RE: Observations/feedback on draft-decnodder-mpls-interas-protection

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Stefaan,

Thanks for your replies. Some follow-on comments
and suggestions for the next rev. in-line.

Regards,
-Vishal

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> Behalf Of stefaan.de_cnodder@alcatel.be
> Sent: Wednesday, April 28, 2004 10:08 AM
> To: Vishal Sharma
> Cc: ccamp@ops.ietf.org
> Subject: Re: Observations/feedback on
> draft-decnodder-mpls-interas-protection
>
>
>
> Hi Vishal,
>
> Thanks for your comments. You find the answers below.
>
> I see that one of the confusing points is about SRLGs where SRLGs
> can be defined inside the ASs without looking to links in other ASs
> using the same physical resource (=let call them inconsistent or
> AS-local SRLGs) or whether the SRGs are defined globaly. I will add
> a definition of it in the draft.

[Vishal] Yes, I think this would be quite useful to have.
Would also help with some of the other dicussions on
SRLG-related issues on the ML.

> The scope of the draft is just to show how existing mechanisms (XRO
> in this case) can be used to provide any type of protection to
> inter-AS LSPs. A problem is that SRLG protection (largest part of
> the draft since the rest is rather trivial) is not well-defined for
> intra-AS LSPs, that's why I added a small appendix about this in the
> draft.

[Vishal] Ok, great. I think together with the above, this appendix should
be useful.

>
> Vishal Sharma wrote:

<<snip>>

> > *******************************************************************
> > Technical
> > ---------
> > i) Abstract: I think it would be useful to make clear here that the
> > techniques
> > in this document apply to links between 2 ASs (or only to
> inter-AS links).
> >
>
> [Stefaan] Not really. It is about protecting an inter-AS link.
> However, for the links and nodes inside the AS, the current FRR
> techniques can be used. A special case is comment xvii about the
> link preceding the exit ASBR in case of SRLG+node protection. I will
> make this clearer in the update of the document.

[Vishal] Great, I understand. I think the clarification will help.

> > ii) Intro., para 4, "Section 4 ... node protection," would be clearer if
> > it specified that an e2e path for an LSP _crossing multiple
> ASs_ can only
> > provide link or node protection. (Presumably, for LSPs within
> an AS, where
> > the SRLG's would be consistent, it should be possible to provide SRLG
> > protection using e2e protection.)
> >
>
>
> [Stefaan] ok, also best to add an explanation on what consistent and
> inconsistent SRLG ids are, better: AS-local and AS-global SRLGs.

[Vishal] Yes, I believe that would help the reader, and is
a useful distinction for subsequent discussions in the WG in general.

> > iii) Sec. 3, para 1, "For instance, in Figure 2 ... multiple
> core routers,"
> > it is a bit confusing to have R23 and R24. Which links specifically are
> > being referred to here? Is it, R21-R24, R21-R25, R25-R24?
> >
>
> [Stefaan] I believe you are looking to figure 1... the text refers
> to figure 2. I will reword it somewhat.

[Vishal] Ok, got it, thanks.

> > iv) Title of Sec. 4 might be better as "Problems in SRLG protection with
> > disjoint
> > e2e LSPs"
> >
>
>
> [Stefaan] Ok
>
>
>
> > v) The document uses "main" and "primary" for the working LSP.
> It might be
> > better to have consistently the same term throughout.
> >
>
> [Stefaan] Indeed, I will use the words working and recovery. This
> terminology is in line with
> draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
>
>
> > vi) It might be better to add another row of routers in both
> ASs in Fig. 2,
> > to make it non-trivial. That way, it will be possible to illustrate that
> > there are multiple secondary egress AS-BRs, and multiple
> secondary ingress
> > AS-BRs, and also that the egress AS-BR has to make a choice of a route
> > to an appropriately picked secondary egress AS-BR, etc.
> >
>
> [Stefaan] Ok, I will update the figure based on your suggestion.
>
>
> > vii) The way the method is described, especially in Sec. 6, it
> appears that
> > the technique applies only to packet LSPs. Is my understanding correct?
> >
>
> [Stefaan] That is correct. At the latest IETF there was a draft
> describing protection for non-packet LSPs. For non-packet LSPs,
> bypass tunnels make no sense and apparently for detours they also
> use another approach. In addition, it is only for ASes, and not for
> regions in general.

[Vishal] Ok, sure. Thanks for the clarification.

> > viii) The entire segment in Sec. 6.1.1 para 2, from "In case
> this condition
> > ..."
> > until "... not in the downstream AS (AS2 in Figure 2)," might
> benefit from
> > some simplification in the writing. It's a bit difficult to follow, as
> > written.
> >
>
>
> [Stefaan] Yes, maybe some more explanation with figures might be
> good here. Simply stated, if the link between AS1 and AS2 is to be
> protected, then the detour starts in AS1 and goes to AS2 without
> going through another AS.


[Vishal] Yes, I think so. One has to read v. carefully otherwise.

> > ix) Similary, in the same para, the description of what portion
> of an RRO
> > should
> > be in the ERO for the detour LSP emanating from the egress AS-BR is also
> > confusing.
> > It might be restated as
> > "The ERO for the detour LSP starting at the egress AS-BR
> contains several
> > segments.
> > It must first contain a strict or loose path towards the
> secondary egress
> > AS-BR, followed
> > by a segment of the RRO for the primary LSP. This segment
> begins at the last
> > hop in
> > the downstream AS and contains all hops thereafter up until the
> > destination."
> >
>
>
> [Stefaan] Maybe also good to explain this based on the figure part
> by part.

[Vishal] If that is possible, I would support doing that. It will
make the scheme easier to follow.

> > x) In the same para, it is mentioned that the ERO of the detour
> LSP consists
> > of
> > two segments. However, when elucidating this with a reference
> to Fig. 2, the
> > ERO
> > of the detour LSP is only said to be composed for router R14,
> R22 and all
> > routers
> > thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned.
> >
>
>
> [Stefaan] Indeed, you are right, I will update the example.

[Vishal] Ok, thanks.

> > xi) In the draft, in the sentence describing the ERO of the detour LSP,
> > the last router should probably be R24 instead of R22 (as currently
> > written).
> >
>
> [Stefaan] There is something wrong with this example. The last node
> in the downstream AS of the main LSP must be in the ERO of the main
> to ensure that the detour merges in the downstream AS.

[Vishal] Sure, no problem. Good to know I wasn't confusing things. :-)

> > xii) Sec.  6.1.1, para 4, the last sentence could be reworded to make
> > it a bit clearer. I think it is saying that when the primary
> and secondary
> > egress AS-BRs are the same, and the primary and secondary ingress AS-BRs
> > are the same, and they have multiple links between them, then the detour
> > LSP must simply use an inter-domain link different than the one used by
> > the primary LSP, and no path computation is needed at the egress AS-BR.
> >
>
>
> [Stefaan] Your understanding is correct. I will reword it.

[Vishal] Thanks for confirming. A bit of wordsmithing here would help.


> > xiii) It would be useful to explain the purpose and structure of the
> > LSP-Merge
> > object as well as the operations performed on it, in Sec. 6.1. itself.
> > Otherwise, the reader sees this object mentioned in the main
> text, without
> > having
> > an idea of what it is.
> > In any case, since the appendices are quite small, and sort of
> intergral to
> > the
> > subsequent text in the main doc., I think it would be best to
> pull them into
> > the
> > main text.
> >
>
>
> [Stefaan] I prefer to keep it in the appendix to avoid that people
> start thinking that my main purpose is to define this RSVP
> extionsion, which is not the case but in principle I agree with you:
> forward references are never good but more drafts/RFCs are doing
> this. Best to add a sentence at the end of 6.1.1 to say what the
> result will be of using it.

[Vishal] Ok, I see your point. In that case, the sentence you suggest
would be fine.

> > xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to
> > follow.
> >
>
>
> [Stefaan] see above.
>
> > xv) The second last para in Sec. 6.3.1 mentions that the merge point of
> > the detour and main LSP must ensure that it can switchover traffic from
> > the incoming detour LSP to its originating detour LSP, since the egress
> > link at this merge point may belong to the same SRLG as the inter-domain
> > link that the incoming detour LSP was protecting.
> > Is this trivial to ensure? It appears that there is a bit of work
> > that an LSR would have to do to ensure that. No? (Since the normal
> > procedure would be simply to merge traffic from the detour LSP
> > on to the main LSP.)
> >
>
>
> [Stefaan] FRR as currently defined in the FRR-draft assumes only
> single failure, i.e. no SRLG protection. In this case, only at most
> 1 detour LSP of a main LSP will be used at a particular time. With
> SRLG's their is indeed the requirement that multiple detours can be
> in use at the same time... that's the consequence of SRLGs and
> indeed, this requires extra functionality. So indeed, your comment
> is very valid.

[Vishal] Great, thanks for the clarification. I think this is rather an
important case that your draft handles, so it would be
worth emphasizing in the draft why this is important (and non-trivial),
along
the lines of what you explained above.

> > xvi) Sec. 6.3.4, the first sentence "If the secondary ... inside these
> > objects"
> > is worded in a rather confusing way. In which objects does the
> sec. ingress
> > AS-BR add the list of SRLG's of the inter-AS link?
> >
>
>
> [Stefaan] Wording is indeed not good: list of SRLGs is added to XRO
> or EXRS. Will correct wording.
>
>
> > xvii) In Sec. 6.3.6. it is not clear why there is a focus on the SRLG
> > protection
> > of the link _preceding_ the ingress AS-BR?
> >
>
>
> [Stefaan] you mean the egress AS-BR I guess. Well normally when
> node+link protection is desired, then one bypass/detour is used to
> protect against a failure of the link or node. In case of SRLG+node
> protection, you would expect the same: one bypass/detour is used to
> protect against a failure of the SRLG or node. In the special case
> where the node is an egress AS-BR, then it is not possible anymore
> to use a single bypass/detour but 2 bypasses/detours have to be
> used. That is why there is a special focus on the SRLG protection of
> the link preceding the egress AS-BR + node protection of that egress
> AS-BR. This applies only when inconsistent SRLG numbering is used
> between the ASs (or AS-local SRLGs to name it differently). The
> detour/bypass protecting the SRLG must merge in the same AS, the
> detour/bypass protecting the node crosses the AS boundary.


[Vishal] Ok, thanks for the explanation. I get it now. May be worth
adding some of the above explanation to the draft to provide
some more context.

> > xviii) In the same section, the para "To ensure that  .... towards the
> > egress
> > AS-BR" is unclear, and perhaps needs to be reworded and better
> explained.
> > Not sure which link the phrase "... SRLG disjoint with the next
> link of the
> > main
> > LSP computed towards the egress AS-BR" refers?
> >
>
>
> [Stefaan] Ok, a slight rewording is required here. The "next link"
> is the link with its SRLGs to be protected, i.e. the link preceding
> the prim egress AS-BR.

[Vishal] Ok, thanks, got it now.

> > xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ...
> LSP setup
> > would fail," is unclear.
> >
>
>
> [Stefaan] This is a complex one. For detours protecting against
> SRLGs of the inter-AS link, the detour MUST merge in the downstream
> AS and MUST NOT cross other ASes when inconsistent SRLG numbering is
> used. For node (or link) protection, it is not really a MUST, but
> rather a SHOULD. If the downstream AS is only 1 hop, then for node
> protection there is not other choice then to let the detour merge in
> the "downstream-downstream AS", which is not allowed for SRLG. But
> for SRLG, the detour may merge at the primary ingress AS-BR, but
> that is then not allowed for node protection. Becuase of these
> conflicting requirements, it is recommended to use 2 detours: one
> for SRLG protection and one for node protection. It is hard to
> understand, but it is correct. Maybe a figure in the draft might
> help.

[Vishal] A figure would be really good here. Even otherwise,
some words along the lines of what you just said above could
help to appreciate the complexity, and the solution you've provided.

> > xx) Sec. 7, second last para states "We also note ... does not
> lead to the
> > failure of the bypass tunnel." I guess it wasn't clear why teh interface
> > failure
> > does not cause a failure of the bypass tunnel.
> >
>
>
> [Stefaan] If the interface fails and this interface was the
> destination of the bypass, then the destination does not exist
> anymore in theory, so the bypass could be torn down. However, this
> is not allowed, otherwise link and bypass would fail at the same
> time. I believe the text is clear here.

[Vishal] Ok, I see now. Actually, what you just said above could
be added maybe to the text itself. It makes things v. clear.

> > xxi) Appendix B, last sentence, why is the use of the sender-template
> > specific
> > detour LSP merely "recommended" as opposed to being "required"?
> >
>
>
>
> [Stefaan] Good point. This has to be changed into "required".
> Although in some particular cases, path-specific detours may be used
> but it is better to always use sender-template specific detours.

[Vishal] Ok, thanks.

> > xxii) The last sentence of Appendix B ends with "avoid merging
> with other
> > LSPs". It
> > would be useful to say here which those "other LSPs" are. I
> assume their are
> > themselves
> > other detour LSPs for the given main LSP?
> >
>
>
> [Stefaan] Yes, this deserves more explanation. Your understanding is
> correct. The basic problem is that 2 detours of the same main LSP
> protect against different SRLGs and hence MUST NOT be merged.

[Vishal] Sure, I think just the above sentence in the text will
clarify things.