the current draft reflects the changes discussed during “the last several months”
the only missing update is about strict-spf and your proposed change is going to be included very soon (hopefully this week). s. > On Nov 15, 2016, at 12:29 AM, Chris Bowers <cbow...@juniper.net> wrote: > > Stefano, > > Has the change suggested in this email been incorporated in the text of > draft-ietf-spring-segment-routing? > Can you publish the current working version of the draft with the WG so that > we can make sure that proposed textual changes and additions from the last > several months have been incorporated? > > Chris > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: Thursday, September 15, 2016 1:42 AM > To: Chris Bowers <cbow...@juniper.net> > Cc: spring@ietf.org > Subject: Re: [spring] clarification of text in > draft-ietf-spring-segment-routing-09 > > Hi Chris, > > >> On Sep 12, 2016, at 4:04 PM, Chris Bowers <cbow...@juniper.net> wrote: >> >> As far as I can tell, this request for clarification of the text in >> draft-ietf-spring-segment-routing-09 has not been addressed. >> >> Thanks, >> Chris >> >> -----Original Message----- >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Chris Bowers >> Sent: Wednesday, August 3, 2016 9:24 AM >> To: spring@ietf.org >> Subject: [spring] clarification of text in >> draft-ietf-spring-segment-routing-09 >> >> SPRING WG, >> >> The following paragraph in section 3.2.1 of >> draft-ietf-spring-segment-routing-09 is confusing. >> >> The ingress node of an SR domain validates that the path to a prefix, >> advertised with a given algorithm, includes nodes all supporting the >> advertised algorithm. In other words, when computing paths for a >> given algorithm, the transit nodes MUST compute the algorithm X on >> the IGP topology, regardless of the support of the algorithm X by the >> nodes in that topology. As a consequence, if a node on the path does >> not support algorithm X, the IGP-Prefix segment will be interrupted >> and will drop packet on that node. It's the responsibility of the >> ingress node using a segment to check that all downstream nodes >> support the algorithm of the segment. >> >> I interpret the first, third, and fourth sentences in this paragraph as >> saying that an ingress node should make sure that transit nodes on a path >> install transit forwarding entries for prefix-SIDs for a given algorithm by >> looking that >> the SR-Algorithm (sub)-TLV advertised by the transit nodes before sending >> traffic on that path. >> >> However, the second sentence in the paragraph confuses this interpretation. >> >> "In other words, when computing >> paths for a >> given algorithm, the transit nodes MUST compute the algorithm X on >> the IGP topology, regardless of the support of the algorithm X by the >> nodes in that topology." >> >> This sentence could be interpreted as saying that transit nodes must compute >> all algorithms advertised by any node in the topology, even if the transit >> node doesn't support the algorithm. This sentence doesn't make sense to me. >> >> A simple solution would be to delete this second sentence. > > I’d go for it. > > Thanks. > s. > > >> However, other clarifying text would be another solution. >> >> Thanks, >> Chris >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
