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

[stefaan.de_cnodder@alcatel.be]

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.

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.

regards,

Stefaan


Vishal Sharma wrote:
> 
> Hi Stefaan,
> 
> As promised at the Seoul IETF, here is my (rather belated!)
> feedback on the interas protection draft.
> (I am cc'ing it to my co-authors as well, so that we can
> minimize duplication of our comments.)
> 
> To make things easier, I have divided my comments into
> technical and editorial.
> 
> Regards,
> -Vishal
> 
> PS: BTW, thanks for your comments on draft-dachille, will try to
> respond to them after having time to review your feedback.
> 
> *******************************************************************
> 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.


> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.


> 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.


> 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.


> 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.


> 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.


> 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.


> 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.


> 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.

> 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.