Les, Thanks for the clarification with regarding to the meaning of SID.
Now, if the draft considers index, I'm afraid comparing index from different protocols (using different SRGB) is meaningless. e.g. IGP1: SRGB: 1000-2000 Mapping entry: (PFX, 1.1.1.1/32, 1, 1, 0, 0) IGP2: SRGB: 2000-3000 Mapping entry: (PFX, 2.2.2.2/32, 1, 1, 0, 0) In this example, looking at the index, there is a SID conflict as the same index is given to 2 prefixes. However, what matters is the conflict in the forwarding table. And in the MPLS one, the first mapping uses label 1001 while the second mapping uses labels 2001, so there is no conflict. More importantly, we can also craft an example where SID index do not conflict, while MPLS label conflict. Thanks, -- Bruno > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:[email protected]] > Sent: Tuesday, July 05, 2016 9:22 AM > To: DECRAENE Bruno IMT/OLN > Cc: [email protected] > Subject: RE: draft-ietf-spring-conflict-resolution-01 > > Bruno - > > I agree with your point. The draft is only discussing SIDs as index values. > We will add some > language to make that clear in the next revision. > Thanx. > > Les > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Monday, July 04, 2016 5:07 AM > > To: Les Ginsberg (ginsberg) > > Cc: [email protected] > > Subject: draft-ietf-spring-conflict-resolution-01 > > > > Hi Les, > > > > When talking about SID conflicts I think the document should spell out what > > it > > means by SID. > > > > Indeed, the architecture document defines SID as: > > "SID: a Segment Identifier. Examples of SIDs are: a MPLS label, an > > index value in a MPLS label space, an IPv6 address. Other types of > > SIDs can be defined in the future." > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#section-2 > > > > > > Indeed, when talking about SID conflicts > > - it matters that we do not compare apple and orange i.e. MPLS labels and > > index in SRGB. > > - we can't compare index from different protocols (e.g. OSPF & IS-IS) unless > > they advertise the same SRGB (which is only a specific case). > > > > > > So either the document considers that a SID is an "index" and in this case, > > we > > just can't compare them across protocols. > > Or it consider that a SID is a "MPLS labels" and in this case, as the IGP > > advertisement typically advertise index for global SIDs, there is a need to > > maps the received SID advertisement into the SRGB of the local node. > > > > This needs to be crystal clear. > > > > Thanks > > -- Bruno > > > > > > __________________________________________________________ > > __________________________________________________________ > > _____ > > > > 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. _________________________________________________________________________________________________________________________ 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
