Missing local protection

carloperocchio commented 7 years ago

Questions and answers discussion: Italo Busi, Sergio Belotti, Daniele Ceccarelli, Francesco Lazzeri, Gianmarco Bruno, Carlo Perocchio Monday, December 05, 2016

Q: Local protection is missing

Context: TE tunnel open issue

italobusi commented 7 years ago

What does it mean "local protection"? Does it mean requesting to setup a tunnel which is protected within the domain?

In this case, is this issue related with Case 2 described in Issue #16 : Case2: different paths form the same tunnel and hence same end point, e.g. working and protection path

efralaz commented 7 years ago

"local protection" refers to the L bit of the LSPA object defined in RFC5440.

" L flag: Corresponds to the "Local Protection Desired" bit ([RFC3209]) of the SESSION-ATTRIBUTE Object. When set, this means that the computed path must include links protected with Fast Reroute as defined in [RFC4090]."

So this is different from asking for a protected path within the domain, as we'll have just one path formed only by protected links (note that in RFC5440 an explicit reference is done to the Fast Reroute, but the meaning of this attribute could be extended to additional technologies using line protected links).

carloperocchio commented 7 years ago

In my opinion the argument can become more complex/tricky if we include in the discussion also the used abstraction to represent the topology. In case of white topology, any element in the domain network is represented, so applying original local protection behavior, only a single path using protected resources must be computed. Instead in case of gray or black topology domain resources can be summarized or not exported: in this case, I think, it is up to the implementation of the abstraction how to provide protection according the requested path, but no details has to be provided back to the path computation client.

tsaad-dev commented 7 years ago

efralaz's explanation for local protection reflects the intent in the model. The model allows for other types of e2e path-protection by computing and signaling separate LSPs. See:

identity lsp-prot-unprotected { base lsp-prot-type; description "LSP protection 'Unprotected'"; reference "RFC4872"; }

identity lsp-prot-reroute-extra { base lsp-prot-type; description "LSP protection '(Full) Rerouting'"; reference "RFC4872"; }

identity lsp-prot-reroute { base lsp-prot-type; description "LSP protection 'Rerouting without Extra-Traffic'"; reference "RFC4872"; }

identity lsp-prot-1-for-n { base lsp-prot-type; description "LSP protection '1:N Protection with Extra-Traffic'"; reference "RFC4872"; }

identity lsp-prot-unidir-1-to-1 { base lsp-prot-type; description "LSP protection '1+1 Unidirectional Protection'"; reference "RFC4872"; } | identity lsp-prot-bidir-1-to-1 { | base lsp-prot-type; | description | "LSP protection '1+1 Bidirectional Protection'"; | reference "RFC4872"; | }

carloperocchio commented 7 years ago

As referenced by reported by te-tunnel model fragment, these definitions are part of PROTECTION Object defined in RFC4872: the LSP (Protection Type) Flags composed by 6 bits. The 'Local protection desired' is a single flag in the Session Attribute Object defined in RFC3209 and reused in RFC5440 as explained by Francesco, 'efralaz', in a previous comment

     0x01  Local protection desired

           This flag permits transit routers to use a local repair
           mechanism which may result in violation of the explicit
           route object.  When a fault is detected on an adjacent
           downstream link or node, a transit router can reroute
           traffic for fast service restoration.

efralaz commented 6 years ago

The purpose of the proposed modification is to add a constraint to the path computation allowing a path to include only links with protection mechanisms available. During signaling this would allow to instruct transit routers to enable local protection mechanisms. The proposed modification is like this:

grouping common-constraints_config { description "Common constraints grouping that can be set on a constraint set or directly on the tunnel"; ..... leaf local-protection { type boolean; description "True if local protected links are used" } }

sergiobelotti commented 6 years ago

@efralaz Create a pull request for te-tunnel model

italobusi commented 5 years ago

The issue https://github.com/tsaad-dev/te/issues/36 has now been solved:

https://tools.ietf.org/html/draft-ietf-teas-yang-te-types-08

However, it seems we are not using the te-type grouping

@sergiobelotti : could you please check the YANG code and tree?

sergiobelotti commented 5 years ago

what do you mean with te-type grouping?

sergiobelotti commented 5 years ago

we correctly use in the code generic-path-constraints-->common-path-constraints-attributes-->common-constraints , that is the grouping where the update of te-types has been provided at tsaad-dev/te#36.

italobusi commented 5 years ago

@sergiobelotti : but there is no leaf link-protection in the YANG tree:

https://github.com/rvilalta/ietf-te-path-computation/blob/master/ietf-te-path-computation.tree

sergiobelotti commented 5 years ago

IETF-TEAS-WG / ietf-teas-yang-path-computation

Missing local protection #24