Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

From: <[email-masked]>
Date: Tue, 11 Aug 2015 14:30:09 +0000

I strongly support option #2

but a Problem may occur in that case, if the per-protocol SRGBs share a subSpace.

so let us consider the following example where node N is a SPRING node with two SR-IGP instances   SR-OSPF and SR-ISIS running,
if we configure OSPF-SRGB [8000, 10000] and ISIS-SRGB [9000, 11000].
actually accepting this configuration may result in the same label for two IGP prefixes (EX :  OSPF-Prefix-index 1001 and ISIS-prefix-index 1 will have the label 9001)
which get translated into two entries in the forwarding table.

to solve that I suggest to add a new notification of type let's say
"SRGB-collusion-detected " which will be raised upon the detection of the SRGBs collusion

Rabah

De : spring [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 31 juillet 2015 10:52
À : Jeff Tantsura; [email-masked]
Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Looks that consensus is for option#2, so let's move SRGB to protocol configuration.

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Friday, July 31, 2015 08:04
To: LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi,

Architecturally I agree - label manager shouldn't care less how labels have been learnt
Operationally I'm strongly for #2, in case of ISIS possibly under AF.

Cheers,
Jeff

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 22, 2015 at 7:19 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi WG,

In the current version of the config Yang model for SR, the SRGB list is configured at SR top level, so it is agnostic to the routing protocol.
We had some comment in Dallas on difficulties that having common label range shared between protocols could lead to.
During discussion in our design team, some point was also raised on routing protocol migrations that may be safer using a per protocol SRGB (so configuration the SRGB at IGP level rather than globally).

We would like to hear from the WG about the preference and arguments for both approaches :
Approach 1) keep SRGB configuration at top level, and so routing protocols will share the same label space (today proposal)
Approach 2) move SRGB configuration to protocols, each routing protocol manages its own label space.

Thanks to provide your feedback in order to solve this issue and have a consensus.

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[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.

_________________________________________________________________________________________________________________________

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: Pushpasis Sarkar <[email-masked]>
Date: Tue, 11 Aug 2015 16:54:01 +0000

Hi Rabah,

Totally agree to your point. And that is why IMO, the configuration module on any router MUST NOT allow any of the per-protocol SRGBs to overlap. All the per-protcol SRGBs MUST be non-overlapping.

Thanks
-Pushpasis

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 11, 2015 at 8:00 PM
To: LITKOWSKI Stephane SCE/IBNF <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

to solve that I suggest to add a new notification of type let's say
“SRGB-collusion-detected “ which will be raised upon the detection of the SRGBs collusion

Rabah

De : spring [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : vendredi 31 juillet 2015 10:52
À : Jeff Tantsura; [email-masked]<mailto:[email-masked]>
Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Looks that consensus is for option#2, so let’s move SRGB to protocol configuration.

Hi,

Architecturally I agree – label manager shouldn’t care less how labels have been learnt
Operationally I’m strongly for #2, in case of ISIS possibly under AF.

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Aug 2015 18:48:07 +0000

Pushpasis/Rabah -

The conflicting SRGB range issue is neither new nor specific to protocol specific SRGBs. There is already a (somewhat lively) discussion going on about what to do w conflicting SRGB ranges when received (see attached email).
IMO if you want to discuss this issue it would be better done in the context of the attached thread - not this one.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Tuesday, August 11, 2015 9:54 AM
To: [email-masked]; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; [email-masked]
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Rabah,

Thanks
-Pushpasis

Rabah

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Subject: Re: [spring] Conflicting MS entries
From: "[email-masked]" <[email-masked]>
To: "Stefano Previdi (sprevidi)" <[email-masked]>
Cc: LITKOWSKI Stephane SCE/IBNF <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked] list" <[email-masked]>
Date: Wed, 17 Jun 2015 14:53:55 +0000
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>

Hi Stefano,

Thanks for initiating discussion on this point.

1) I don't feel that this is a IS-IS encoding specific issue, but rather a SPRING consideration, so I'm adding spring.
Eventually this seems related to draft-filsfils-spring-segment-routing-ldp-interop

<chair hat off>

2) From a service provider standpoint, i.e. from a functional standpoint, I think what we should try to handle this as nicely as possible. Indeed, having conflicting configurations between 2 nodes may happen, and even the most clever implementation may not avoid such configuration mistake. So in such case, dropping traffic for Mapping Server SID seems a significant network wide disruption.

3) As a contributor to spring, from a protocol standpoint, this looks a priori easier than BGP error handling, so we should probably be able to do at least as good.
It seems easier since:
- the state of the speaker is not relevant as we don't need to send spring traffic or spring signaling to it.
- all receivers receive the same information which is syntaxally correct

So to have a coherent network state, it would seem sufficient to specify a behavior on the receiving side.

4) Going into more details, and referring to Stéphane analysis:
	 1) I don't really the issue. From a forwarding standpoint, looks like we can simply program multiple SIDs in the FIB.
	 2) Seems more complex to me. A priori we need to define a tie-breaker based on received MS entries. We seem to all agree that local only mapping must be disregarded/less preferred. According to you, this is the easy part, so looks good.
	3) Is already specified in the ISIS document: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-04#section-2.4.5

So it looks like the remaining work is to define a tie-breaker.

Thanks,
Bruno

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Stefano Previdi (sprevidi)
> 
> <removing the long recipient list and adding isis-wg> Background
> information about this issue is on the original email here below.
> 
> 
> Hi Stephane,
> 
> On Jun 17, 2015, at 10:42 AM, <[email-masked]> wrote:
> > Hi Stefano,
> >
> > As discussed in Dallas, there may be no ideal option but let's try to find
> one which may try to preserve the transport service. So I'm not in favor of
> option 1.
> > There may be three kinds of overlap :
> > 1) prefix overlap with different indexes, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	192.0.2.5/32 range 1 index 2000
> > 	192.0.2.5/32 range 2 index 3000
> > 	In this case 192.0.2.5/32 is associated with three different indexes
> >
> > 2) index overlap, example :
> > 	192.0.2.0/32 range 10 index 100
> > 	198.15.0.0/32 range 100 index 100
> > 	In this case, different prefixes will use the same index.
> >
> > 3) overlap between binding TLV and prefix entry
> > 	192.0.2.0/32 range 10 index 100 learned from MS
> > 	192.0.2.5/32 index 200 learned from TLV135
> > 	In this case 192.0.2.5/32 is associated with two different indexes
> > learned by two different ways
> 
> 
> very good points above and that illustrate even better the complexity of the
> scheme we would need to define in order to cope with all possible cases.
> 
> 
> > 2) must be solved as we manage conflicting SIDs associated with
> connected prefixes. It's a similar case, two different prefixes having the
> same SID.
> 
> 
> yes, this is the easy one. Again, no real solution here but as you pointed out,
> you may still want to preserve part of the reachability.
> 
> >
> > 1)3) If we think about tiebreaker, I'm not sure that preferring local MS
> entries over remote MS entries is a good idea as it may lead to
> inconsistencies while the target may be to have everyone taking the same
> decision.  In contrary, I would make prefer prefix SID mappings over MS
> entries.
> 
> 
> yes, I agree. The point was what to prefer between a received MS entry vs. a
> locally defined MS entry. But as you aid, if we prefer anything "local" we
> can't rely on network-wide consistent behavior.
> 
> s.
> 
> 
> > To compare MS entries, it may be possible to consider something like
> lowest range and then lowest index for example.
> >
> > -----Original Message-----
> > From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
> > Sent: Tuesday, June 16, 2015 19:15
> > To: Clarence Filsfils (cfilsfil); Ahmed Bashandy (bashandy); Hannes
> > Gredler; LITKOWSKI Stephane SCE/IBNF; DECRAENE Bruno IMT/OLN; Jeff
> > Tantsura; Les Ginsberg (ginsberg); Wim (Wim) Henderickx; Steven Luong
> > (sluong)
> > Subject: Conflicting MS entries
> >
> > Co-authors and Contributors,
> >
> > I'd like to close on the conflicting MS entries issues.
> >
> > The issue is related to what a receiver should do when receiving to or
> more conflicting MS mappings.
> >
> > So far we agreed that there's no way we can determine which one is good
> or bad and therefore whatever action we mandate it will create disruption.
> The choices are:
> >
> > 1. ignore all conflicting entries
> > 2. select one of the conflicting entry based on whatever breaking tie algo.
> >
> > Obviously, option1 is the easiest knowing that no other option would allow
> to fix the conflict anyway.
> > Option2 may be appealing but in such case we would have to consider all
> corner cases such as:
> > . what about a conflict between locally configured mapping entry and
> received ones ?
> > . what about conflicting entries received by the same router ? which one to
> select ?
> >
> > I think it is preferable to ignore all conflicting entries and log and error
> message. We discussed about this in Dallas but despite the agreement on
> the absence of a cure we decided, at that time, to let the operators to give
> feedback on the proposal.
> >
> > Is there anything that has changed ?
> >
> > Also, let me know if you'd prefer to bring the issue to the mailing list
> before reaching agreement among co-authors.
> >
> > Thanks.
> > s.
> >
> >
> >
> ______________________________________________________________
> ________
> > ___________________________________________________
> >
> > 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; they should not be
> distributed, used or copied without authorisation.
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 12 Aug 2015 05:32:44 +0000

Hi Les,

Sure. However I am more interested in the prevention than the cure. But I agree that a cure is needed as well.

Thanks
-Pushpasis

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 12, 2015 at 12:18 AM
To: Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, LITKOWSKI Stephane SCE/IBNF <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Pushpasis/Rabah –

The conflicting SRGB range issue is neither new nor specific to protocol specific SRGBs. There is already a (somewhat lively) discussion going on about what to do w conflicting SRGB ranges when received (see attached email).
IMO if you want to discuss this issue it would be better done in the context of the attached thread – not this one.

   Les

From: spring [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Tuesday, August 11, 2015 9:54 AM
To: [email-masked]<mailto:[email-masked]>; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Rabah,

Thanks
-Pushpasis

Rabah

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 12 Aug 2015 08:09:43 +0000

Les
The discussion that you pointed out does not discuss  the conflicting SRGB scenario that I explained,
rather it is about the conflicting index ranges which is another problem.

To clarify :
1) The Index range conflict  result in having two IGP prefixes with same Index value.
2)SRGB range overlapping  problem happens only when we consider the scenario where a SPRING node runs two or more IGPs, and every IGP has its own SRGB,

PS As stephane one of the authors of SR-yang said  the consensus is to adopt the per-protocol SRGB space option.

Bests,
RABAH.

De : Les Ginsberg (ginsberg) [mailto:[email-masked]]
Envoyé : mardi 11 août 2015 20:48
À : Pushpasis Sarkar; GUEDREZ Rabah IMT/OLN; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; [email-masked]
Objet : RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Pushpasis/Rabah -

   Les

Hi Rabah,

Thanks
-Pushpasis

Rabah

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Aug 2015 09:48:04 +0000

Hi Rabah,

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 12, 2015 at 4:09 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>, Pushpasis Sarkar <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Les

To clarify :

The SR YANG model configures the node-sids outside the IGPs - https://www.ietf.org/id/draft-ietf-spring-sr-yang-00.txt. If you advertise the same prefix in multiple protocols in the same topology, it should use the same index value. The case where you need to partition the SID space between protocols is the exception rather than the rule.

Unless you have completely separate routing domains with completely separate SID spaces, you’d want to use a consistent SRGB across protocols.

Thanks,
Acee

Bests,
RABAH.

De : Les Ginsberg (ginsberg) [mailto:[email-masked]]
Envoyé : mardi 11 août 2015 20:48
À : Pushpasis Sarkar; GUEDREZ Rabah IMT/OLN; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; [email-masked]<mailto:[email-masked]>
Objet : RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Pushpasis/Rabah –

   Les

Hi Rabah,

Thanks
-Pushpasis

Rabah

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Wed, 12 Aug 2015 15:47:39 +0000

Hi Acee

De : Acee Lindem (acee) [mailto:[email-masked]]
Envoyé : mercredi 12 août 2015 11:48
À : GUEDREZ Rabah IMT/OLN; Les Ginsberg (ginsberg); Pushpasis Sarkar; LITKOWSKI Stephane SCE/IBNF; Jeff Tantsura; [email-masked]
Objet : Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

Hi Rabah,

Les

To clarify :

The SR YANG model configures the node-sids outside the IGPs - https://www.ietf.org/id/draft-ietf-spring-sr-yang-00.txt. If you advertise the same prefix in multiple protocols in the same topology, it should use the same index value. The case where you need to partition the SID space between protocols is the exception rather than the rule.
[Rabah] I  totally  agree,  but the Problem still exists, please refer to the discussion about that subject.

[Rabah] will see what option the authors will go with :  a single SRGB per node or per-protocol instance SRGB.
I did raise the problem of per-protocol SRGBs overlapping, because Option 2 seems the one that got more support.

Thanks,
Acee

Bests,
RABAH.

Pushpasis/Rabah –

   Les

Hi Rabah,

Thanks
-Pushpasis

Rabah

Hi,

Cheers,
Jeff

Hi WG,

Stephane Litkowski
Network Architect

Thank you.

Thank you.

Thank you.

Thank you.