Bruno - In Section 3.2.5 of the draft:
" ... For other sources, It may seem intuitive to assign priority based on point of origination (e.g. intra-area preferred over inter-area, prefix reachability advertisements preferred over SRMS advertisements, etc.). However, any such policy makes it more likely that inconsistent choices will be made by routers in the network and increase the likelihood of forwarding loops or blackholes." If this point is agreed to then changes to the IGP drafts - such as the IS-IS SR draft section that you quoted (actually Section 2.4.5 of that draft) - would be necessary. So yes - it is our intent to have the protocol drafts changed if the conflict resolution language in this area is accepted. Les > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, October 22, 2015 9:00 AM > To: Les Ginsberg (ginsberg) > Cc: [email protected] > Subject: RE: New Version Notification for draft-ginsberg-spring-conflict- > resolution-00.txt > > Les, > > As an individual contributor, I have a clarification question regarding > Segment > Identifier Conflicts > https://tools.ietf.org/html/draft-ginsberg-spring-conflict-resolution- > 00#section-3 > > In the IGP, (Prefix, SID) mapping may be advertised via either Prefix-SID > (sub-TLV attached to an IP Prefix) or Mapping Server (Mapping Server Prefix- > SID in the Binding TLV). > The draft generalizes both by defining and using a generalized mapping > entry. > Hence the draft seems to make no distinction between Prefix-SID and > Remote-Binding SID advertised by the Mapping Server. Is this a correct > understanding? > > OTOH, the "IS-IS Extensions for Segment Routing" IS-IS WG draft, specify > that a distinction must be made: > " For a given prefix, if both a MS entry with its Prefix-SID Sub-TLV > and a Prefix TLV (e.g.: TLV135) with its Prefix-SID are received, the > Prefix-SID advertised within the Prefix TLV MUST be preferred while > the MS entry MUST be ignored." > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-06#section- > 3.6.1 > > So is your intention to: > - change the IS-IS specification to remove this rule (preference for > Prefix-SID > Sub-TLV)? > - or adapt your draft to accommodate for this rule? > > Thanks, > Regards, > Bruno > > > From: Les Ginsberg (ginsberg) > Sent: Wednesday, October 14, 2015 8:44 > > PM Folks - > > > > Would like to call your attention to this new draft. > > > > Les > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Wednesday, October 14, 2015 10:57 AM > > To: Peter Psenak (ppsenak); Les Ginsberg (ginsberg); Stefano Previdi > > (sprevidi) > > Subject: New Version Notification for draft-ginsberg-spring-conflict- > > resolution-00.txt > > > > > > A new version of I-D, draft-ginsberg-spring-conflict-resolution-00.txt > > has been successfully submitted by Les Ginsberg and posted to the IETF > > repository. > > > > Name: draft-ginsberg-spring-conflict-resolution > > Revision: 00 > > Title: Segment Routing Conflict Resolution > > Document date: 2015-10-14 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-ginsberg-spring- > conflict- > > resolution-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict- > > resolution/ > > Htmlized: https://tools.ietf.org/html/draft-ginsberg-spring-conflict- > > resolution-00 > > > > > > Abstract: > > In support of Segment Routing (SR) routing protocols advertise a > > variety of identifiers used to define the segments which direct > > forwarding of packets. In cases where the information advertised by > > a given protocol instance is either internally inconsistent or > > conflicts with advertisements from another protocol instance a means > > of achieving consistent forwarding behavior in the network is > > required. This document defines the policies used to resolve these > > occurrences. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
