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

From: "Vishal Sharma" <[email-masked]>
Date: Tue, 20 Apr 2004 00:14:15 -0700

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

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

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?

iv) Title of Sec. 4 might be better as "Problems in SRLG protection with
disjoint
e2e LSPs"

v) The document uses "main" and "primary" for the working LSP. It might be
better to have consistently the same term throughout.

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.

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?

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.

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

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.

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

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.

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.

xiv) This will make the description in Sec. 6.1.4 and 6.3.1 easier to
follow.

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

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?

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?

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?

xix)In Sec. 6.3.6, para 4, the phrase "IF only 1 detour LSP ... LSP setup
would fail," is unclear.

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.

xxi) Appendix B, last sentence, why is the use of the sender-template
specific
detour LSP merely "recommended" as opposed to being "required"?

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?

Editorial
---------

i) Sec. 4, para 1, "first of all it supports fast recovery, and, second, it
provides
SRLG protection..."

ii) Sec. 4, para 3, "This is because ... in common with AS1, and _neither_
AS1
nor AS3 will be aware ..."

iii) Sec. 6.1.1, para 2, "in case this condition ... goes through the AS
where
the detour LSP originated causing loops."

iv) Sec. 6.2, "The method to determine a secondary egress AS-Br is the same
as
for the _secondary_ egress AS-BR for link protection."

v) Sec. 7, para 5, "The difficulty ... bypass tunnels _lies_ in the
selection of
the appropriate ..."

---

From: [email-masked]
Date: Wed, 28 Apr 2004 19:07:45 +0200

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

> respond to them after having time to review your feedback.

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

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

> 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

[Stefaan] Ok

> 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

> to an appropriately picked secondary egress AS-BR, etc.

[Stefaan] Ok, I will update the figure based on your suggestion.

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

> some simplification in the writing. It's a bit difficult to follow, as

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

> the downstream AS and contains all hops thereafter up until the

[Stefaan] Maybe also good to explain this based on the figure part
by part.

> thereafter. The segment from R14 to R12 and R12 to R21 is not mentioned.

[Stefaan] Indeed, you are right, I will update the example.

> the last router should probably be R24 instead of R22 (as currently

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

> the primary LSP, and no path computation is needed at the egress AS-BR.

[Stefaan] Your understanding is correct. I will reword it.

> subsequent text in the main doc., I think it would be best to pull them into

[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

[Stefaan] see above.

> procedure would be simply to merge traffic from the detour 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.

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

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

> 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

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

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

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

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