On 10/07/2018 12:42, Alexander Vainshtein wrote:
Ahmad and all,
Lots of thanks for your response to my comments.
Unfortunately I cannot say that it addresses all of them – please see
*/inline below/*for the details.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
*From:*Ahmed Bashandy [mailto:[email protected]]
*Sent:* Monday, July 9, 2018 10:54 PM
*To:* Alexander Vainshtein <[email protected]>; Robert
Raszuk <[email protected]>; Chris Bowers <[email protected]>
*Cc:* [email protected]; [email protected];
[email protected];
[email protected]; [email protected]; Stewart Bryant
<[email protected]>
*Subject:* Re: Request for RTGWG Working Group adoption for
draft-bashandy-rtgwg-segment-routing-ti-lfa
Thanks for the comments
See the reply inline at #Ahmed
Ahmed
On 5/29/18 3:35 AM, Alexander Vainshtein wrote:
Robert, Chris and all,
I agree with Robert that it is up to the authors of an individual
submission what they consider in or out of scope of the draft.
However, I agree with Chris that the authors of an individual
draft asking for its adoption by a specific WG should do their
best to address the comments they have received from the WG members.
#Ahmed: Thanks a lot
From my POV this did not happen in the case of the draft in
question – for the following reasons:
1.In his early RTG-DIR review
<https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/>
of the draft Stewart has pointed to the following issues with the
-00 version of the draft (needless to say, I defer to Stewart
regarding resolution of these issues):
a.*No IPR disclosures for draft-bashandy*in spite of 3 IPR
disclosures for its predecessor draft-francois. I have not seen
any attempts to address this issue – at least, search of IPR
disclosures for draft-bashandy did not yield any results today
#Ahmed: Since draft-bashandy inherits draft-francois, then the IPR of
the latter applies to the former. But if there is a spec that requires
re-attaching the IPR of an inherited draft to the inheriting draft, it
would be great to point it out or point out some other draft where
that occurred so that I can follow the exact procedure.
*/[[Sasha]] Well, it looks like we have been both in error here: there
is a Cisco IPR Disclosure <https://datatracker.ietf.org/ipr/3068/> for
draft-bashandy dated 18-Sep17./**//**/This disclosure has been posted
after Stewart’s early review, and I have been wrong not checking for
it before sending this comment. But there is no “inheritance” from IPR
Disclosures for draft-francois either. So I think this issue is now
closed./**//*
b.*Selecting the post-convergence path *(inheritance from
draft-francois) does not provide for any benefits for traffic that
will not pass via the PLR */after convergence/*.
i.The authors claim to have addressed this issue by stating that
“Protection applies to traffic which traverses the Point of Local
Repair (PLR). Traffic which does NOT traverse the PLR remains
unaffected.”
ii.From my POV this is at best a misleading statement because it
does not really address Stewart’s comment which was about traffic
that */traversed the PLR before convergence/* but */would not
traverse it after convergence/*.
iii.This is not a fine distinction: actually it indicates that
selecting post-convergence path for repair is more or less
useless (unless the traffic originates at the PLR).
#Ahmed: Thanks for pointing out this *additional benefit* of providing
a post-convergence back path. If a flow starts to use the PLR after a
failure, then the presence of a post convergence backup path on the
PLR extends the benefits of using the post-convergence path to flows
that did not use the PLR prior the topology change. I will modify the
statement in the introduction to indicate that :)
*/[[Sasha]] Sorry, but this looks quite off the target to me. The
repair path provided by TI-LFA is only relevant for the period between
the actual failure (that triggers usage of this path) and
re-convergence of IGP. I.e. traffic that did cross the PLR before
failure but crosses it after failure AND IGP re-convergence cannot
benefit in any way from selection of the repair path. At the same
time, it is pretty easy to give an example of a setup in which:/*
-*/Traffic between two nodes crosses the PLR before failure/*
-*/The destination of this traffic is protected (say by a local LFA)
and so will use the repair path in the interval between failure
detection and IGP re-convergence/*
-*/After IGP re-convergence traffic does not pass thru the original
PLR anymore and thus does not experience any benefits from any
possible selection of the repair path by the PLR./*
*/If you wish, I can send you a simple example topology. /*
*//*
*/So, from my POV, this issue remains as open as before./*
SB> This concern has been a day one issue by pretty much everyone that
has seen this work.
The draft really needs text to address it.
c.*Selecting the post-convergence path is detrimental to
scalability of the solution*. Please note that in RFC 7490
<https://tools.ietf.org/html/rfc7490> “the Q-space of E with
respect to link S-E is used as a proxy for the Q-space of each
destination” in order to provide a scalable solution – but this
clearly is not the case of draft-bashandy if post-convergence
paths are used. To the best of my understanding, the authors did
not, so far, do anything to address this comment.
#Ahmed: I fail to see why there is a scalability problem.
draft-bashandy-rtgwg-segment-routing-ti-lfa just prefers particular
node(s) in the Q space if that node(s) is (are) along the post
convergence path.
But if I am missing something, it would be great to point out exactly
what aspect of scalability you are concerned about so that we can
address it
*/[[Sasha]] Please take a look at the text from Section 5.2.1 of RFC
7490 <https://tools.ietf.org/html/rfc7490> (the relevant text is
highlighted):/*
Note that the Q-space calculation could be conducted for each
individual destination and a per-destination repair tunnel end point
determined. However, this would, in the worst case, require an SPF
computation per destination that is not currently considered to be
scalable. Therefore, the Q-space of E with respect to link S-E is
used as a proxy for the Q-space of each destination.
*/[[Sasha]] The proxy approach described above works well enough with
RLFA. But it is hardly compatible with the proposal to use prefer the
repair paths that match post-convergence paths, because
post-convergence paths are per affected destination. I do not see how
this can be combined with selecting a single Q-space (and hence a
single PQ node) for all destinations./*
SB> That is a good point.
- Stewart
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
