Re: Request for RTGWG Working Group adoption for draft-bashandy-rtgwg-segment-routing-ti-lfa

[Ahmed Bashandy <[e-mail]>]

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

> 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
>
> 2.*There is a serious overlap between the contents of Section 5.3 of 
> draft-bashandy and the*Node Protection for SR-TE Paths 
> <https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-02> 
> draft. I do not think that the WG really needs a replay of the recent 
> discussion between the authors of draft-farrel-mpls-sfc and 
> draft-xuclad-spring-sr-service-chaining. I, for one, would expect any 
> such issues being resolved (one way or another) */before adopting one 
> of these documents as a WG one/*.
>
#Ahmed:  Protecting explicit path was first documented in
https://www.ietf.org/archive/id/draft-francois-rtgwg-segment-routing-ti-lfa-00.txt
which is dated Aug/17/2015. That is at least 6 months prior to the first 
version of "draft-hegde-spring-node-protection-for-sr-te-paths-00", 
which is dated Mar/20/16

> There are some other comments I have on the draft, but I do not see 
> them as an obstacle for WG adoption.
>
Ahmed: Thanks a lot again
>
> Regards,
>
> Sasha
>
> Office: [phone]
>
> Cell: [phone]
>
> Email: [e-mail]
>
> *From:*rtgwg [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Tuesday, May 29, 2018 12:03 PM
> *To:* Chris Bowers <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]; 
> [e-mail]; [e-mail]
> *Subject:* Re: Request for RTGWG Working Group adoption for 
> draft-bashandy-rtgwg-segment-routing-ti-lfa
>
> Hi Chris,
>
> I am afraid you have it completely backwards :)
>
> Current status of the document is individual submission and it is up 
> to the authors to decide what is and what is not in the scope of their 
> work. It can't be that anyone asking for scope extension can block the 
> work or even WG adoption call by throwing the stones at it. That would 
> be pretty insane.
>
> Now once the doc is accepted as working group document its ownership 
> transitions from given set of authors to WG and indeed WG could ask to 
> extend or narrow the scope. Again WG not an individual.
>
> For me (a WG member) the document looks good as is and should proceed 
> fast since it addresses very important technology gap. I do sincerely 
> hope that any attempt to derail it or stretch it so much that it will 
> break will be stopped by WG chairs and ADs.
>
> Best,
>
> Robert.
>
> On Tue, May 29, 2018 at 1:30 AM, Chris Bowers <cbowers@juniper..net 
> <mailto:[e-mail]>> wrote:
>
>     Ahmed,
>
>     Several participants in the WG (including Stewart) have provided
>     feedback requesting that the draft address particular issues.
>
>     The response you have provided to this feedback is that these
>     issues are out-of-scope for the draft, so they will not be addressed.
>
>     I have seen no change in the text of the draft to incorporate this
>     feedback.
>
>     It is up to the working group to decide what is the scope of a
>     document it works on.  I do not think that it would be productive
>
>     to conduct a poll for WG adoption until the scope of the draft is
>     broadened to address the feedback that has already been provided.
>
>     Chris
>
>     *From:* Jeff Tantsura <[e-mail]
>     <mailto:[e-mail]>>
>     *Sent:* Monday, May 28, 2018 4:27 PM
>     *To:* Ahmed Bashandy <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>; Stewart Bryant
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail]
>     <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>
>
>     *Subject:* Re: Request for RTGWG Working Group adoption for
>     draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>     Hi Ahmed,
>
>     I’m awaiting Stewart’s response.
>
>     Thanks!
>
>     Cheers,
>
>     Jeff
>
>     *From: *Ahmed Bashandy <[e-mail]
>     <mailto:[e-mail]>>
>     *Date: *Monday, May 28, 2018 at 13:59
>     *To: *Jeff Tantsura <[e-mail]
>     <mailto:[e-mail]>>, rtgwg-chairs
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc: *<[e-mail]
>     <mailto:[e-mail]>>,
>     <[e-mail] <mailto:[e-mail]>>,
>     <[e-mail] <mailto:[e-mail]>>, <[e-mail]
>     <mailto:[e-mail]>>, <[e-mail]
>     <mailto:[e-mail]>>,
>     <[e-mail]
>     <mailto:[e-mail]>>, <[e-mail]
>     <mailto:[e-mail]>>, RTGWG <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject: *Re: Request for RTGWG Working Group adoption for
>     draft-bashandy-rtgwg-segment-routing-ti-lfa
>
>     Hi Jeff
>
>     All comments have been addressed as shown in the email below
>
>     Can we initiate the WG adoption
>
>     Ahmed
>
>     On 5/19/18 12:20 PM, Ahmed Bashandy wrote:
>
>         Hi Jeff
>
>         These comments are already addressed with the exception of the
>         minor comment about section 5.3.1 and 5.3.2. But for the
>         convenience of everyone, I will respond to each specific
>         comment here
>
>         See "#Ahmed" below
>
>
>         Thanks
>
>         Ahmed
>
>         > Reviewer: Stewart Bryant
>
>         > Review result: Has Issues
>
>         > 
>
>         > These review comments were incorrectly posted against the uloop draft,
>
>         > apologies for any confustion.
>
>         > 
>
>         > I have been asked to perform an early review of this document on
>
>         > behalf of the Routing Directorate.
>
>         > 
>
>         > Summary:
>
>         > 
>
>         > A document on this subject is something that the WG should publish,
>
>         > but I think that there are number of issues that the WG need to
>
>         > discuss and reach consensus on before deciding whether or not they
>
>         > should adopt this draft as a starting point for that work.
>
>         > 
>
>         > 
>
>         > Major Issues:
>
>         > 
>
>         > Before I get into the substance I am surprised that there are no IPR
>
>         > disclosures. In an earlier and related work
>
>         > (draft-francois-segment-routing-ti-lfa-00) there were three IPR
>
>         > disclosures.
>
>         #Ahmed
>
>         The IPR link is
>
>         https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-bashandy-rtgwg-segment-routing-ti-lfa
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_ipr_search_-3Fsubmit-3Ddraft-26id-3Ddraft-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=i0BSrEO9trtQg-svJmisngedg7C2ALPRCMA49HKC8Jg&e=>
>
>         If there is anything else for us to do regarding IPR I will be more than happy to take care of
>
>           
>
>         > 
>
>         > The work has four basic components, the concept of resolving the
>
>         > problem of P and Q being non-adjacent, the use of SR to solve the
>
>         > non-adjacency, the use of the post convergence path following failure
>
>         > and the applicability of these techniques to an SR network. The first
>
>         > and second points seem of utility in non-SR networks, and so I am
>
>         > surprised that they are not called out as such, in the first case
>
>         > perhaps with consideration to strategically places RSVP tunnels, or
>
>         > binding segments.
>
>         The draft already mentions that the work builds on top of existing FRR work. For example
>
>         the second statement of the abstract already says
>
>            builds on proven IP-FRR concepts being
>
>            LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding
>
>            (DLFA).
>
>         The statement about the possibility of using RSVP is clearly outside the scope of document as mentioned in first paragraph of the introduction.
>
>           
>
>         > 
>
>         > The issue of mapping repair path to the post convergence path to the
>
>         > something that has always concerned me in this concept. It is true
>
>         > that traffic that always passes through the PLR will experience the
>
>         > properties the authors describe, but not all traffic will pass through
>
>         > the PLR post convergence. The post failure path will be topology
>
>         > dependent, and may take a different path from the point of ingress.
>
>         #Ahmed
>
>         The fourth paragraph in the introduction clearly mentions that we are protecting the traffic passing through the PLR.
>
>           
>
>         > 
>
>         > I am also concerned that the authors do not discuss the need for loop
>
>         > free convergence, since although traffic going through the repair path
>
>         > will be loop-free, traffic arriving at the PLR might not be.. Consider
>
>         > for example a topology fragment that looks like a clock with a router
>
>         > at each minute. Traffic enters at 9 o'clock, leave at 3 o'clock and
>
>         > goes via 12 o'clock and 12 o'clock fails.  The routers 9..12 will
>
>         > re-converge at different times and this may give rise to the
>
>         > micro-looping of traffic trying to get to the PLR. A summary of the
>
>         > problem and a pointer to the companion draft may be sufficient.
>
>         #Ahmed
>
>         The last statement in the first paragraph in the introduction refers the reader to the uloop avoidance draft which handles non-local failures
>
>           
>
>         > 
>
>         > Finally on the basic concept it would be good to state up from whether
>
>         > the proposal is constrained solely to SR networks, or whether the
>
>         > authors believe that the concept is of wider applicability. It see no
>
>         > reason why it would be constrained to only work on SR networks.
>
>         #Ahmed
>
>         As it is quite clear from the title of the draft as well as many statements inside it, the scope of document is restricted to segment routing.
>
>           
>
>         > 
>
>         > There is no discussion of multiple failures, nor as far as I can see
>
>         > of failures that are worse than anticipated. This is an important
>
>         > point that needs to be established early. Some methods, (MRT)
>
>         > intrinsically address multiple failures, others (NV) intrinsically
>
>         > exclude them. Simple LFA needs a supervisor to quickly abandon all
>
>         > hope when they occur.
>
>         #Ahmed
>
>         As specified in the 3rd paragraph of the introduction the scope of the document is limited to single link, single node, and single local SRLG failure.
>
>           
>
>         > 
>
>         > In an SR network the paths used are not the shortest paths, they are a
>
>         > collection of shortest paths, so there needs to be some discussion on
>
>         > the interaction between the SR paths and repair paths to consider
>
>         > whether it is unconditionally safe against forwarding loops.. It would
>
>         > presumably be so if the authors borrowed the concept of repair
>
>         > addresses rather than normal forwarding addresses from not-via, but I
>
>         > don't think they have done this.
>
>         #Ahmed
>
>         Again the second statement of the 1st paragraph of the Introduction says
>
>           
>
>            By relying on segment routing this document provides
>
>                   a local repair mechanism for standard IGP shortest path
>
>           
>
>         So the scope of the document is quite clear
>
>           
>
>         > 
>
>         > There should also be some discussion on the original path constraints
>
>         > that are applicable to the repair. Presumably the ingress node
>
>         > constrained the traffic to go though failed node F for a reason. If
>
>         > the repair is unconstrained that reason could be violated, but this is
>
>         > not discussed in the text.
>
>         #Ahmed
>
>         Same response as the response to the previous comment. The scope is standard IGP shortest paths
>
>           
>
>           
>
>         > 
>
>         > 
>
>         > In the Security section you say:
>
>         > 
>
>         >     The behavior described in this document is internal functionality
>
>         >     to a router that result in the ability to guarantee an upper bound
>
>         >     on the time taken to restore traffic flow upon the failure of a
>
>         >     directly connected link or node. As such no additional security
>
>         >     risk is introduced by using the mechanisms proposed in this
>
>         >     document.
>
>         > 
>
>         > 
>
>         > SB> I am not sure that the above is correct. There may be a security
>
>         > reason
>
>         > SB> why a packet was steered along a path which breaks when you use
>
>         > this
>
>         > SB> technique.
>
>         #Ahmed
>
>         The security consideration section has been modified to to indicate that
>
>         the traffic is being steered over the post convergence path and hence there
>
>         is no security risk because this is the path that the operator intended to use
>
>         after the failure through the metrics configured on the links. In fact by expediting
>
>         rerouting the traffic over the intended post convergence path without waiting
>
>         for IGP reconvergence, we have introduced a minor security enhancement by reducing
>
>         misforwarding and/or traffic drop
>
>           
>
>           
>
>           
>
>         > 
>
>         > In the conclusion you say:
>
>         > 
>
>         >     The
>
>         >     mechanism is able to calculate the backup path irrespective of the
>
>         >     topology as long as the topology is sufficiently redundant.
>
>         > 
>
>         > 
>
>         > SB> That is certainly true in classic. I am not sure this is
>
>         > universally
>
>         > SB> true under SR which includes the use of non-shortest path and
>
>         > SB> binding segments.
>
>           
>
>         #Ahmed
>
>         Again the document is restricted to IGP shortest path as mentioned in the introduction
>
>           
>
>           
>
>         > Minor issues:
>
>         > 
>
>         >     For each destination in the network, TI-LFA prepares a data-plane
>
>         >     switch-over to be activated upon detection of the failure of a
>
>         >     link used to reach the destination.
>
>         > 
>
>         > SB> To make the scaling clearer to the reader, I think you need
>
>         > SB> to make it clear that for each protected link, you determine
>
>         > SB> the repair needed to reach every destination reachable over that
>
>         > SB> link. You sort of say that, but it's a bit hidden.
>
>         #Ahmed
>
>         I do not understand the difference between the text in the draft and the
>
>         text that you are proposing. We think that our text is quite clear
>
>           
>
>           
>
>         >     We provide the TI-LFA approach that achieves guaranteed coverage
>
>         >     against link, node, and local SRLG failure, in any IGP network,
>
>         >     relying on the flexibility of SR.
>
>         > 
>
>         > SB> Should that be any SINGLE link.... failure?
>
>         #Ahmed
>
>         As mentioned above few times above, the introduction clearly mentions *single*
>
>           
>
>           
>
>         > In the text (and the text that follows)
>
>         > 
>
>         >     To do so, S applies a "NEXT" operation on Adj(S-F) and then two
>
>         >     consecutive "PUSH" operations: first it pushes a node segment for
>
>         > F,
>
>         >     and then it pushes a protection list allowing to reach F while
>
>         >     bypassing S-F.
>
>         > 
>
>         > You need to reference the SR operations.
>
>         #Ahmed
>
>         This paragraph is in Section 5.2.1. The latest version refers to the SR draft
>
>           
>
>         > 
>
>         > Also you are considering Adj segments, and presumably they were there
>
>         > for a reason, but you do not discuss that.
>
>         #Ahmed
>
>         Section 5.2 discusses protecting adjacency segments
>
>           
>
>           
>
>         > 
>
>         > In 5.3.1 and 5.3.2 you have a list of conditions, but do not make it
>
>         > clear whether any or all must be true.
>
>         > 
>
>         #Ahmed
>
>         The intention is for all of the conditions to be true. I will make it clear in the next version
>
>           
>
>           
>
>         > Nits
>
>         > 
>
>         > 1. Introduction
>
>         > 
>
>         >     Segment Routing aims at supporting services with tight SLA
>
>         >     guarantees [1]. This document provides a local repair mechanism
>
>         >     relying on SR-capable of restoring end-to-end connectivity in the
>
>         >     case of a sudden failure of a network component.
>
>         > 
>
>         > SB> Grammar needs a little work in the last sentence.
>
>         #Ahmed
>
>         Addressed in the latest version of the document
>
>           
>
>           
>
>         > In Fig 1, I assume that the blobs are network fragments.
>
>         > 
>
>         > In the conclusion you say:
>
>         >     This document proposes a mechanism that is able to pre-calculate a
>
>         >     backup path for every primary path so as to be able to protect
>
>         >     against the failure of a directly connected link or node.
>
>         > SB> you need to add SRLG
>
>         #Ahmed
>
>         Addressed in the latest version of the draft
>
>           
>
>         On 5/10/18 9:40 AM, Jeff Tantsura wrote:
>
>             Hi Ahmed,
>
>               
>
>             We would like you to address the comments from Early Review and get OK from Stewart, before progressing the document
>
>               https://datatracker.ietf.org/doc/review-bashandy-rtgwg-segment-routing-ti-lfa-00-rtgdir-early-bryant-2017-05-31/
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dbashandy-2Drtgwg-2Dsegment-2Drouting-2Dti-2Dlfa-2D00-2Drtgdir-2Dearly-2Dbryant-2D2017-2D05-2D31_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=hRw9JYX16QjABo0X8NzFeA4qtZ406HEzUaYNGbxzzGQ&s=xMxNv--9p-MRxL0OnPyOZs76OvnidWNl7oTWWXG7B3g&e=>
>
>               
>
>             Please let us know when this could be done.
>
>               
>
>             Cheers,
>
>             Jeff
>
>             On 4/25/18, 02:17, "Ahmed Bashandy"<[e-mail]> <mailto:[e-mail]>  wrote:
>
>               
>
>                  Hi
>
>                  
>
>                  We would like to request the WG adoption of
>
>                  draft-bashandy-rtgwg-segment-routing-ti-lfa-04.
>
>                  
>
>                  The draft has been stable for a long while and the IPR declaration has
>
>                  been recorded
>
>                  
>
>                  The latest version addresses all comments and the draft has been
>
>                  presented in IETF-96 and IETF-99
>
>                  
>
>                  Thanks
>
>                  
>
>                  Ahmed
>
>                  
>
>                  
>
>                  
>
>               
>
>               
>
>
>     _______________________________________________
>     rtgwg mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtgwg
>
>
> ___________________________________________________________________________
>
> This e-mail message is intended for the recipient only and contains 
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
> received this
> transmission in error, please inform us by e-mail, phone or fax, and 
> then delete the original
> and all copies thereof.
> ___________________________________________________________________________