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

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

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