Subject: [spring] SID semantics (was draft-ginsberg-spring-conflict-resolution)

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 11 Jan 2016 22:44:35 +0000

Stewart/Robert –

I have revised the subject – because what you are talking about has nothing to do with the original subject.

Please review:  https://www.ietf.org/id/draft-ietf-spring-segment-routing-07.txt - particularly Section 3

And at least one of the protocol drafts e.g. https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06.txt  - particularly Section 2.4

You will find that a SID can be associated with many types of FECs – a prefix is just one example.

If you still feel there is something to discuss please do so in the context of this revised thread.
Thanx.

    Les

From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, January 11, 2016 8:17 AM
To: [email-masked]; Robert Raszuk
Cc: Les Ginsberg (ginsberg); [email-masked]; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Actually SIDs should not have the semantics of an IP address.

They should have the semantics of an instruction. If you want
to make an analogy, that should be with a MPLS label. Where
some people think of a label as short hand for an address. If
a label could only be an address we could not have used them
to identify VPNs or to convey the more complex operation
associated with a pseudowire label.

It would pay dividends to get this right now else later we will
regret not being able to add some function to the architecture
because someone had built on the assumption that SID==Address.

- Stewart

On 11/01/2016 15:17, [email-masked]<mailto:[email-masked]> wrote:
Fully agree but this is not the choice that has been made at the beginning. Do you want to propose a change ?

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, January 08, 2016 15:26
To: LITKOWSKI Stephane SCE/OINIS
Cc: Stewart Bryant; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

Stephane,

IP addresses are not used in path computation. Those are just leaves. You can easily compute topology by just using nodes and links without IP addresses. SIDs should have semantics similar to IP address but presence of one should not mandate or be in any way tight to the other.

Cheers,
R.

On Fri, Jan 8, 2016 at 3:09 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Why not ... but in this case why also having Node-SID bound to a prefix ? Today Anycast and Node-SID are all a subcase of the IGP Prefix SID, so bound to a prefix.
I agree that there is no real need to bind them to a prefix as long as we can still compute the path towards the SID (now we inherit IP path).

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution

> On 8 Jan 2016, at 09:39, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:
>
> [SLI] Anycast SID is not a conflict because the IP prefix is the same.

Taking a long term view why conflate anycast SID with an IP address? SIDs are instructions not addresses, and we may wish to use them to instruct well known operation in the network.

Stewart
_________________________________________________________________________________________________________________________

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.