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

Shraddha -

Thanx for the comments - responses inline.

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

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Shraddha Hegde

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

> To: spring@ietf.org<mailto:spring@ietf.org>

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

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

>

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

>             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

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

>

>

> Rgds

> Shraddha

>

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

> From: Martin Horneffer [mailto:maho@nic.dtag.de]

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

> To: spring@ietf.org<mailto:spring@ietf.org>

> 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

> >> spring@ietf.org<mailto:spring@ietf.org>

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

> >>

> >

> > _______________________________________________

> > spring mailing list

> > spring@ietf.org<mailto:spring@ietf.org>

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

> >

>

>

> _______________________________________________

> spring mailing list

> spring@ietf.org<mailto:spring@ietf.org>

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