Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

From: Martin Vigoureux <[email-masked]>
Date: Mon, 10 Jul 2017 14:58:00 +0200

WG,

We are half-way through the WG Last Call and I am very surprised to only 
see a single answer to it.

I am not sure I'll move this forward with only silence as support.

-m

Le 29/06/2017 à 15:28, Martin Vigoureux a écrit :
> Hello Working Group,
>
> This email starts a Working Group Last Call on
> draft-ietf-spring-conflict-resolution-04 [1] which is considered mature
> and ready for a final working group review.
>
> ¤ Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *21st of July*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
>
> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has
> been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879,
> 3669 and 5378 for more details).
>
> If you are listed as an Author or Contributor of
> draft-ietf-spring-conflict-resolution-04 please respond to this email
> and indicate whether or not you are aware of any relevant IPR.
>
> Note that, as of today, no IPR has been disclosed against this document
> or its earlier versions.
>
> Thank you,
> Martin
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: stefano previdi <[email-masked]>
Date: Mon, 10 Jul 2017 16:12:43 +0200

I strongly support the publication of this draft.

I’m  not aware of any IPR related to the mechanisms described in the draft.

s.

> On Jun 29, 2017, at 3:28 PM, Martin Vigoureux <[email-masked]> wrote:
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on draft-ietf-spring-conflict-resolution-04 [1] which is considered mature and ready for a final working group review.
> 
> Note that this is *not only* a call for comments on the document; it is also a call for support (or not) to publish this document as a Proposed Standard RFC.
> 
> ¤ *Coincidentally*, we are also polling for knowledge of any IPR that applies to draft-ietf-spring-conflict-resolution, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> draft-ietf-spring-conflict-resolution-04 please respond to this email and indicate whether or not you are aware of any relevant IPR.
> 
> Note that, as of today, no IPR has been disclosed against this document or its earlier versions.
> 
> Thank you,
> Martin
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jul 2017 14:20:53 +0000

A few comments from my perspective as co-author.

This is a problem for which it is important to have a standardized solution, so moving the draft forward is an important part of successfully deploying Segment Routing over an MPLS dataplane. 

This draft has been the subject of lively debate over the last 1.5 years - and I have contributed to that debate in part because of concerns about the complexity of the defined solution ("ignore overlap only").

Since the draft was last presented in Seoul I have spent time discussing the requirements with multiple operators and I have become convinced that the deployment cases do indeed require the solution that is defined in the draft. I therefore support the draft without reservation and encourage others to do the same. I think the latest version (note it is V5 - which corrected a few errors that existed in V4) is a mature document which addresses real world deployment cases.

Martin - I am not aware of any IPR relevant to this draft.

    Les

> -----Original Message-----
> From: spring [mailto:[email-masked]] On Behalf Of Martin
> Vigoureux
> Sent: Monday, July 10, 2017 5:58 AM
> To: [email-masked]
> Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution
> 
> WG,
> 
> We are half-way through the WG Last Call and I am very surprised to only see
> a single answer to it.
> 
> > draft-ietf-spring-conflict-resolution-04 [1] which is considered
> > mature and ready for a final working group review.
> >
> > version yet, and send your comments to the list, no later than *21st
> > of July*.
> > Note that this is *not only* a call for comments on the document; it
> > is also a call for support (or not) to publish this document as a
> > Proposed Standard RFC.
> >
> > applies to draft-ietf-spring-conflict-resolution, to ensure that IPR
> > has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
> > 4879,
> > [1]
> > https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution
> > /
> >

---

From: "Gaurav Dawra (gdawra)" <[email-masked]>
Date: Mon, 10 Jul 2017 21:50:15 +0000

+1

Support the publication of this draft.

Regards,
 
Gaurav

On 7/10/17, 7:12 AM, "spring on behalf of stefano previdi" <[email-masked] on behalf of [email-masked]> wrote:

    
    s.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 11 Jul 2017 01:27:05 +0000

Support.

Thanks,
Nagendra

On 6/29/17, 9:28 AM, "spring on behalf of Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Working Group,

    

    
    Thank you,
    Martin

---

From: [email-masked]
Date: Tue, 11 Jul 2017 08:00:09 +0200

Hello Martin,
I support the draft as co-author. I am not aware of any relevant IPR.
Thanks,
Martin

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 11 Jul 2017 06:26:27 +0000

Yes/support
On Mon, Jul 10, 2017 at 23:00 <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/
> >>

---

From: Peter Psenak <[email-masked]>
Date: Tue, 11 Jul 2017 10:04:12 +0200

Support as co-author.

I am not aware of any IPR relevant to this draft.

Peter

On 10/07/17 14:58 , Martin Vigoureux wrote:
> .

---

From: <[email-masked]>
Date: Tue, 11 Jul 2017 10:41:32 +0000

Martin,

As an individual contributor, I have read all versions of this document and support progressing -05 to the IESG.

Unless we believe error never happen, a standardized conflict resolution procedure is needed to safely deploy MPLS Segment Routing in a multi-vendor network. Some implementations are waiting for this document to be advanced to RFC in order to implement the stable behavior.

IMO, -05 is ready:
- "SR Global Block Inconsistency" is ready for months (>1 year)
- "SR-MPLS Segment Identifier Conflicts" required more time to progress and explored multiple options, but after much work from the authors, -05 seems ready to me. For forwarding nodes, it defines a per FEC preference rule limiting the conflict resolution to only the FEC (prefix/SID) which indeed face conflicting advertisements. For non-forwarding nodes (e.g. network controllers, PCE...), it allows more freedom in the SID to be used (or discarded), including a simplified procedure disregarding all conflicting entries.

Thanks,
Regards,
--Bruno
 > From: spring [mailto:[email-masked]] On Behalf Of Martin Vigoureux
 > Sent: Monday, July 10, 2017 2:58 PM
 > To: [email-masked]

_________________________________________________________________________________________________________________________

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: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Jul 2017 19:01:30 +0000

I fully support this document and, now that we have reached consensus,
believe we should publish it before anyone changes their minds…

I have reviewed the -05 version and have the following comments:

    1. Section 3.1 - Make it clear that a larger preference is more
preferred. While this is stated in section 3.3, it must be inferred in
section 3.1 to understand the text.
    2. Expand acronyms on first use, e.g., SID and SRMS.
    3. In section 3.8, do we want to suggest that the conflicting
configuration not be “accepted” rather than not “advertised”?

I also have a number of editorial suggestions which I will sent to the
authors offline. 

Thanks,
Acee 

On 7/11/17, 6:41 AM, "spring on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Unless we believe error never happen, a standardized conflict resolution
>procedure is needed to safely deploy MPLS Segment Routing in a
>multi-vendor network. Some implementations are waiting for this document
>to be advanced to RFC in order to implement the stable behavior.
>
>IMO, -05 is ready:
>- "SR-MPLS Segment Identifier Conflicts" required more time to progress
>and explored multiple options, but after much work from the authors, -05
>seems ready to me. For forwarding nodes, it defines a per FEC preference
>rule limiting the conflict resolution to only the FEC (prefix/SID) which
>indeed face conflicting advertisements. For non-forwarding nodes (e.g.
>network controllers, PCE...), it allows more freedom in the SID to be
>used (or discarded), including a simplified procedure disregarding all
>conflicting entries.
>
>Thanks,
>Regards,
>--Bruno
>mature
>is
>has
>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jul 2017 19:46:13 +0000

Acee -

Thanx for your support abd your comments.
Responses inline.

> From: spring [mailto:[email-masked]] On Behalf Of Acee Lindem
> (acee)
> Sent: Tuesday, July 11, 2017 12:02 PM
> To: [email-masked]; Martin Vigoureux
> Cc: [email-masked]
>     1. Section 3.1 - Make it clear that a larger preference is more preferred.
> While this is stated in section 3.3, it must be inferred in section 3.1 to
> understand the text.

[Les:] Agreed.

>     2. Expand acronyms on first use, e.g., SID and SRMS.

[Les:] ACK

>     3. In section 3.8, do we want to suggest that the conflicting configuration
> not be “accepted” rather than not “advertised”?
> 
[Les:] I don't think so.

While it is possible that such a check could be run as each configuration line is entered, stating that this is the way it should be done constrains an implementation unnecessarily. That is certainly a reasonable way of implementing it, but not the only way. For example,  a node could allow SRMS configuration to be entered locally without validating it until the user indicates  "configuration complete". Then  the conflict resolution algorithm could be run "as if the configured values were advertised" to detect conflicts before advertisement is enabled.

I don’t think we care which way an implementation chooses to go - the useful bit is that the check is performed BEFORE the config is advertised and starts to be used.

> I also have a number of editorial suggestions which I will sent to the authors
> offline.

[Les:] Thanx for those as well.

    Les

> >Unless we believe error never happen, a standardized conflict
> >resolution procedure is needed to safely deploy MPLS Segment Routing in
> >a multi-vendor network. Some implementations are waiting for this
> >document to be advanced to RFC in order to implement the stable
> behavior.
> >
> >IMO, -05 is ready:
> >and explored multiple options, but after much work from the authors,
> >-05 seems ready to me. For forwarding nodes, it defines a per FEC
> >preference rule limiting the conflict resolution to only the FEC
> >(prefix/SID) which indeed face conflicting advertisements. For non-
> forwarding nodes (e.g.
> > > > ¤ *Coincidentally*, we are also polling for knowledge of any IPR
> > > > that applies to draft-ietf-spring-conflict-resolution, to ensure
> > > > that IPR
> >has
> > > > draft-ietf-spring-conflict-resolution-04 please respond to this
> > > > email and indicate whether or not you are aware of any relevant IPR.
> > > >
> >_________________________________________________________
> ______________
> >___ _______________________________________________
> >
> >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.
> >
> >information that may be protected by law; they should not be
> >distributed, used or copied without authorisation.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 11 Jul 2017 19:49:30 +0000

Hi Les, 

I agree with the responses.

On 7/11/17, 3:46 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

>>preferred.
>>configuration
>While it is possible that such a check could be run as each configuration
>line is entered, stating that this is the way it should be done
>constrains an implementation unnecessarily. That is certainly a
>reasonable way of implementing it, but not the only way. For example,  a
>node could allow SRMS configuration to be entered locally without
>validating it until the user indicates  "configuration complete". Then
>the conflict resolution algorithm could be run "as if the configured
>values were advertised" to detect conflicts before advertisement is
>enabled.
>
>I don’t think we care which way an implementation chooses to go - the
>useful bit is that the check is performed BEFORE the config is advertised
>and starts to be used.

That is reasonable.

Thanks,
Acee

>>authors

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 14 Jul 2017 16:51:39 +0200

Strong support from me, too.

 From an operator's point of view this is really needed.

Best regards, Martin

Am 10.07.17 um 14:58 schrieb Martin Vigoureux:
>
> WG,
>
> We are half-way through the WG Last Call and I am very surprised to 
> only see a single answer to it.
>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 21 Jul 2017 06:44:23 +0000

SPRING WG,

Conflict resolution is an important problem to solve and it is important to 
Standardize this draft. 

I generally support the draft but have a few major comments which I hope the authors will work on.

 1.Conflict resolution and forwarding

            Section 3.4 has the statement
            "Active Entries in the database may be used in forwarding."
	
             This is a very loose statement which does not enforce implementations to program the forwarding plane
	with the active database entries. 
	This does not ensure traffic drops are minimized.
	
	The Forwarding plane programming aspects are completely missing in the document.
	A separate section is needed which describes the different aspects of programming the forwarding plane.
	
2.  Protocol independent resolution and impact on network migrations
             In case of network migration from one protocol to other for ex: OSPF-SR to ISIS-SR,
             it is useful to associate protocol preferences on a local node to the SID advertisement
	and feed into the conflict resolution. This would make sure the conflicts will always 
	have a winner which is an advertisement from protocol with preferred admin-distance.
		
	There is need for introducing another preference value specific to protocol preference
	and make it the top rule in the preference rule hierarchy.
	
	This would also solve the issue of MT-ID numbers being different in different protocols
	as the SIDs would be compared within a protocol advertisement.

3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF areas, It's possible that the
     conflicts are not visible in entire domain but are visible only on the border router as the border routers
     have the database of both domains.
    The conflict resolution preference Rules should be enhanced to include the Level information in the preference rule.
    A new parameter called sub-domain should be defined.
		
		One could propose using existing SRMS preference values and assigning prefixes with preference values
	based on levels they are advertised in. This introduces more complex configuration requirements on the 
	network. The objective of this draft is to achieve consistent behaviours in case of misconfigurations and
	introducing more configurations as a solution does not help.

		Based on the Advertisement originated in ISIS Level or OSPF area below values are defined.
		
		Level 1 , non-zero OSPF area =1
		Level 2, OSPF Area 0 = 2
		Non IGPs set subdomain = 0
         		
				Preference algorithm is changed as

    1. Higher protocol preference wins
   2. smaller sub-domain wins				
    3. Higher srms preference value wins 
    4. Smaller range wins
    5.IPv6 entry wins over IPv4 entry
    6.Longer prefix length wins
    7.Smaller starting address (considered as an unsigned integer
       value) wins
    8.Smaller algorithm wins  
    9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison. since the all these rules are applied
	                                        within protocol it's safe to compare topology IDs
    10. Smaller starting SID wins

Rgds
Shraddha

-----Original Message-----
From: Martin Horneffer [mailto:[email-masked]] 
Sent: Friday, July 14, 2017 8:22 PM
To: [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Best regards, Martin

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 24 Jul 2017 20:27:08 +0000

Shraddha -

Thanx for the comments - responses inline.

> From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde

> Sent: Thursday, July 20, 2017 11:44 PM

> To: [email-masked]<mailto:[email-masked]>

> I generally support the draft but have a few major comments which I hope

> the authors will work on.

>              This is a very loose statement which does not enforce

> implementations to program the forwarding plane

[Les:] Conflict resolution is only determining which entries are eligible to be used in forwarding. This does not mean that all "active" entries will be used . The most obvious example (but not the only possible one) of this is an SRMS entry that is associated with a prefix which is not actually reachable. So the language in the draft is intentional and is correct.

>             The Forwarding plane programming aspects are completely missing in

> the document.

>             A separate section is needed which describes the different aspects

> of programming the forwarding plane.

[Les:] This is NOT in scope for this draft. If you want a description of how SR MPLS forwarding works please see draft-ietf-spring-segment-routing-mpls.

>              In case of network migration from one protocol to other for ex: OSPF-

> SR to ISIS-SR,

>              it is useful to associate protocol preferences on a local node to the SID

> advertisement

>             and feed into the conflict resolution. This would make sure the

> conflicts will always

>             have a winner which is an advertisement from protocol with

> preferred admin-distance.

>             There is need for introducing another preference value specific to

> protocol preference

[Les:] "admin distance" is a locally defined preference which is not advertised. It is therefore not possible to include it as a parameter in an algorithm which requires a consistent answer on all nodes throughout the network.

>             This would also solve the issue of MT-ID numbers being different in

> different protocols

>             as the SIDs would be compared within a protocol advertisement.

[Les:] I do not understand what relationship you see between "protocol preference" and "MT-ID".

MT-ID values are scoped by  the protocol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to be used by different protocols when advertising routes for the same physical topology. This is why the draft's use of "topology" is not as MTID but rather as a locally scoped identifier. From Section 3:

" Note: Topology is a locally scoped identifier assigned by each

   router.  Although it may have an association with Multitopology

   Identifiers (MTID) advertised by routing protocols it is NOT

   equivalent to these identifiers.  MTIDs are scoped by a given routing

   protocol.  MTID ranges are protocol specific and there may be

   standardized protocol specific MTID assignments for topologies of a

   specific type (e.g., an AFI specific topology).  As mapping entries

   can be sourced from multiple protocols it is not possible to use a

   network scoped identifier for a topology when storing mapping entries

   in the local database."

Topology is then used to detect different scopes for a mapping entry - which may result in a SID conflict if the same SID is used in different topologies, but it cannot be used as a tiebreaker since its value is local and any preference (e.g., higher value wins)  is not guaranteed to result in consistent answers on all nodes in the network. Which is why we have Section 3.3 Rule #8:

   "8.  If topology IDs are NOT identical both entries MUST be ignored"

> 3. In case of hierarchical IGP networks with multiple ISIS Levels or OSPF areas,

> It's possible that the

>      conflicts are not visible in entire domain but are visible only on the border

> router as the border routers

>     The conflict resolution preference Rules should be enhanced to include the

> Level information in the preference rule.

>                             One could propose using existing SRMS preference values

> and assigning prefixes with preference values

>             based on levels they are advertised in. This introduces more complex

> configuration requirements on the

>             network. The objective of this draft is to achieve consistent

> behaviours in case of misconfigurations and

>                             Based on the Advertisement originated in ISIS Level or OSPF

> area below values are defined.

>     1. Higher protocol preference wins

[Les:] I have explained above why protocol preference cannot be used.

>     9. Smaller topology Id wins >>>>>>>>>>..Moved above SID comparison.

> since the all these rules are applied

>                                                     within protocol it's safe to compare topology IDs

[Les:] No - it isn't - as explained above.

[Les:] SIDs are assigned either by the node(s) originating the prefix reachability advertisement or by SRMS advertisements. The latter are level/area agnostic - and even you are agreeing that we should not change that.

There is then no reason for the SID to be altered as it is advertised into different areas.  Which leads us to the conclusion that SIDs are not level/area specific.

If your concern is that border routers who may have more entries in their SID database than intra-area routers may come to a different conclusion as regards conflicts - I agree with you - but I do not believe your proposal resolves the problem.

Consider the following simple topology:

A1-----A2------B2-----B1

All nodes run IS-IS.

A1 is a Level-1 router in Area A. It advertises: 1.1.1.1/32 SID 100

A2 is a Level-1-2 router in Area A

B1 is a Level-1 router in Area B. It advertises: 2.2.2.2/32 SID 100

B2 is a Level-1-2 router in Area B

If Level 1 routes are leaked into Level 2 but NOT down into Level 1, we have the following SID databases on the four routers:

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Here are the active entries on each node comparing the two algorithms

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

There is a tradeoff here between being able to forward some inter-area traffic entering the network via the L2 sub-domain but impacting some intra-area traffic  vs being able to forward all intra-area traffic but no inter-area traffic.

Not clear which strategy is "better" - but it is clear that neither strategy eliminates all issues. Given that the same SID database will NOT exist on all routers in multi-area deployments some risk exists and cannot be totally eliminated.

I do agree that we should try to minimize the use of conflicting SIDs for inter-area traffic. What is lacking in the draft is a statement that conflicting SIDs should not be leaked out of an area. I will work on a statement in the draft to make that point clear.

Thanx for bringing this issue up.

    Les

> To: [email-masked]<mailto:[email-masked]>

> >> Note that, as of today, no IPR has been disclosed against this

> >> document or its earlier versions.

> >> https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolutio

> >> n/

> >> [email-masked]<mailto:[email-masked]>

> > [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 28 Jul 2017 03:30:52 +0000

Thanks for the response.

   It is important  to keep the network functioning correctly in case of transitioning from
   one protocol to the other.

   Let us assume a case of OSPF SR network transitioning to ISIS SR network.
   Most typical transitioning technique is ships in the night where both protocols will be
   enabled in the network with OSPF having better preference and the issue in ISIS routing do
   not affect the traffic. Once the ISIS deployment is complete, the traffic will be switched
   to ISIS by changing preference.

   In case of OSPF-SR transitioning to ISIS SR, because of the conflict resolution
   rules that the conflicts are protocol independent, it is possible that config mistakes in ISIS
   will bring down the routes in OSPF. The ISIS topology and OSPF topology is not expected to be congruent
   during transition,
   so the conflicts seen on each node combining the two views will not be similar.
   This has potential to cause routing loops/ traffic drops in the network.

   I suggest to add the protocol-preference as one of the parameters in the preference algorithm
   with this being on the top of the list.
   The resultant conflict resolution will be consistent on ISIS topology and OSPF topology
  and is the best suited model for ships in the night transitions.

Pls see inline for other responses.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Shraddha -

<Shraddha> The language in the draft is ambiguous and it does not help achieve consistent forwarding behavior across implementations.

                      Prefixes that are not reachable may not be used in forwarding which is acceptable but the draft does not mandate that the reachable prefixes which are active

                    MUST be programmed. Normative language is necessary in the draft w.r.t using active entries in forwarding.

<Shraddha> The point I am bringing up here is not how SR MPLS forwarding works. It is w.r.t to programming the forwarding plane when there is a conflict.

The abstract section has below statement

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

If the draft is not going to address the forwarding plane detail w.r.t conflicting entries it is definitely not meeting the

The objective described above.

Take an example of a conflict

(192, 192.0.2.1/32, 200, 1, 0, 0)

   (192, 192.0.2.222/32, 200, 1, 0, 0)

   SID 200 has been assigned to 192.0.2.1/32 by the

   first advertisement.

   The second advertisement assigns SID 200 to 192.0.2.222/32.

In this case after applying the preference rules

(192, 192.0.2.1/32, 200, 1, 0, 0)

 Becomes active entry.

As per the text in the draft," it may be used in forwarding" so some implementations

May choose to program forwarding plane and some may not which does not give a consistent forwarding behavior

Across implementations.

<Shraddha>  In migration cases, topologies across two different protocols are not congruent causing inconsistent behavior.

                       Using admin-distance as an input parameter keeps the conflict resolution with-in the protocol and guarantees

                      Consistent behavior across all the nodes corresponding to that protocol.

                     The drafts tries to address this scenario partially between IGP and BGP by suggesting preference values. But that does not solve the

Problem between two different IGPs.

   in the local database."

<Shraddha> Lets keep this discussion on-hold until we decide on the protocol preference and migration issues.

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

<Shraddha> Not leaking the conflicting SIDs makes sense. But Even if the conflicting SIDs are not leaked across boundaries, there is still a possibility that inter-area/intra-area traffic gets misforwarded at the area boundary. This issue can cause potential security risks as the traffic can get delivered to unintended node.The best option is to ignore both conflicting entries when they belong to different area/level

    2. If the entries belong to different sub-domains ignore both entries

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

---

From: <[email-masked]>
Date: Fri, 28 Jul 2017 10:42:55 +0000

Always as an individual contributor, thanks to Shraddha comments, a few point below

1)      Conflict resolution per LSDB or across LSDB
I've haven't re-read all text, but I'm not certain that the current text specifies whether the conflict resolution must be run on a per LSDB basis, or across all LSDB. I think we'll agree that we all implementation be consistent on this point, hence this need to be specified.

2)      Conflict resolution per LSDB or across LSDB ?
I believe Les means across LSDB but Shraddha raised interesting questions regarding this, using area/level or IGP transitioning use cases.

a)      Thesis: On the "per LSDB" side:
Running conflict resolution on a per LSDB ensure that this conflict resolution runs on the same data, which is required to get the same result. Otherwise, as per Shraddha's points, (L1L2 routers, different OSPF & IS-IS topologies) we have inconsistencies.

b)      Antithesis: On the "across LSDB" side:
We need consistency across the network, hence across LSDBs.

c)       Synthesis
We seem to have a tradeoff issue as we can't have both. However, it seems to me that the consistency issue with different LSDB is not specific to SR conflict resolution. We can have it with regular IP routing/forwarding. Hence this may favor enforcing consistency within LSDB which we can still enforce.

Some (two) details inlined [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Thanks for the response.

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, July 25, 2017 1:57 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

MT-ID values are scoped by  the protocol which uses them. For example, OSPFv2 supports a 7 bit MT-ID while IS-IS supports a 12 bit MT-ID. It is therefore possible for non-matching MTIDs to be used by different protocols when advertising routes for the same physical topology. This is why the draft's use of "topology" is not as MTID but rather as a locally scoped identifier. >From Section 3:

   in the local database."

[Les:] SIDs are assigned either by the node(s) originating the prefix reachability advertisement or by SRMS advertisements. The latter are level/area agnostic

[Bruno] I'm not sure to undertand what is meant by "level/area agnostic". In IS-IS, SRMS advertisements seems to be able to be scoped on a per area/level basis using the S-flag

https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-13#section-2.4

- and even you are agreeing that we should not change that.

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

[Bruno] For MPLS transit, the ABR knows whether the traffic leaves the area or not. If it does, it could take into account both SIDs: incoming label from the SID of the incoming area, outgoing label from the SID of the outgoing area. Not that different from LDP which select the label on a per neighbor basis...even though LDP does not do routing i.e. does not natively have this information.

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 28 Jul 2017 22:18:22 +0000

Shraddha -

Protocol preference (commonly known as admin distance) is a locally configured value which is not advertised. Therefore there is no way for one node to know what preference another node has assigned to different protocols. If admin distance is used as part of the conflict resolution algorithm there is therefore no way to guarantee consistency on different nodes.  I have pointed this out previously - you have not acknowledged this.

Let's use your example below  - transitioning a network from OSPF to IS-IS - to show how using admin distance in the conflict resolution algorithm results in inconsistency.

Consider the following simple network:

A---B---C---D

Node A originates the prefix 1.1.1.1/32.
The network is using OSPF and OSPF is advertising SID 100 for 1.1.1.1. All nodes use SID 100 in their forwarding planes.

The customer wants to transition to IS-IS, and so starts configuring IS-IS on each node, but makes sure that initially  the admin distance assigned to IS-IS is greater than (less preferred) than that of OSPF.
In configuring IS-IS the customer makes a mistake and assigns SID 200 to 1.1.1.1.  (This presumes a protocol centric model for configuring SIDs - which I do not recommend - but let's ignore that for now.)

The customer is now ready to switch the network to IS-IS and starts to do so by changing the admin distance of IS-IS on Node D to be more preferred.
Using your proposal, Node D would now choose SID 200 as the Active SID for prefix 1.1.1.1.
But on Node C, OSPF is still the more preferred protocol, so on Node C SID 100 is being used for 1.1.1.1.

As soon as the admin distance change is made on Node D, the label associated with SID 200 will be programmed in forwarding to send traffic addressed to 1.1.1.1 via Node C.
But in Node C's forwarding plane SID 100 is being used, so when the packet arrives at Node C it will get dropped.

Contrast that with the behavior  when using algorithm currently defined in the draft. In the presence of the two conflicting advertisements:

(192, 1.1.1.1/32, 100, 1, 0, 0)
(192, 1.1.1.1/32, 200, 1, 0, 0)

SID 100 will be declared the winner (Rule #7: Lower SID wins)
This will be true regardless of which protocol is the "best" at any moment in time on any node. So even when IS-IS becomes the winning protocol on Node D the forwarding plane continues to use SID 100 on all nodes. Therefore, forwarding is not compromised when transitioning from one protocol to another.

Of course, a far better strategy is to make SID configuration independent of the protocol. Then when introducing a new protocol both protocols would obtain and advertise the same SID value for the same prefix and the problem state described above would simply never occur.

HTH clarify why your suggestion is not viable.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Thursday, July 27, 2017 8:31 PM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Thanks for the response.

Rgds
Shraddha

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

   in the local database."

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 28 Jul 2017 22:25:12 +0000

Bruno -

Please reread "Section 3.7.  Guaranteeing Database Consistency.".
The draft is explicit that "entries advertised by all routing protocols MUST be included".

Also please read my recent response to  Shraddha as regards the pitfalls of using protocol specific databases for conflict resolution.

    Les

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

c)       Synthesis

From: spring [mailto:[email-masked]] On Behalf Of Shraddha Hegde
Sent: Friday, July 28, 2017 5:31 AM
To: Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Thanks for the response.

Rgds
Shraddha

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

   in the local database."

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

Thank you.

---

From: <[email-masked]>
Date: Mon, 31 Jul 2017 16:55:20 +0000

Les,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, July 29, 2017 12:25 AM
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Bruno -

 [Bruno] ok, thanks.

Also please read my recent response to  Shraddha as regards the pitfalls of using protocol specific databases for conflict resolution.
 [Bruno]
Do we agree on the problems arising when running the conflict resolution across multiple databases? (point 2.b below; in short as different nodes may run a different set of LSDBs, we can't reach consistent resolution) I believe so since you acknowledged the problem for the specific case of L1L2 nodes running 2 LSDBs.
I'm not sure that we can easily solve this problem, so at this stage, the algorithm seems good enough to me. However, IMHO the document should acknowledge the problem (e.g. in section 3.7)  for network operators to be aware of this issue and possibly provides some operational recommendation to minimize this. e.g.
- during IGP migrations, if not all nodes runs both IGPs, only advertise SID in a single IGP (the one used by all nodes).
- if applicable, prefer the flooding of SRMS advertisements across all areas
...

> What is lacking in the draft is a statement that conflicting SIDs should not be leaked out of an area
Good point, thanks.
If conflicting SIDs are re-advertised in L2 from multiple ABRs, there may be a risk of oscillations as both ABR withdraw and then re-advertise the SID. Possibly a tie break may help (or whatever option)

Thanks,
Regards,
--Bruno

    Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, July 28, 2017 3:43 AM
To: Shraddha Hegde; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

c)       Synthesis

Thanks for the response.

Rgds
Shraddha

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

   in the local database."

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

Thank you.

---

From: Shraddha Hegde <[email-masked]>
Date: Mon, 31 Jul 2017 17:26:34 +0000

Les,

When the protocol preference is different across different nodes OSPF and ISIS do not guarantee that there would not be traffic loops/drops.
The misconfigurations can cause traffic loops when the different protocols are active on different nodes even without SR so I don't see a point
In bringing up such a case for comparison.

Lets keep the solution to the problem aside for a moment. Do you agree that the draft  algorithm in current form has potential issues
When database is not consistent across all nodes? Do you think this is a problem we should try to solve?

Pls see inline for details...

Rgds
Shraddha

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Saturday, July 29, 2017 3:48 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Shraddha -

A---B---C---D

The customer is now ready to switch the network to IS-IS and starts to do so by changing the admin distance of IS-IS on Node D to be more preferred.
Using your proposal, Node D would now choose SID 200 as the Active SID for prefix 1.1.1.1.
But on Node C, OSPF is still the more preferred protocol, so on Node C SID 100 is being used for 1.1.1.1.
<Shraddha> As I pointed out different protocol being active on different nodes should be operator's responsibility and is not addressed
                       Even when SR is not enabled.

                       Whereas, it is important to make sure during migration when only a few nodes have ISIS enabled, it does not impact OSPF.
                        The draft algorithm does not gracefully handle this and makes migrations much more painful by affecting the running network
                         Due to misconfigs in the new protocol.

SID 100 will be declared the winner (Rule #7: Lower SID wins)
This will be true regardless of which protocol is the "best" at any moment in time on any node. So even when IS-IS becomes the winning protocol on Node D the forwarding plane continues to use SID 100 on all nodes. Therefore, forwarding is not compromised when transitioning from one protocol to another.
<Shraddha> You have chosen a situation that is favoring the algorithm in the draft.
                       Consider
                         (192, 1.1.1.1/32, 200, 1, 0, 0)  >>>>>>>>>>>>OSPF
                         (192, 1.1.1.1/32, 100, 1, 0, 0)  >>>>>>>>>>>>ISIS
                       Consider when the customer has configured ISIS on only a few nodes. On some nodes ISIS advertisement wins and uses 100 to forward but
                       Gets dropped on next node as ISIS isn't running .

<Shraddha> There are so many nuances to migration. One protocol doesn't behave same as the other simply because these are two different implementations and would have some different behaviors. It is always a best practice to keep the new protocol getting configured separate from the existing protocol, bring up the new protocol , verify all is well and then switchover to new protocol on all nodes. In this regard some may prefer keeping the SIDs advertised in two protocols separate and so its important to address the case when different SIDs are advertised in the protocol.

   Les

Thanks for the response.

Rgds
Shraddha

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

   in the local database."

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 31 Jul 2017 19:32:09 +0000

Shraddha -

All the rules defined in the draft are based on advertised values - which means if two nodes have the same database and use the same set of rules they will reach the same decision as regards conflict resolution.
You cannot improve upon this by introducing a new rule based upon a value (protocol administrative distance) which is neither guaranteed to be the same on all nodes nor advertised. The only thing this accomplishes is to introduce the potential for  further inconsistency.

If we cannot agree on this, then all the rest of the details discussed below do not matter.

There is an important point - which the draft does explicitly state in Section 3.7:

"In order to obtain consistent active entries all nodes in a network
   MUST have the same mapping entry database."

The productive part of this thread is to highlight the ways in which database inconsistency can occur. This cannot be completely eliminated, but we can minimize this in a number of ways:

1)Reemphasize that a SID is a property of the prefix - NOT the protocol which advertises it

This is fundamental to the SR architecture and is consistent with the way SIDs are used in the forwarding plane. And it will eliminate the possibility that two intra-area protocols use different SIDs for the same prefix.

2)Reduce the proliferation of "inactive" intra-area SIDs to other areas.

While this is desirable, as Bruno noted in his recent reply, there is danger for oscillation if not done carefully. I am still thinking about how to correctly specify this.

3)Perhaps the draft would benefit from some additional discussion of the ways in which inconsistent databases can occur and what consequences they have.
(Bruno - I think this is what you are suggesting in your reply).

I will also look into this.

   Les

From: Shraddha Hegde [mailto:[email-masked]]
Sent: Monday, July 31, 2017 10:27 AM
To: Les Ginsberg (ginsberg); [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Les,

Rgds
Shraddha

Shraddha -

A---B---C---D

   Les

Thanks for the response.

Rgds
Shraddha

Shraddha -

"In cases where the

   first advertisement.

 Becomes active entry.

Across implementations.

   in the local database."

A1-----A2------B2-----B1

All nodes run IS-IS.

A1

1.1.1.1/32 100

A2

1.1.1.1/32 100

2.2.2.2/32 100

B1

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

Node

Draft Algorithm

Shraddha Algorithm

A1

1.1.1.1/32 100

1.1.1.1/32 100

A2

1.1.1.1/32 100

1.1.1.1/32 100

B1

2.2.2.2/32 100

2.2.2.2/32 100

B2

1.1.1.1/32 100

2.2.2.2/32 100

     4. Smaller range wins

        value) wins

     8.Smaller algorithm wins

     9. Smaller topology Id

    Les