Bruno -
When there is a conflict, the problem with trying to decide which advertisement
should be preferred is that there really is no way of knowing with certainty
which advertisement is the correct one. You have made certain assumptions below
as to what is the most advantageous preference - and in a given scenario your
assumptions may be quite reasonable. But here is an alternate scenario where I
think different assumptions could be made with an equal justification.
Again consider a brown field deployment. SRMS is used to advertise SIDs for
those nodes which are not yet SR capable. So, for Node X which has a Node
address of 1.1.1.1 SRMS might advertise:
1.1.1.1/32 100 range 1
This in fact is the correct value and all is working well.
At some point Node X gets upgraded to become SR capable. Part of the new
configuration is to assign the SID locally, but in doing so the operator makes
an error and configures:
1.1.1.1/32 200 range 1
Because the operator wants to do "make before break" the SRMS advertisement is
NOT removed when Node X is upgraded (there should be no rush to do so) - so we
have a conflict. Using your logic below, network would switch to using SID 200
for 1.1.1.1/32 - which in fact is the wrong choice.
I think this scenario is just as plausible as the scenario you presented.
You also seems to suggest that SRMS advertisements are far more likely to have
ranges greater than 1, something like:
1.1.1.1/32 100 range 100
but I think this assumption is questionable. For this to work, the following
things have to be true:
1)A significant set of the node addresses in the network have to fit within the
defined range
2)All the SIDs which are assigned (even locally) need to follow a monotonically
increasing mapping of address-to-SID
There may be networks where the above constraints will be met - but I have seen
enough deployments w irregular address assignments not to expect such
regularity.
I am not saying you are wrong - I am saying we can all come up with cases where
a given set of rules offers advantages - but as there are many sets of optimal
rules depending on how your network is deployed/upgraded - any argument of this
type is simply unresolvable. Every answer is advantageous under one set of
conditions and disadvantageous under another set.
HTH
Les
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, October 23, 2015 1:05 AM
> To: Les Ginsberg (ginsberg)
> Cc: [email protected]
> Subject: RE: New Version Notification for draft-ginsberg-spring-conflict-
> resolution-00.txt
>
> Les,
>
> Mapping Server (MS) is typically deployed in brown field deployments where
> some routers are not (yet) Segment Routing (SR) compliant, i.e. LDP only.
> In this scenario, the MS advertises the SIDs for the whole range of router's
> loopback. The SR routers also advertise their own SID in Prefix-SID sub-TLV
> attached to their loopback. Hence, in the nominal situation, SIDs are
> advertised both by loopback owners and by the MS.
>
> In this situation, with a _single_ erroneous advertisement from the MS (e.g.
> a typo from an operator or a software bug) _all_ the SID/Segments in the
> network becomes in conflict.
> draft-ginsberg-spring-conflict-resolution proposes 2 options:
> a) ignore the SID in conflict
> b) select one based on a tie-breaker
>
> "a" would result in all SID/Segments of the network to become invalidated.
> i.e. breaking the whole MPLS network. In my view, this is not a desirable
> reaction, especially in reaction to a single error.
> "b" seems better. Yet the tie-breaker does not make a distinction between
> Prefix-SID sub-TLV and MS advertisement. IMO Prefix-SID sub-TLV should be
> privileged for 2 reasons:
> - To learn a data from (node) X, I'd rather trust X itself rather than Y.
> Especially from X point of view. (IOW, let me speak for myself)
> - Prefix-SID sub-TLV advertises a single SID while MS advertise many.
> Assuming a single error (which seems reasonable as the network was
> running correctly before), it seems less risky to take the risk for a single
> SID
> rather than for the whole MS advertisement.
>
>
> That is also the opinion of draft-ietf-isis-segment-routing-extensions which
> already specify this behavior:
> 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.
>
>
> Bottom line, I don't understand why you are proposing to change this
> specification. Could you please elaborate on your reasons and challenge
> mines as needed?
>
> Thanks,
> Regards;
> Bruno
>
> > From: Les Ginsberg > Sent: Thursday, October 22, 2015 9:21 PM
> >
> > 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-resolutio
> > > n-
> > > 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#sec
> > > tion-
> > > 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.
>
>
> __________________________________________________________
> __________________________________________________________
> _____
>
> 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, France Telecom -
> 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 authorization.
> If you have received this email in error, please notify the sender and delete
> this message and its attachments.
> As emails may be altered, France Telecom - Orange shall not be liable if this
> message was modified, changed or falsified.
> Thank you.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
