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 protected] 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 protected] [mailto:[email protected]] *On Behalf Of
*Robert Raszuk
*Sent:* Friday, January 08, 2016 15:26
*To:* LITKOWSKI Stephane SCE/OINIS
*Cc:* Stewart Bryant; Les Ginsberg (ginsberg); [email protected];
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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>]
Sent: Friday, January 08, 2016 14:52
To: LITKOWSKI Stephane SCE/OINIS
Cc: Robert Raszuk; Les Ginsberg (ginsberg); [email protected]
<mailto:[email protected]>; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution
> On 8 Jan 2016, at 09:39, <[email protected]
<mailto:[email protected]>> <[email protected]
<mailto:[email protected]>> 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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
