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

From: <[email-masked]>
Date: Tue, 1 Aug 2017 08:28:28 +0000

Hi Les,

There is something unclear to me here.
Let's say we have the following entries:
OSPF mappings:
(192,10.0.0.1/32,100,1,0,0)
(128,10.0.0.1/32,200,300,0,0)

ISIS mappings:
(192,10.0.0.1/32,300,1,0,0)
(128,10.0.0.1/32,400,300,0,0)

There is a prefix conflict here because we have 4 SIDs for 10.0.0.1/32. The current proposal should pick (192,10.0.0.1/32,100,1,0,0) learned from OSPF because of smallest start SID.
Now let's say that the active route in the RIB is an IS-IS route because of local protocol preference, the route is : IS-IS 10.0.0.1/32 nexthop 42.42.42.42 via Te0/1
So do you program the following FIB entries (consider SRGB start at 16000 for every nodes) :
10.0.0.1/32 via Te0/1 push 16100
Inlabel 16100 via Te0/1 swap 16100

This means that you defacto allows cross protocols information use (e.g. ISIS route using an OSPF mapping). The text is not crystal clear on that point.

Or the other possibility is to not use the SID information because it does not comes from the right protocol. So you only program the FIB but not the LFIB:
10.0.0.1/32 via Te0/1.

Could you clarify ?

Thanks,

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

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]> [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

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]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

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]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Shraddha -

Thanx for the comments - responses inline.

> -----Original Message-----

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

>    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

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

>     10. Smaller starting SID wins

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

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.

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

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.

<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

     1. Higher protocol preference wins

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

     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

    10. Smaller starting SID wins

Thanx for bringing this issue up.

    Les

> Rgds

> Shraddha

> -----Original Message-----

> From: Martin Horneffer [mailto:[email-masked]]

> Sent: Friday, July 14, 2017 8:22 PM

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

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

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

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

> >> n/

> >> _______________________________________________

> >> spring mailing list

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

> >> https://www.ietf.org/mailman/listinfo/spring

> > _______________________________________________

> > spring mailing list

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

> > https://www.ietf.org/mailman/listinfo/spring

> _______________________________________________

> spring mailing list

> [email-masked]<mailto:[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.

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Tue, 1 Aug 2017 13:23:48 +0000

Regarding the existence of multiple protocols/LSDB, section 2 related to SRGB seems to be light on this case.

   Sender behavior is defined in various SR protocol drafts such as [SR-
   IS-IS] which specify that senders MUST NOT advertise overlapping
   ranges.

   Receivers of SRGB ranges MUST validate the SRGB ranges advertised by
   other nodes.  If the advertised ranges do not conform to the
   restrictions defined in the respective protocol specification
   receivers MUST ignore all advertised SRGB ranges from that node.

When both IS-IS and OSPF are used, there is no document specifying how SRGB advertisements should be done across protocols.

Some people have expressed that SRGB is a property of the node, not of the protocol. This seems to call for both IGP to advertise the same SRGB range(s).
But a strict reading of this draft may lead to consider that those SRGB range(s) are not disjoint, hence must all be ignored.
   For the set of ranges to be usable the ranges MUST be disjoint.
   Sender behavior is defined in various SR protocol drafts such as [SR-
   IS-IS] which specify that senders MUST NOT advertise overlapping
   ranges.

   Receivers of SRGB ranges MUST validate the SRGB ranges advertised by
   other nodes.  If the advertised ranges do not conform to the
   restrictions defined in the respective protocol specification
   receivers MUST ignore all advertised SRGB ranges from that node.

I think this point should be clarifier in the draft.

Thanks,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 01, 2017 10:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 1 Aug 2017 16:28:59 +0000

Stephane -

The draft states (as this thread has discussed):

Section 3.7

"In cases where multiple routing protocols are in use mapping
      entries advertised by all routing protocols MUST be included."

In what way is this not clear??

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

From: spring [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, July 29, 2017 00:25
To: DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Bruno -

    Les

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.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 1 Aug 2017 19:30:44 +0000

Bruno -

I think there is a fundamental point which is being overlooked here.

If we look at https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt Section 2<https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt%20Section%202>: (emphasis added)

"SR Global Block (SRGB): local property of an SR node.  In the MPLS
   architecture, SRGB is the set of local labels reserved for global
   segments."

IGP s are one means of advertising SR values (SRGB, SIDs). This does not mean that the scope of the value advertised is limited to the IGP instance.
There is a great deal of precedence for this - many values advertised by IGPs are node properties (e.g.,  IP/IPv6 addresses ).

Do not confuse the transport with the scope of the identifier being advertised.

   Les

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, August 01, 2017 6:24 AM
To: Les Ginsberg (ginsberg); [email-masked]
Cc: LITKOWSKI Stephane OBS/OINIS; Shraddha Hegde
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Thanks,
--Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, August 01, 2017 10:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 08:08:42 +0000

No it's not, it's definitely not enough precise.

Telling that you include all the entries (from all protocols) in the conflict resolution does not mean that cross protocol info may be used when programming the FIB. That's a different story.

And speaking as an operator, from a troubleshooting point of view it becomes a nightmare when you use some information coming from the protocol and some other informations coming from another source of information.

So let's say that I have two concurrent routes for a prefix on a node N:

OSPF 10.0.0.1/32 preference 100 via Te0/1 (N1)
ISIS 10.0.0.1/32 preference 200 via Te0/2 (N2)

N, N1 and N2 advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in ISIS.
N has the following SID mappings:
OSPF mappings:
(192,10.0.0.1/32,100,1,0,0)
(128,10.0.0.1/32,200,300,0,0)

ISIS mappings:

So to program the LFIB on N, I will take the ISIS route which is the active route in the RIB. I will so consider the ISIS SRGB of N but from a conflict resolution point of view, I will use the OSPF advertisement (192,10.0.0.1/32,100,1,0,0)

So my LFIB entry will be:
Inlabel: 2100, swap 2100 via Te0/2

In addition to that, the draft proposes a lower preference for BGP mappings, which introduces a hierarchy between protocols like a protocol preference.

Where is the global logic here ? It is really weird to retrieve some SR information from one protocol, and some others from another protocol.

I think we are touching things here that are not clearly defined by the architecture: the multi protocol behavior has never been clearly described, so we probably need to think about it and define something before rushing on the conflict resolution.

I see two main approaches:

a)      We can consider that OSPF-SR extensions and the regular OSPF protocol used for routing as completely separate things (same for IS-IS). So OSPF-SR extensions are considered as a label distribution protocol like LDP is. As LDP, it requires some routing informations to be used (that may come from the OSPF routing protocol or even IS-IS). So SR builds a kind of label information base (LIB) like LDP and then the routing process combines the LIB info with the active route to build the FIB entry. This approach is similar to what you try to achieve except that I suppose here that all the SR informations should come from a single source (so if we pick a binding from OSPF, we consider to use the OSPF SRGB). Thus as we have multiple sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly LDP, we also need to create a preference mechanism between the protocols here as we do for the routing table. In such a scenario, when doing an IGP migration, I need to migrate the label distribution protocol part and also the routing protocol part possibly in multiple steps (by using preferences on each side). We need to define how we can distribute SR informations from one protocol to the other.

In this approach, using the example above, we should program this entry in the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label comes from OSPF-SR, routing comes from the IS-IS active route)

b)      We can consider another approach where the SR informations are tied with the routing protocol. When multiple protocols are running, we still need to take care of the conflict resolution between the protocols, but this may be solved easily by using the existing protocol preference of the RIB as the first criteria. So a mapping will never be used if it does not correspond to an active route from the same protocol.

In this approach, using the example above, we should program this entry in the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label comes from ISIS-SR, routing comes from the IS-IS active route). The OSPF mappings for 10.0.0.1/32 are not considered as there is no OSPF active route.

The approach b) is more simpler to understand from an operation point of view (single preference to manage, single source of information) while a) has some similarities with what we do when using LDP with the complexity of having multiple label distribution protocols involved. In any case, we need to document clearly the approach taken.

Brgds,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Stephane -

Section 3.7

   Les

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, August 01, 2017 1:28 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

---

From: Dirk Goethals <[email-masked]>
Date: Wed, 2 Aug 2017 10:37:34 +0200

Hi,

N, N1 and N2
advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in
ISIS.

IMHO, there is no real conflict as both SRGB are disjoint, so why

not proving both entries in LFIB?

Dirk

Op 2/08/2017 om 10:08 schreef
[email-masked]:

No it’s not,
it’s definitely not enough precise.

Telling that
you include all the entries (from all protocols) in the
conflict resolution does not mean that cross protocol info
may be used when programming the FIB. That’s a different
story.

And speaking as
an operator, from a troubleshooting point of view it becomes
a nightmare when you use some information coming from the
protocol and some other informations coming from another
source of information.

So let’s say
that I have two concurrent routes for a prefix on a node N:

OSPF
10.0.0.1/32 preference 100 via Te0/1 (N1)

ISIS
10.0.0.1/32 preference 200 via Te0/2 (N2)

N, N1 and N2
advertise SRGB [1000,2000] in OSPF and SRGB [2000,3000] in
ISIS.

N has the
following SID mappings:

OSPF mappings:

ISIS mappings:

So to program
the LFIB on N, I will take the ISIS route which is the
active route in the RIB. I will so consider the ISIS SRGB of
N but from a conflict resolution point of view, I will use
the OSPF advertisement
(192,10.0.0.1/32,100,1,0,0)

So my LFIB
entry will be:

Inlabel:
2100, swap 2100 via Te0/2

In addition to
that, the draft proposes a lower preference for BGP
mappings, which introduces a hierarchy between protocols
like a protocol preference.

Where is the
global logic here ? It is really weird to retrieve some SR
information from one protocol, and some others from another
protocol.

I think we are
touching things here that are not clearly defined by the
architecture: the multi protocol behavior has never been
clearly described, so we probably need to think about it and
define something before rushing on the conflict resolution.

I see two main
approaches:

a)
We can consider that OSPF-SR
extensions and the regular OSPF protocol used for routing as
completely separate things (same for IS-IS). So OSPF-SR
extensions are considered as a label distribution protocol
like LDP is. As LDP, it requires some routing informations
to be used (that may come from the OSPF routing protocol or
even IS-IS). So SR builds a kind of label information base
(LIB) like LDP and then the routing process combines the LIB
info with the active route to build the FIB entry. This
approach is similar to what you try to achieve except that I
suppose here that all the SR informations should come from a
single source (so if we pick a binding from OSPF, we
consider to use the OSPF SRGB). Thus as we have multiple
sources of labels: OSPF-SR, ISIS-SR, BGP-SR, even possibly
LDP, we also need to create a preference mechanism between
the protocols here as we do for the routing table. In such a
scenario, when doing an IGP migration, I need to migrate the
label distribution protocol part and also the routing
protocol part possibly in multiple steps (by using
preferences on each side). We need to define how we can
distribute SR informations from one protocol to the other.

In this
approach, using the example above, we should program this
entry in the LFIB: Inlabel 1100 swap 1100 via Te0/2 (label
comes from OSPF-SR, routing comes from the IS-IS active
route)

b)
We can consider another approach where
the SR informations are tied with the routing protocol. When
multiple protocols are running, we still need to take care
of the conflict resolution between the protocols, but this
may be solved easily by using the existing protocol
preference of the RIB as the first criteria. So a mapping
will never be used if it does not correspond to an active
route from the same protocol.

In this
approach, using the example above, we should program this
entry in the LFIB: Inlabel 2300 swap 2300 via Te0/2 (label
comes from ISIS-SR, routing comes from the IS-IS active
route). The OSPF mappings for 10.0.0.1/32 are not considered
as there is no OSPF active route.

The approach b)
is more simpler to understand from an operation point of
view (single preference to manage, single source of
information) while a) has some similarities with what we do
when using LDP with the complexity of having multiple label
distribution protocols involved. In any case, we need to
document clearly the approach taken.

Brgds,

From:
Les Ginsberg (ginsberg) [mailto:[email-masked]]

To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno
IMT/OLN; Shraddha Hegde; [email-masked]

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

Stephane –

The draft
states (as this thread has discussed):

Section 3.7

“In cases where
multiple routing protocols are in use mapping

entries
advertised by all routing protocols MUST be included.”

In what way is
this not clear??

Les

From:
[email-masked]
[mailto:[email-masked]]

To: Les Ginsberg (ginsberg); DECRAENE Bruno
IMT/OLN; Shraddha Hegde;
[email-masked]

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

Hi Les,

There is
something unclear to me here.

Let’s say we
have the following entries:

OSPF
mappings:

ISIS
mappings:

There is a
prefix conflict here because we have 4 SIDs for
10.0.0.1/32. The current proposal should pick
(192,10.0.0.1/32,100,1,0,0) learned from OSPF because of
smallest start SID.

Now let’s say
that the active route in the RIB is an IS-IS route because
of local protocol preference, the route is : IS-IS
10.0.0.1/32 nexthop 42.42.42.42 via Te0/1

So do you
program the following FIB entries (consider SRGB start at
16000 for every nodes) :

10.0.0.1/32
via Te0/1 push 16100

Inlabel 16100
via Te0/1 swap 16100

This means
that you defacto allows cross protocols information use
(e.g. ISIS route using an OSPF mapping). The text is not
crystal clear on that point.

Or the other
possibility is to not use the SID information because it
does not comes from the right protocol. So you only
program the FIB but not the LFIB:

10.0.0.1/32
via Te0/1.

Could you
clarify ?

Thanks,

From:
spring [mailto:[email-masked]]
On Behalf Of Les Ginsberg (ginsberg)

To: DECRAENE Bruno IMT/OLN; Shraddha Hegde;
[email-masked]

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

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

To: Shraddha Hegde; Les Ginsberg (ginsberg);

[email-masked]

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

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

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

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

To: Shraddha Hegde <[email-masked]>;
[email-masked]

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

Shraddha -

Thanx for the comments - responses
inline.

> To: [email-masked]

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

> Conflict resolution is an
important problem to solve and it is important to

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

>             "Active Entries
in the database may be used in forwarding."

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

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

>             The Forwarding
plane programming aspects are completely missing in

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

<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

in the network is required.”

first advertisement.

Becomes active entry.

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

Across implementations.

> 2.  Protocol independent
resolution and impact on network migrations

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

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

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

>             have a winner
which is an advertisement from protocol with

>             There is need for
introducing another preference value specific to

>             and make it the
top rule in the preference rule hierarchy.

[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

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

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

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

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

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

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

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

>             introducing more
configurations as a solution does not help.

Based on the Advertisement originated in ISIS Level or
OSPF

Level 2, OSPF Area 0 = 2

>     1. Higher protocol
preference wins

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

>     7.Smaller starting
address (considered as an unsigned integer

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

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

[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

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

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

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.

4. Smaller range wins

value) wins

8.Smaller algorithm wins

9. Smaller topology Id

Thanx
for bringing this issue up.

Les

> To: [email-masked]

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

> > We are half-way through
the WG Last Call and I am very surprised to

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

draft-ietf-spring-conflict-resolution-04 [1] which is
considered

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

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

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

> >> [email-masked]

> > [email-masked]

> [email-masked]

Thank you.

Thank you.

[email-masked]

---

From: <[email-masked]>
Date: Wed, 2 Aug 2017 12:39:40 +0000

Hi,

In the current version of the draft, conflict evaluation does not look at the SRGB, it only looks at SIDs.
In any case, in the given example, there is a prefix conflict => multiple SIDs/labels associated to a single prefix.

>From an LFIB point of view, as per the current draft, only a single entry will be installed as the others will be inactive in the mapping DB.
I agree that in this example two LFIB entries may be installed but this requires:

-          a per protocol conflict resolution to let one entry per protocol to be active.

-          managing SRGB overlap between protocols: specifications define that SRGB advertisement cannot overlap within a protocol, but not across protocols. It is obvious that an implementation must avoid to advertise overlapping SRGBs between two protocols (e.g. OSPF [1000,2000] and IS-IS [1200,2200]), but I do not think we mandate this somewhere (we do it inside a particular protocol instance) => I think we need to take care of this in any case as even if two SIDs are different, the resulting labels may be equal in case of SRGB overlap.

Brgds,

From: Dirk Goethals [mailto:[email-masked]]
Sent: Wednesday, August 02, 2017 10:38
To: LITKOWSKI Stephane OBS/OINIS; Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: Re: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Hi,

Op 2/08/2017 om 10:08 schreef [email-masked]<mailto:[email-masked]>:

ISIS mappings:

Brgds,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Tuesday, August 01, 2017 18:29
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]<mailto:[email-masked]>
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Stephane -

Section 3.7

   Les

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

Thank you.

spring mailing list

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 2 Aug 2017 18:06:21 +0000

Stephane -

I think it is important to look at conflict resolution in the context of the SR architecture. Much of what you discuss below is inconsistent with the SR architecture and as a result it creates new problems that actually don't need to be solved.
Let me see if I can get us back on the same page.

As previously quoted,  https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt Section 2<https://www.ietf.org/id/draft-ietf-spring-segment-routing-12.txt%20Section%202>: (emphasis added)

>From the same draft, Section 3 we have other relevant statements:

"An IGP-Prefix segment is an IGP segment attached to an IGP prefix.
   An IGP-Prefix segment is global (unless explicitly advertised
   otherwise) within the SR/IGP domain."

"In the context of an instance and a topology, multiple Prefix-SID's
   MAY be allocated to the same IGP Prefix as long as the algorithm
   value is different in each one."

There are a number of conclusions which follow from these statements.

1)An SRGB is a node property, it is NOT a per protocol property

2)The SID associated with a prefix is a property of the prefix, not the protocol which advertises it.

3)One - and only one - SID is associated with a given prefix/algorithm

4)The SR architecture is NOT defining a per protocol forwarding plane - it is defining an SR forwarding plane

If we try to support per protocol SRGBs and allow per protocol SID assignments, this leads to a number of problems, some of which you have mentioned in your posts.
By far the biggest issue is that if we allow per protocol SID assignments, then we are actually REQUIRED to support non-overlapping per protocol SRGBs, which in turn means that we are REQUIRED to support multiple incoming labels for the same prefix.

This follows because a node has no way to determine which protocol will provide the winning route on its neighbors. It would therefore have to program all of the SIDs which the neighbor might use to forward traffic.
This in turn leads to the requirement for per protocol non-overlapping SRGBs because if we allow the same SID to be used for different prefixes so long as the advertising protocols are different, we then have to have a way of mapping that same SID to two different local labels. The only way to guarantee that is possible is to have per protocol non-overlapping SRGBs.

All of this is in conflict with the SR architecture as per the excerpts I have quoted above - which is why the conflict resolution drafts specifies

·         one conflict resolution database populated by advertisements provided by all protocols/SRMSs.

·         SRGB inconsistency detection on a per node basis

If there is concern that the current language in the draft is not explicit enough, I am happy to work on adding clarifying language.
But it is crucial to understand and agree that the choice to use a protocol independent database and per node SRGB is required by the SR Architecture.

A few more comments inline...

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 02, 2017 1:09 AM
To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

ISIS mappings:

[Les:] The reason this was introduced was to provide a preference for SIDs associated with intra-area prefix advertisements. It recognizes that, within an IGP area, what is likely to be the case is that all SR capable nodes will have IGP advertisements, but BGP is only enabled on a few nodes (the ABRs). So the conflict resolution database on all nodes will have the IGP SID advertisements - but only a few nodes will have the BGP SID advertisements. By making BGP advertisements least preferred we insure that the nodes running BGP make conflict resolution choices which are consistent with the nodes which have only the IGP advertisements.

[Les:] The SR information being advertised is scoped by the node - not by the protocol. It is therefore not "weird" to maintain a protocol independent database but logical to do so.
I think this may seem "weird" because you are likely aware that some implementations have chosen to use a per protocol configuration model for SRGB and prefix SIDs. This is an unfortunate choice in my opinion as it introduces the possibility for local configuration inconsistency where none was intended. But, as always, the normative behavior defined by the draft is not meant to mandate how an  implementation supports the normative behavior. But the solution defined in the draft  MUST conform to SR architecture. This in turn may influence implementation strategies i.e. an implementation may move away from per protocol configuration, but that choice is out of scope for the draft itself.

[Les:] Solution "a" is closer to what the draft defines than "b". But, as detailed above, per protocol SRGB leads to other issues and is inconsistent w the SR architecture.
As far as how to "distribute SR information from one protocol to the other", this is already supported by at least some implementations. When routes are redistributed between protocols the SIDs from the source protocol are passed to the destination protocol.
This of course does not imply support for per protocol SIDs -which - as detailed above - is inconsistent with the SR Architecture.

   Les

Brgds,

Stephane -

Section 3.7

   Les

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Aug 2017 13:42:30 +0000

Hi Les,

I think there is a fundamental disagreement here.
"SR Global Block (SRGB): local property of an SR node.  In the MPLS
   architecture, SRGB is the set of local labels reserved for global
   segments."

We agree that the SRGB is a per node property, but a per node+per protocol SRGB is still compliant with this and there was a consensus on the list to let implementations having a per protocol SRGB configuration on each node (this was reflected in the YANG model).

This statement clearly mentions the IGP domain as the boundary...

This also mentions that the statement is limited to a particular IGP instance and topology and does not imply anything for cross instances...

Honestly when the architecture document was written, it was with only a single IGP instance/domain in mind...

Brgds,

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Wednesday, August 02, 2017 20:06
To: LITKOWSKI Stephane OBS/OINIS; DECRAENE Bruno IMT/OLN; Shraddha Hegde; [email-masked]
Subject: RE: [spring] WG Last Call for draft-ietf-spring-conflict-resolution

Stephane -

ISIS mappings:

   Les

Brgds,

Stephane -

Section 3.7

   Les

Hi Les,

ISIS mappings:

Could you clarify ?

Thanks,

Bruno -

    Les

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.

Thank you.

Thank you.