Subject: [spring] FW: New Version Notification for draft-ginsberg-spring-conflict-resolution-00.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 14 Oct 2015 18:44:17 +0000

Folks -

Would like to call your attention to this new draft.

   Les

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
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

---

From: <[email-masked]>
Date: Thu, 22 Oct 2015 15:59:56 +0000

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 -
> 
> 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-masked]
> 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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 22 Oct 2015 19:20:47 +0000

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 22, 2015 9:00 AM
> To: Les Ginsberg (ginsberg)
> Cc: [email-masked]
> Subject: RE: New Version Notification for draft-ginsberg-spring-conflict-
> resolution-00.txt
> 
> Les,
> 
> 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).
> 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?
> 
> > From: Les Ginsberg (ginsberg) > Sent: Wednesday, October 14, 2015 8:44
> > PM Folks -
> >
> > URL:            https://www.ietf.org/internet-drafts/draft-ginsberg-spring-
> conflict-
> > resolution-00.txt
> > 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
> >
> __________________________________________________________
> __________________________________________________________
> _____
> 
> 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.

---

From: <[email-masked]>
Date: Fri, 23 Oct 2015 08:05:21 +0000

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 -
> 
> 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
> 
> 
> > As an individual contributor, I have a clarification question regarding
> Segment
> > Identifier Conflicts
> > - change the IS-IS specification to remove this rule (preference for Prefix-
> SID
> > Sub-TLV)?

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 23 Oct 2015 22:00:13 +0000

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

> Sent: Friday, October 23, 2015 1:05 AM
> 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.
> "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.
> 
> 
> 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
> 
> > 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
> >
> >
> > > Subject: RE: New Version Notification for
> > > draft-ginsberg-spring-conflict- resolution-00.txt
> > >
> > > Les,
> > >
> > > 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).
> > > Remote-Binding SID advertised by the Mapping Server. Is this a
> > > correct understanding?
> > >
> > > https://tools.ietf.org/html/draft-ietf-spring-segment-routing-06#sec
> > > tion-
> > > 3.6.1
> > >
> > > So is your intention to:
> > > > From: Les Ginsberg (ginsberg) > Sent: Wednesday, October 14, 2015
> > > > 8:44 PM Folks -
> > > >
> > > > 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
> > > > Status:         https://datatracker.ietf.org/doc/draft-ginsberg-spring-
> conflict-
> > > > resolution/
> > > 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
> > > 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.
> 
> 
> messages electroniques etant susceptibles d'alteration, France Telecom -
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci
> 
> used or copied without authorization.
> As emails may be altered, France Telecom - Orange shall not be liable if this
> message was modified, changed or falsified.
> Thank you.

---

From: <[email-masked]>
Date: Thu, 29 Oct 2015 11:37:53 +0000

Les,

> From: Les Ginsberg (ginsberg) [mailto:[email-masked]] > Sent: Saturday, October 24, 2015 12:00 AM
> 
> 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.

Mostly agreed.
But I'm not that concerned about finding "the correct one" or the good one.
I'm concerned about the consequences of the error handling behavior.
I'd like that we evaluate them and possibly minimize the adverse consequences.

In the scenario where the Mapping Server (MS) advertise range of SIDs, the error handling of draft-ginsberg-spring-conflict-resolution introduces a significant risk of breaking a significant part of the network. The error handling of draft-ietf-isis-segment-routing-extensions do not.
So I'd like to better understand why you are proposing to change the spec and the implementations, and why in this specific direction.

In your email, you are arguing that some network deployment of MS would not advertise range of SIDs, and in such condition the conflict and the consequences would be more limited. 
Ok, but evaluating a different scenario does not address my point.

Finally, you are discussing the relative popularity of both deployments. You are welcome to present data (facts) about this. If you don't, even though I could have arguments, I don't see the value of discussing this because I don't think that this is the point. Even if MS range are used by 20% of SPRING deployments, taking the risk to break the connectivity of this range of routers (e.g. 100 routers or more), in case of a single error (typo or bug) does not seem desirable.

In summary, as part of the error handling discussion, I'd like that we evaluate the consequences and possibly minimize the adverse ones. A network wide breakage seems a large one to me.

-- Bruno

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