Subject: RE: Size of CR in CRH

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 00:19:33 +0200

HI,

So just to make sure I understand this analogy of 16 bit -- 2^16 = 65536
nodes. I think this is only on paper.

Imagine I have 1000 routers so if I divide the 16 bit space by 1000 I get
at most 65 local node behaviours if anyone would like to embed such into
the SID.

That means that if my router have more then 65 interfaces I am not able to
steer packets by src route out of my router ... I must always depend on the
lookup of next SID how to forward the packets.

That also means that if I want to apply any form of NP in segment endpoint
I am quite limited to the number of local functions I could use.

To conclude - Let me restate to what I and others already said - flat SID
space domain wide in mapping plane is a mistake. Yes this is like MPLS, but
this does not make it great again due to that legacy.

Many thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 02:01:24 +0000

Robert,

Consider the following network:

  *   Contains 65,000 routers
  *   Each router has 500 directly connected neighbors or fewer
  *   Uses 16-bit CRH

In this network, each node might have 65,499 CRH-FIB entries:

  *   64,999 CRH-FIB entries cause packets to follow the least-cost path to another node in the domain
  *   500 CRH-FIB entries cause packets to traverse a specific link to a specific neighbor.

As a mnemonic device, an operator might assign identifiers as follows:

  *   0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain
  *   65,001 - 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.

Now recall that identifiers have node local significance. So, Node A and Node B might both have a CRH-FIB entry that is identified by the value 65,001. However:

  *   The CRH-FIB entry on Node A causes packets to traverse a particular link towards Node X
  *   The CRH-FIB entry on Node B causes packets to traverse a different link towards Node Y.

I think that this example refutes the premise of your argument, so there is not further need to address the conclusion.

                                                                                         Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 20, 2020 6:20 PM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: RE: Size of CR in CRH

[External Email. Be cautious of content]

HI,

So just to make sure I understand this analogy of 16 bit -- 2^16 = 65536 nodes. I think this is only on paper.

Imagine I have 1000 routers so if I divide the 16 bit space by 1000 I get at most 65 local node behaviours if anyone would like to embed such into the SID.

That means that if my router have more then 65 interfaces I am not able to steer packets by src route out of my router ... I must always depend on the lookup of next SID how to forward the packets.

That also means that if I want to apply any form of NP in segment endpoint I am quite limited to the number of local functions I could use.

To conclude - Let me restate to what I and others already said - flat SID space domain wide in mapping plane is a mistake. Yes this is like MPLS, but this does not make it great again due to that legacy.

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 10:34:27 +0200

Ron,

> Now recall that identifiers have node local significance.

I was talking about case described in yr draft section 7:

"Applications can:

       o Allocate SIDs so that they have *domain-wide significance*."

While not a must - it is an option. So I believe my observation stays valid
till draft either removes that option or describes scaling properties
differences between both domain wide and local significance of the SIDs.

Thx,
R.

On Thu, May 21, 2020 at 4:01 AM Ron Bonica <[email-masked]> wrote:

>    - Contains 65,000 routers
>    - Each router has 500 directly connected neighbors or fewer
>    - Uses 16-bit CRH
>
>
>
>    - 64,999 CRH-FIB entries cause packets to follow the least-cost path
>    to another node in the domain
>    - 500 CRH-FIB entries cause packets to traverse a specific link to a
>    specific neighbor.
>
>
>
>    - 0-65,000 identify CRH-FIB entries that cause packets to follow the
>    least-cost path to another node in the domain
>    - 65,001 – 65,565 identify CRH-FIB entries that that cause packets to
>    traverse a specific link to a specific neighbor.
>
>
>
> Now recall that identifiers have node local significance. So, Node A and
> Node B might both have a CRH-FIB entry that is identified by the value
> 65,001. However:
>
>
>
>    - The CRH-FIB entry on Node A causes packets to traverse a particular
>    link towards Node X
>    - The CRH-FIB entry on Node B causes packets to traverse a different
>    link towards Node Y.
>
>
>
> I think that this example refutes the premise of your argument, so there
> is not further need to address the conclusion.
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, May 20, 2020 6:20 PM
> *To:* Ron Bonica <[email-masked]>
> *Cc:* 6man <[email-masked]>
> *Subject:* RE: Size of CR in CRH
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> HI,
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 14:19:07 +0000

Robert,

It might makes sense for an operator to:

  *   Allocate identifiers that cause packets to traverse a least-cost path as if they had domain-wide significance
  *   Allocate identifiers that cause packets to traverse specific links as strictly node local

This concept also exists in SR-MPLS, where prefix SIDs have domain-wide scope and adjacency SIDs have node-local scope.

I will make this more clear in the next draft version.

                                        Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Thursday, May 21, 2020 4:34 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

"Applications can:

       o Allocate SIDs so that they have domain-wide significance."

While not a must - it is an option. So I believe my observation stays valid till draft either removes that option or describes scaling properties differences between both domain wide and local significance of the SIDs.

Thx,
R.

On Thu, May 21, 2020 at 4:01 AM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                                         Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 20, 2020 6:20 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: Size of CR in CRH

HI,

Many thx,
R.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 May 2020 14:35:02 +0000

Hi Ron,

Just to add to what Robert mentioned.

“Re: [Ron] I think that this example refutes the premise of your (comment) argument”

No, it does not "refutes the premise of" Robert's comment. It raises more questions and cements the need for a proper architecture and use-case document.

In rev 10 of the CRH document[1], the following SIDs with normative reference to SRm6 were defined:

"The following are valid segment types:

   o Adjacency.

   o Node.

   o Binding. "

The ISIS extension for CRH still defines how to advertise prefix SIDs and Adjacency SIDs.

In your example you introduced the notion of ranges ”0-65,000 (global significance; prefix SID) 65,001 - 65,565 (local significance; adjacency SIDs). Where is this defined?
Did you not remove the above-quoted text in Feb. 2020?
Will the working group see Binding SID definition back into the draft, too?
What else … draft-bonica-6man-vpn-dest-opt? draft-alston-spring-crh-bgp-signalling? draft-bonica-6man-seg-end-opt-07? draft-ssangli-bess-bgp-vpn-srm6-01? Crh-PCEP draft? …. Etc.

[1] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-10#section-4

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Thursday, May 21, 2020 at 4:35 AM
To: Ron Bonica <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

"Applications can:

Thx,
R.

  *   0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain
  *   65,001 – 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.

                                                                                         Ron

HI,

To conclude - Let me restate to what I and others already said - flat SID space domain wide in mapping plane is a mistake. Yes this is like MPLS, but this does not make it great again due to that legacy..

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 16:35:23 +0200

Ron,

While we are at the local vs global significance of SIDs can you please
elaborate how do you resolve the conflict where given SID value is
advertised by more then one node ? In fact imagine that all nodes in a
domain choose to advertise the same SID value "15" to forward the traffic
to their respective peers. So packet arrives at segment endpoint node A
with CRH consisting of SID list 15, 15, 15, 15 ... where each value 15
means different behaviour on different node.

How do you even know which way to forward the packet ?

See in this case your mapping plane will contain different functions on
different nodes signalled with the same SID.

I understand that you are trying to silently borrow set of procedures from
SR-MPLS here as documented in RFC8660. But if you just open this RFC you
will see section 2.5 or 2.6 without which you just can not simply propose
to treat SID as locally significant in any form of segment routing. Of
course unless you would consume two SIDs per node.

Thx,
Robert.

On Thu, May 21, 2020 at 10:34 AM Robert Raszuk <[email-masked]> wrote:

> While not a must - it is an option. So I believe my observation stays
> valid till draft either removes that option or describes scaling properties
>> That means that if my router have more then 65 interfaces I am not able
>> to steer packets by src route out of my router ... I must always depend on
>> the lookup of next SID how to forward the packets.
>>
>>
>>
>> That also means that if I want to apply any form of NP in segment
>> endpoint I am quite limited to the number of local functions I could use.
>>
>>
>>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 15:11:12 +0000

Robert,

Let's address your question with an example. Assume that Node A is sending a packet to Node D. The delivery path includes the following strictly routed hops:

  *   Node A to Node B over link A->B
  *   Node B to Node C over link B->C
  *   Node C to Node D over link C->D

Now we populate the CRH-FIB on Nodes B and C as follows:

  *   On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict, Link = B->C
  *   On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict, Link = C->D

Now, Node A formats a packet as follows:

  *   IPv6 Destination Address = Node B
  *   CRH Segments Left = 2
  *   Identifier list = [15,15]

Node A sends this packet to Node B over link A->B. Node B decrements Segments Left and looks for entry 15 in *its* CRH-FIB. If finds:

  *   On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict, Link = B->C

So, Node B updates the IPv6 address and sends the packet to Node C over link B->C. Node C decrements Segments Left and looks for entry 15 in *its* CRH-FIB. If finds:

  *   On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict, Link = C->D

So, Node C updates the IPv6 address and sends the packet to Node D over link C->D.

                                                          Ron

Sent: Thursday, May 21, 2020 10:35 AM

Ron,

While we are at the local vs global significance of SIDs can you please elaborate how do you resolve the conflict where given SID value is advertised by more then one node ? In fact imagine that all nodes in a domain choose to advertise the same SID value "15" to forward the traffic to their respective peers. So packet arrives at segment endpoint node A with CRH consisting of SID list 15, 15, 15, 15 ... where each value 15 means different behaviour on different node.

See in this case your mapping plane will contain different functions on different nodes signalled with the same SID.

I understand that you are trying to silently borrow set of procedures from SR-MPLS here as documented in RFC8660. But if you just open this RFC you will see section 2.5 or 2.6 without which you just can not simply propose to treat SID as locally significant in any form of segment routing. Of course unless you would consume two SIDs per node.

Thx,
Robert.

On Thu, May 21, 2020 at 10:34 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Ron,

"Applications can:

Thx,
R.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 17:24:35 +0200

Hi Ron,

> Node B decrements Segments Left and looks for entry 15 in **its**
CRH-FIB. If finds:

>     On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict,
Link = B->C

Your example works when the entire network has a single segment routed path
:)

What happens if also Node Z somewhere in the domain (or maybe even
connected to B) advertised SID 15 with some different outbound link ?

So Node B will have two FIB entries:

  Identifier = 15, IPv6 Address = Node C, Method = strict, Link = B->C
  Identifier = 15, IPv6 Address = Node Z, Method = strict, Link = X->Y

So how will B decided which one to use ?

Best,
R.

On Thu, May 21, 2020 at 5:11 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> Let’s address your question with an example. Assume that Node A is sending
> a packet to Node D. The delivery path includes the following strictly
> routed hops:
>
>
>
>    - Node A to Node B over link A->B
>    - Node B to Node C over link B->C
>    - Node C to Node D over link C->D
>
>
>
>    - On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict,
>    Link = B->C
>    - On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict,
>    Link = C->D
>
>
>
>    - IPv6 Destination Address = Node B
>    - CRH Segments Left = 2
>    - Identifier list = [15,15]
>
>
>
> Node A sends this packet to Node B over link A->B. Node B decrements
> Segments Left and looks for entry 15 in **its** CRH-FIB. If finds:
>
>
>
>    - On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict,
>    Link = B->C
>
>
>
> So, Node B updates the IPv6 address and sends the packet to Node C over
> link B->C. Node C decrements Segments Left and looks for entry 15 in *
> *its** CRH-FIB. If finds:
>
>
>
>    - On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict,
>    Link = C->D
>
>
>
> *Sent:* Thursday, May 21, 2020 10:35 AM
> *Subject:* Re: Size of CR in CRH
>
>
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 18:45:02 +0000

Robert,

Identifiers have node local scope. This means:

  *   One a single node, there is a one-to-one mapping between identifiers and the CRH-FIB entries that they identify
  *   Nodes A through Z can all have a CRH-FIB entry that is identified by N. However, all of those CRH-FIB entries do not need to contain the same information.

Referring back to your example, Node B will never have the following entry in its CRH-FIB:

  *   Identifier = 15, IPv6 Address = Node Z, Method = strict, Link = X->Y

Why should it? It isn't attached to link X->Y. So it couldn't use that entry even if it had it.

                                                         Ron

Sent: Thursday, May 21, 2020 11:25 AM

Hi Ron,

> Node B decrements Segments Left and looks for entry 15 in *its* CRH-FIB. If finds:
>
>     On Node B:  Identifier = 15, IPv6 Address = Node C, Method = strict, Link = B->C

Your example works when the entire network has a single segment routed path :)

What happens if also Node Z somewhere in the domain (or maybe even connected to B) advertised SID 15 with some different outbound link ?

Best,
R.

On Thu, May 21, 2020 at 5:11 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                          Ron

Ron,

Thx,
Robert.

"Applications can:

Thx,
R.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 21:14:21 +0200

> It isn’t attached to link X->Y.

Please assume it is attached.

I stated very clearly: "(or maybe even connected to B)"

Thx,
R.

On Thu, May 21, 2020 at 8:45 PM Ron Bonica <[email-masked]> wrote:

>    - One a single node, there is a one-to-one mapping between identifiers
>    and the CRH-FIB entries that they identify
>    - Nodes A through Z can all have a CRH-FIB entry that is identified by
>    N. However, all of those CRH-FIB entries do not need to contain the same
>    information.
>
>
>
>    - Identifier = 15, IPv6 Address = Node Z, Method = strict, Link = X->Y
>
>
>
> Why should it? It isn’t attached to link X->Y. So it couldn’t use that
> entry even if it had it.
>
>
>
>                                                          Ron
>
>
>
>
>
>
>
>
>
> *Sent:* Thursday, May 21, 2020 11:25 AM

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 19:46:43 +0000

Robert,

I am assuming that B is attached to Z. When I say, it isn't attached, I mean that B isn't attached to Link X->Y. Link X->Y is attached to Z.

                                                                                              Ron

Sent: Thursday, May 21, 2020 3:14 PM

> It isn't attached to link X->Y.

Thx,
R.

On Thu, May 21, 2020 at 8:45 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                         Ron

Hi Ron,

Best,
R.

                                                          Ron

Ron,

Thx,
Robert.

"Applications can:

Thx,
R.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 May 2020 13:03:58 -0700

On Thu, May 21, 2020 at 8:11 AM Ron Bonica
<rbonica=[email-masked]> wrote:
>
> Robert,
>
>
>
> Let’s address your question with an example. Assume that Node A is sending a packet to Node D. The delivery path includes the following strictly routed hops:
>
>
>
> Node A to Node B over link A->B
> Node B to Node C over link B->C
> Node C to Node D over link C->D
>
>
>

Ron,

I think a route list of 15,15,15,15 working this way isn't naturally
intuitive and might be a bit hard to manage (without context this
looks to me like routing loops to me). Why wouldn't you want to assign
each node a domain scoped identifier? So if A->15, B->16, C->17, and
D->18 then a route list of 15,16,17,18 would visit A, B, C, D and have
consistent meaning across a domain?

Tom

> On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict, Link = C->D
>
>
>
> IPv6 Destination Address = Node B
> CRH Segments Left = 2
> Identifier list = [15,15]
>
>
>
> Node A sends this packet to Node B over link A->B.. Node B decrements Segments Left and looks for entry 15 in *its* CRH-FIB. If finds:
>
>
>
> On Node C:  Identifier = 15, IPv6 Address = Node D, Method = strict, Link = C->D
>
>
>
> Contains 65,000 routers
> Each router has 500 directly connected neighbors or fewer
> Uses 16-bit CRH
>
>
>
> 64,999 CRH-FIB entries cause packets to follow the least-cost path to another node in the domain
> 500 CRH-FIB entries cause packets to traverse a specific link to a specific neighbor.
>
>
>
> 0-65,000 identify CRH-FIB entries that cause packets to follow the least-cost path to another node in the domain
> 65,001 – 65,565 identify CRH-FIB entries that that cause packets to traverse a specific link to a specific neighbor.
>
>
>
> The CRH-FIB entry on Node A causes packets to traverse a particular link towards Node X
> The CRH-FIB entry on Node B causes packets to traverse a different link towards Node Y.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 May 2020 22:05:03 +0200

Hello Ron,

entry even if it had it.

This question I think exposes or uncovers (at least for me) the crux of
your proposal ... perhaps even fatal one.

You are assuming that only locally allocated SIDs are in CRH-FIB - that is
fatal assumption for bunch of reasons ... one swapping DA to some node N
hops away. How are you going to accomplish that if such entries are not
even in CRH-FIB ?

I guess it is very clear now why the other day you stated that "all nodes
in the domain must support CRH".

What seems you are doing here ... and of course this is not written
anywhere in any document ... so this is pure acceptance call guessing - is
a forward referencing SIDs against the peers.

So on any node you are allocating SID per interface - strictly speaking per
forwarding adjacency. Clearly you can not build such construct for remote
nodes based on the above.

Furthermore you are building forwarding chain on the basis of ordered
forwarding list of SIDs just hoping that the peer will accept the packet if
his DA address is in the IPv6 header. Then it will look up his own SID and
continue.

One thing I must agree with you that this is not Segment Routing ... In
fact I am not sure how to call this architecture. Maybe forward referenced
source routing ?

You can not do TI-LFA with this approach unless you pre-program any
possible alternative paths to all nodes in the network.

Sure you can demo this in the lab or even on a network just like you could
demo static mpls labels. Yes it is very simple and you got attention of few
folks with that. And yes you could perhaps even show that if you just add
few lines of xml config you could tunnel it across non CRH capable nodes
... But is this solution for any production network ?

I think and I was told by unicast emails that I am not alone - we are just
guessing what the vehicle looks like after seeing the first wheel. So far
it does not even look like a car ... maybe bike or scooter. Who knows ....

If I may recommend next action without dismissing your proposal a wise
thing to do would be to get from you set of slides or perhaps youtube
recording showing exactly not only all mapping distribution, but more
over illustrating exact packet's header including CRH in all various cases
I and others asked when packet is traversing throughout a controlled domain.

Only after that we could start a new adoption call when more folks actually
has a clear picture what it is being adopted here. Is it a brilliant and
cool solution or is it some form of wild animal which can bite.

Many thx,
Robert.

On Thu, May 21, 2020 at 9:46 PM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> I am assuming that B is attached to Z. When I say, it isn’t attached, I
> mean that B isn’t attached to Link X->Y. Link X->Y is attached to Z.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> *Sent:* Thursday, May 21, 2020 3:14 PM

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 22:22:28 +0000

Robert,

I think that you are confusing two data structures. The CRH-FIB is just that, a FIB. I contains enough information to resolve an incoming identifier to an IPv6 address and a forwarding method. Each node maintains a unique CRH-FIB and there is no requirement for nodes to share their CRH-FIBs with one another. The CRH-FIB lives on the forwarding plane and is an appropriate topic for 6man.

Somewhere in the network, there is an entity constructs the CRH and the list that it contains. That entity needs access to another data structure, that includes a global view of each node's CRH-FIB. That entity might be:

  *   A human, manually constructing forwarding policy
  *   A controller
  *   Path computation software on a router.

                                                                                                       Ron

Sent: Thursday, May 21, 2020 4:05 PM

Hello Ron,

> Why should it? It isn't attached to link X->Y. So it couldn't use that entry even if it had it.

This question I think exposes or uncovers (at least for me) the crux of your proposal ... perhaps even fatal one.

You are assuming that only locally allocated SIDs are in CRH-FIB - that is fatal assumption for bunch of reasons ... one swapping DA to some node N hops away. How are you going to accomplish that if such entries are not even in CRH-FIB ?

I guess it is very clear now why the other day you stated that "all nodes in the domain must support CRH".

What seems you are doing here ... and of course this is not written anywhere in any document ... so this is pure acceptance call guessing - is a forward referencing SIDs against the peers.

So on any node you are allocating SID per interface - strictly speaking per forwarding adjacency. Clearly you can not build such construct for remote nodes based on the above.

Furthermore you are building forwarding chain on the basis of ordered forwarding list of SIDs just hoping that the peer will accept the packet if his DA address is in the IPv6 header. Then it will look up his own SID and continue.

One thing I must agree with you that this is not Segment Routing ... In fact I am not sure how to call this architecture. Maybe forward referenced source routing ?

You can not do TI-LFA with this approach unless you pre-program any possible alternative paths to all nodes in the network.

Sure you can demo this in the lab or even on a network just like you could demo static mpls labels. Yes it is very simple and you got attention of few folks with that. And yes you could perhaps even show that if you just add few lines of xml config you could tunnel it across non CRH capable nodes ... But is this solution for any production network ?

I think and I was told by unicast emails that I am not alone - we are just guessing what the vehicle looks like after seeing the first wheel. So far it does not even look like a car ... maybe bike or scooter. Who knows ....

If I may recommend next action without dismissing your proposal a wise thing to do would be to get from you set of slides or perhaps youtube recording showing exactly not only all mapping distribution, but more over illustrating exact packet's header including CRH in all various cases I and others asked when packet is traversing throughout a controlled domain.

Only after that we could start a new adoption call when more folks actually has a clear picture what it is being adopted here. Is it a brilliant and cool solution or is it some form of wild animal which can bite.

Many thx,
Robert.

On Thu, May 21, 2020 at 9:46 PM Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

                                                                                              Ron

Thx,
R.

                                                         Ron

Hi Ron,

Best,
R.

                                                          Ron

Ron,

Thx,
Robert.

"Applications can:

Thx,
R.

                                                                                         Ron

HI,

Many thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 21 May 2020 22:28:04 +0000

Tom,

If a network operator wants to maintain some discipline regarding identifier allocation, it can do so. However, CRH does not require any specific discipline.

                                                             Ron

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Thursday, May 21, 2020 4:04 PM
To: Ron Bonica <[email-masked]>
Cc: Robert Raszuk <[email-masked]>; 6man <[email-masked]>
Subject: Re: Size of CR in CRH

Ron,

I think a route list of 15,15,15,15 working this way isn't naturally intuitive and might be a bit hard to manage (without context this looks to me like routing loops to me). Why wouldn't you want to assign each node a domain scoped identifier? So if A->15, B->16, C->17, and
D->18 then a route list of 15,16,17,18 would visit A, B, C, D and have
consistent meaning across a domain?

Tom

> Link = B->C On Node C:  Identifier = 15, IPv6 Address = Node D, Method 
> = strict, Link = C->D
>
>
>
> Each router has 500 directly connected neighbors or fewer Uses 16-bit 
> CRH
>
>
>
> 0-65,000 identify CRH-FIB entries that cause packets to follow the 
> The CRH-FIB entry on Node A causes packets to traverse a particular 
> link towards Node X The CRH-FIB entry on Node B causes packets to traverse a different link towards Node Y.
>
>
>
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!!NEt6yMaO-gk!SCZC26VMsknkoW1IUbK5yhnPdBBQL5d8jKsRJS1A-xbPAtK7EJ0wc
> F34sP0jN7Z-$

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 May 2020 00:29:57 +0200

Hi Ron,

I don't think we need to go through a tutorial here what the FIB, CRH-FIB
or LFIB is.

I asked specific question on which you have not provided any answer:

If I have part of the network non CRH aware and each node is free to
allocate their own SID - as you are claiming SIDs are locally significant -
how would the CRH look like in case of SID conflict between local node and
remote node SID collision.

Now rest of your answer is rather vague at best. And this is not just a
detail. This is fundamental frame to the proposal we are discussing
adoption of.

Sure once document becomes a WG a collective brains can paint it well - but
if it does not even have solid frames it may be a pretty hard task.

Just my own little side input. Others may see it different way,

Many thx,
R.

On Fri, May 22, 2020 at 12:22 AM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> I think that you are confusing two data structures. The CRH-FIB is just
> that, a FIB. I contains enough information to resolve an incoming
> identifier to an IPv6 address and a forwarding method. Each node maintains
> a unique CRH-FIB and there is no requirement for nodes to share their
> CRH-FIBs with one another. The CRH-FIB lives on the forwarding plane and is
> an appropriate topic for 6man.
>
>
>
> Somewhere in the network, there is an entity constructs the CRH and the
> list that it contains. That entity needs access to another data structure,
> that includes a global view of each node’s CRH-FIB. That entity might be:
>
>
>
>    - A human, manually constructing forwarding policy
>    - A controller
>    - Path computation software on a router.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> *Sent:* Thursday, May 21, 2020 4:05 PM
> So on any node you are allocating SID per interface - strictly speaking
> per forwarding adjacency. Clearly you can not build such construct for
> remote nodes based on the above.
>
>
>
> Only after that we could start a new adoption call when more folks
> actually has a clear picture what it is being adopted here. Is it a
> brilliant and cool solution or is it some form of wild animal which can
> bite.
>
>
>
> Many thx,
>
> Robert.
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 May 2020 01:13:10 +0200

Hi Ron,

Sure ... we went via this already but why not one more time :)

Node B allocated SID = 15 locally to go to Node C and Node Z allocated SID
15
locally to go to Node D.

So Node B will have two CRH-FIB entries:

  Identifier = 15, IPv6 Address = Node C, Method = strict, Link = B->C
  Identifier = 15, IPv6 Address = Node Z, Method = loose, Link = Z->D

CRH send by Node A is [15,15] & DA = Node B

Please describe how node B will know that we need to go via IPv6 network
to Node Z vs go locally to Node C ?

Cheers,
Robert.

On Fri, May 22, 2020 at 12:55 AM Ron Bonica <[email-masked]> wrote:

> Robert,
>
>
>
> I think that we are talking past each other. Please help me to understand
> your question by providing an example network and the CRH-FIB on each node.
>
>
>
>                                                                        Ron
>
>
>
>
>
>
>
> *Sent:* Thursday, May 21, 2020 6:30 PM
> Sure once document becomes a WG a collective brains can paint it well -
> but if it does not even have solid frames it may be a pretty hard task.
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 May 2020 20:21:52 -0400

Robert, local signifance has a very clear meaning in this space.  We 
understand it in MPLS.  We understand it in SRv6.
And in neither case does it mean that nodes can make up any old label, 
and use it any old way, without suitable communication / coordination.

However, equally, the exact coordination depends upon the control 
mechanism and indications one wants to use.  For example, if local 
labels always follow global labels which indicate their presence, then 
sure, you can use almost any value.  But if the disciple or pattern is 
different, then different constraints apply.

So just what are you trying to ask?

Yours,
Joel

On 5/21/2020 6:29 PM, Robert Raszuk wrote:
> Hi Ron,
> 
> I don't think we need to go through a tutorial here what the FIB, 
> CRH-FIB or LFIB is.
> 
> allocate their own SID - as you are claiming SIDs are locally 
> significant - how would the CRH look like in case of SID conflict 
> between local node and remote node SID collision.
> 
> On Fri, May 22, 2020 at 12:22 AM Ron Bonica <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Robert,____
> 
>     __ __
> 
>     I think that you are confusing two data structures. The CRH-FIB is
>     just that, a FIB. I contains enough information to resolve an
>     incoming identifier to an IPv6 address and a forwarding method. Each
>     node maintains a unique CRH-FIB and there is no requirement for
>     nodes to share their CRH-FIBs with one another. The CRH-FIB lives on
>     the forwarding plane and is an appropriate topic for 6man.____
> 
>     __ __
> 
>     Somewhere in the network, there is an entity constructs the CRH and
>     the list that it contains. That entity needs access to another data
>     structure, that includes a global view of each node’s CRH-FIB. That
>     entity might be:____
> 
>     __ __
> 
>       * A human, manually constructing forwarding policy____
>       * A controller____
>       * Path computation software on a router.. ____
> 
>     __ __
> 
>                                                                                                             Ron____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     Juniper Business Use Only____
> 
>     *From:* Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>
>     *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: Size of CR in CRH____
> 
>     __ __
> 
>     *[External Email. Be cautious of content]____*
> 
>     __ __
> 
>     Hello Ron,____
> 
>     __ __
> 
>      > Why should it? It isn’t attached to link X->Y. So it couldn’t use
>     that entry even if it had it. ____
> 
>     __ __
> 
>     This question I think exposes or uncovers (at least for me) the crux
>     of your proposal ... perhaps even fatal one. ____
> 
>     __ __
> 
>     You are assuming that only locally allocated SIDs are in CRH-FIB -
>     that is fatal assumption for bunch of reasons ... one swapping DA to
>     some node N hops away. How are you going to accomplish that if such
>     entries are not even in CRH-FIB ? ____
> 
>     __ __
> 
>     I guess it is very clear now why the other day you stated that "all
>     nodes in the domain must support CRH". ____
> 
>     __ __
> 
>     anywhere in any document ... so this is pure acceptance call
>     guessing - is a forward referencing SIDs against the peers. ____
> 
>     __ __
> 
>     So on any node you are allocating SID per interface -
>     strictly speaking per forwarding adjacency. Clearly you can not
>     build such construct for remote nodes based on the above. ____
> 
>     __ __
> 
>     Furthermore you are building forwarding chain on the basis of
>     ordered forwarding list of SIDs just hoping that the peer will
>     accept the packet if his DA address is in the IPv6 header. Then it
>     will look up his own SID and continue. ____
> 
>     __ __
> 
>     One thing I must agree with you that this is not Segment Routing ...
>     In fact I am not sure how to call this architecture. Maybe forward
>     referenced source routing ? ____
> 
>     __ __
> 
>     possible alternative paths to all nodes in the network. ____
> 
>     __ __
> 
>     Sure you can demo this in the lab or even on a network just like you
>     could demo static mpls labels. Yes it is very simple and you got
>     attention of few folks with that. And yes you could perhaps even
>     show that if you just add few lines of xml config you could tunnel
>     it across non CRH capable nodes ... But is this solution for any
>     production network ? ____
> 
>     __ __
> 
>     I think and I was told by unicast emails that I am not alone - we
>     are just guessing what the vehicle looks like after seeing the first
>     wheel. So far it does not even look like a car ... maybe bike or
>     scooter. Who knows .... ____
> 
>     __ __
> 
>     If I may recommend next action without dismissing your proposal a
>     wise thing to do would be to get from you set of slides or perhaps
>     youtube recording showing exactly not only all mapping distribution,
>     but more over illustrating exact packet's header including CRH in
>     all various cases I and others asked when packet is
>     traversing throughout a controlled domain.____
> 
>     __ __
> 
>     brilliant and cool solution or is it some form of wild animal which
>     can bite. ____
> 
>     __ __
> 
>     Many thx,____
> 
>     Robert.____
> 
>     __ __
> 
>     __ __
> 
>     On Thu, May 21, 2020 at 9:46 PM Ron Bonica <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         Robert,____
> 
>         ____
> 
>         I am assuming that B is attached to Z. When I say, it isn’t
>         attached, I mean that B isn’t attached to Link X->Y. Link X->Y
>         is attached to Z.____
> 
>         ____
> 
>                                                                                                        Ron____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         Juniper Business Use Only____
> 
>         *From:* Robert Raszuk <[email-masked]
>         <mailto:[email-masked]>>
>         *To:* Ron Bonica <[email-masked] <mailto:[email-masked]>>
>         *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
>         *Subject:* Re: Size of CR in CRH____
> 
>         ____
> 
>         *[External Email. Be cautious of content]*____
> 
>         ____
> 
>          > It isn’t attached to link X->Y. ____
> 
>         ____
> 
>         Please assume it is attached. ____
> 
>         ____
> 
>         I stated very clearly: "(or maybe even connected to B)"____
> 
>         ____
> 
>         Thx,
>         R.____
> 
>         ____
> 
>         ____
> 
>         ____
> 
>         On Thu, May 21, 2020 at 8:45 PM Ron Bonica <[email-masked]
>         <mailto:[email-masked]>> wrote:____
> 
>             Robert,____
> 
>             ____
> 
>             Identifiers have node local scope. This means:____
> 
>             ____
> 
>               * One a single node, there is a one-to-one mapping between
>                 identifiers and the CRH-FIB entries that they identify____
>               * Nodes A through Z can all have a CRH-FIB entry that is
>                 identified by N. However, all of those CRH-FIB entries
>                 do not need to contain the same information.____
> 
>             ____
> 
>             Referring back to your example, Node B will never have the
>             following entry in its CRH-FIB:____
> 
>             ____
> 
>               * Identifier = 15, IPv6 Address = Node Z, Method = strict,
>                 Link = X->Y____
> 
>             ____
> 
>             Why should it? It isn’t attached to link X->Y. So it
>             couldn’t use that entry even if it had it.____
> 
>             ____
> 
>                                         
>                                           Ron____
> 
>             ____
> 
>             ____
> 
>             ____
> 
>             ____
> 
>             Juniper Business Use Only____
> 
>             *From:* Robert Raszuk <[email-masked]
>             <mailto:[email-masked]>>
>             *To:* Ron Bonica <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
>             *Subject:* Re: Size of CR in CRH____
> 
>             ____
> 
>             *[External Email. Be cautious of content]*____
> 
>             ____
> 
>             Hi Ron,____
> 
>             ____
> 
>              > Node B decrements Segments Left and looks for entry 15 in
>             **its** CRH-FIB. If finds:____
> 
>              > ____
> 
>              >     On Node B:  Identifier = 15, IPv6 Address = Node C,
>             Method = strict, Link = B->C____
> 
>             ____
> 
>             Your example works when the entire network has a single
>             segment routed path :) ____
> 
>             ____
> 
>             What happens if also Node Z somewhere in the domain (or
>             maybe even connected to B) advertised SID 15 with some
>             different outbound link ? ____
> 
>             ____
> 
>             So Node B will have two FIB entries: ____
> 
>             ____
> 
>                Identifier = 15, IPv6 Address = Node C, Method = strict,
>             Link = B->C ____
> 
>                Identifier = 15, IPv6 Address = Node Z, Method = strict,
>             Link = X->Y ____
> 
>             ____
> 
>             So how will B decided which one to use ? ____
> 
>             ____
> 
>             Best,____
> 
>             R.____
> 
>             ____
> 
>             ____
> 
>             ____
> 
>             ____
> 
>             On Thu, May 21, 2020 at 5:11 PM Ron Bonica
>             <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>                 Robert,____
> 
>                 ____
> 
>                 Let’s address your question with an example. Assume that
>                 Node A is sending a packet to Node D. The delivery path
>                 includes the following strictly routed hops:____
> 
>                 ____
> 
>                   * Node A to Node B over link A->B____
>                   * Node B to Node C over link B->C____
>                   * Node C to Node D over link C->D____
> 
>                 ____
> 
>                 Now we populate the CRH-FIB on Nodes B and C as follows:____
> 
>                 ____
> 
>                   * On Node B:  Identifier = 15, IPv6 Address = Node C,
>                     Method = strict, Link = B->C____
>                   * On Node C:  Identifier = 15, IPv6 Address = Node D,
>                     Method = strict, Link = C->D____
> 
>                 ____
> 
>                 Now, Node A formats a packet as follows:____
> 
>                 ____
> 
>                   * IPv6 Destination Address = Node B____
>                   * CRH Segments Left = 2____
>                   * Identifier list = [15,15]____
> 
>                 ____
> 
>                 Node A sends this packet to Node B over link A->B.. Node
>                 B decrements Segments Left and looks for entry 15 in
>                 **its** CRH-FIB. If finds:____
> 
>                 ____
> 
>                   * On Node B:  Identifier = 15, IPv6 Address = Node C,
>                     Method = strict, Link = B->C____
> 
>                 ____
> 
>                 So, Node B updates the IPv6 address and sends the packet
>                 to Node C over link B->C. Node C decrements Segments
>                 Left and looks for entry 15 in **its** CRH-FIB. If
>                 finds:____
> 
>                 ____
> 
>                   * On Node C:  Identifier = 15, IPv6 Address = Node D,
>                     Method = strict, Link = C->D____
> 
>                 ____
> 
>                 So, Node C updates the IPv6 address and sends the packet
>                 to Node D over link C->D.____
> 
>                 ____
> 
>                                                                            Ron____
> 
>                 ____
> 
>                 ____
> 
>                 ____
> 
>                 Juniper Business Use Only____
> 
>                 *From:* Robert Raszuk <[email-masked]
>                 <mailto:[email-masked]>>
>                 *To:* Ron Bonica <[email-masked]
>                 <mailto:[email-masked]>>
>                 *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
>                 *Subject:* Re: Size of CR in CRH____
> 
>                 ____
> 
>                 *[External Email. Be cautious of content]*____
> 
>                 ____
> 
>                 Ron, ____
> 
>                 ____
> 
>                 While we are at the local vs global significance of SIDs
>                 can you please elaborate how do you resolve the conflict
>                 where given SID value is advertised by more then one
>                 node ? In fact imagine that all nodes in a domain choose
>                 to advertise the same SID value "15" to forward the
>                 traffic to their respective peers. So packet arrives at
>                 segment endpoint node A with CRH consisting of SID list
>                 15, 15, 15, 15 ... where each value 15 means different
>                 behaviour on different node. ____
> 
>                 ____
> 
>                 How do you even know which way to forward the packet ? ____
> 
>                 ____
> 
>                 See in this case your mapping plane will contain
>                 different functions on different nodes signalled with
>                 the same SID. ____
> 
>                 ____
> 
>                 I understand that you are trying to silently borrow
>                 set of procedures from SR-MPLS here as documented in
>                 RFC8660. But if you just open this RFC you will see
>                 section 2.5 or 2.6 without which you just can not simply
>                 propose to treat SID as locally significant in any form
>                 of segment routing. Of course unless you would consume
>                 two SIDs per node. ____
> 
>                 ____
> 
>                 Thx,
>                 Robert.____
> 
>                 ____
> 
>                 ____
> 
>                 On Thu, May 21, 2020 at 10:34 AM Robert Raszuk
>                 <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>                     Ron, ____
> 
>                     ____
> 
>                      > Now recall that identifiers have node local
>                     significance. ____
> 
>                     ____
> 
>                     I was talking about case described in yr draft
>                     section 7: ____
> 
>                     ____
> 
>                     "Applications can:____
> 
>                     ____
> 
>                     o Allocate SIDs so that they have *domain-wide
>                     significance*."____
> 
>                     ____
> 
>                     While not a must - it is an option. So I believe my
>                     observation stays valid till draft either removes
>                     that option or describes scaling properties
>                     differences between both domain wide and local
>                     significance of the SIDs.____
> 
>                     ____
> 
>                     Thx,____
> 
>                     R.____
> 
>                     ____
> 
>                     ____
> 
>                     On Thu, May 21, 2020 at 4:01 AM Ron Bonica
>                     <[email-masked] <mailto:[email-masked]>>
>                     wrote:____
> 
>                         Robert,____
> 
>                         ____
> 
>                         Consider the following network:____
> 
>                         ____
> 
>                           * Contains 65,000 routers____
>                           * Each router has 500 directly connected
>                             neighbors or fewer____
>                           * Uses 16-bit CRH____
> 
>                         ____
> 
>                         In this network, each node might have 65,499
>                         CRH-FIB entries:____
> 
>                         ____
> 
>                           * 64,999 CRH-FIB entries cause packets to
>                             follow the least-cost path to another node
>                             in the domain____
>                           * 500 CRH-FIB entries cause packets to
>                             traverse a specific link to a specific
>                             neighbor.____
> 
>                         ____
> 
>                         As a mnemonic device, an operator might assign
>                         identifiers as follows:____
> 
>                         ____
> 
>                           * 0-65,000 identify CRH-FIB entries that cause
>                             packets to follow the least-cost path to
>                             another node in the domain____
>                           * 65,001 – 65,565 identify CRH-FIB entries
>                             that that cause packets to traverse a
>                             specific link to a specific neighbor.____
> 
>                         ____
> 
>                         Now recall that identifiers have node local
>                         significance. So, Node A and Node B might both
>                         have a CRH-FIB entry that is identified by the
>                         value 65,001. However:____
> 
>                         ____
> 
>                           * The CRH-FIB entry on Node A causes packets
>                             to traverse a particular link towards Node X____
>                           * The CRH-FIB entry on Node B causes packets
>                             to traverse a different link towards Node Y.____
> 
>                         ____
> 
>                         I think that this example refutes the premise of
>                         your argument, so there is not further need to
>                         address the conclusion.____
> 
>                         ____
> 
>                                                                                                                   Ron____
> 
>                         ____
> 
>                         ____
> 
>                         ____
> 
>                         ____
> 
>                         Juniper Business Use Only____
> 
>                         *From:* Robert Raszuk <[email-masked]
>                         <mailto:[email-masked]>>
>                         *To:* Ron Bonica <[email-masked]
>                         <mailto:[email-masked]>>
>                         *Cc:* 6man <[email-masked] <mailto:[email-masked]>>
>                         *Subject:* RE: Size of CR in CRH____
> 
>                         ____
> 
>                         *[External Email. Be cautious of content]*____
> 
>                         ____
> 
>                         HI, ____
> 
>                         ____
> 
>                         So just to make sure I understand this analogy
>                         of 16 bit -- 2^16 = 65536 nodes. I think this is
>                         only on paper. ____
> 
>                         ____
> 
>                         Imagine I have 1000 routers so if I divide the
>                         16 bit space by 1000 I get at most 65 local node
>                         behaviours if anyone would like to embed such
>                         into the SID. ____
> 
>                         ____
> 
>                         That means that if my router have more then 65
>                         interfaces I am not able to steer packets by src
>                         route out of my router ... I must always depend
>                         on the lookup of next SID how to forward the
>                         packets. ____
> 
>                         ____
> 
>                         That also means that if I want to apply any form
>                         of NP in segment endpoint I am quite limited to
>                         the number of local functions I could use. ____
> 
>                         ____
> 
>                         To conclude - Let me restate to what I and
>                         others already said - flat SID space domain wide
>                         in mapping plane is a mistake. Yes this is like
>                         MPLS, but this does not make it great again due
>                         to that legacy. ____
> 
>                         ____
> 
>                         Many thx,
>                         R.____
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 15:04:36 +1200

Joel,
> So just what are you trying to ask?

I'm not sure what Robert's question is. Mine is something like this:

If the local domain contains routers from vendor A, routers from
vendor B, and a management system from C, what are the minimum
rules about the label's format and semantics that must be followed
to guarantee interoperability? In other words, C needs to be able
to tell both A routers and B routers the same thing in order to
set up their CRH-FIBs.

A supplementary question is: Should those rules be specified in
the basic CRH draft, or in a separate document?

(I have a similar question about the SRH work, but it probably
doesn't belong here.)

Regards
   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 21 May 2020 23:37:06 -0400

Well, it seeeems to work for MPLS without our having written that text :-)

If you assume a central controller / NMS model (there are other models), 
then the controller needs to understand what range of CRH entry values 
each node in the domain can understand (if we use 32 bit values, not all 
devices will support the same subset of 2 billion entries).  It has to 
know how (YANG model?  Other mechanisms?) to tell each node how to 
handle the entries it is responsible for.  And it needs to know what 
range the node can use for strict hops.

How it gets that information has always been quite variable.  For SR, 
people tend to assume it is advertised in routing, but even for SR that 
is not strictly required.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 17:42:49 +1200

Joel,

The difference I see is that (according to what I've been able to
understand about the SRH model, and extrapolating to the CRH model)
the labels don't just map to next-hop address but also to some
specific service or action tied to the label. In fact RFC8402
says this explicitly (emphasis added):

   Segment: an *instruction* a node executes on the incoming packet (e.g.,
   forward packet according to shortest path to destination, or, forward
   packet through a specific interface, or, *deliver the packet to a
   given application/service instance*).

   SID: a segment identifier.  Note that the term SID is commonly used
   in place of the term "Segment", though this is technically imprecise
   as it overlooks any necessary translation.

So a SID value has semantics mapped to actions. This is the bit that
doesn't seem to me is interoperable without more specification.

If this doesn't apply to CRH, I apologise for being off topic.

Regards
   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 May 2020 10:40:37 -0400

CRH can be used with identifiers with all the overloading that the 
SPRING architecture.  Just as MPLS labels can be used that way.

Much of that overloading behavior can also be delivered (with or without 
CRH) by using destination options, as other drafts show.  Which way you 
want to use the CRH identifiers determines what their semantics are. 
How you want to control your network then determines how you need to 
distribute that information.

the question of whether the decomposition of the Segment Routing 
architecture proposed in SRm6 is an appropriate solution is one that 
SPRING can debate.  On the SRm6 document.  We refreshed that because we 
think it is useful information for the community.  But it is not 
necessary for evaluating CRH.

Yours,
Joel

PS: If we actually lived with our own architectures in routing, BGP 
would be just an actual path vector reachability exchange rather than a 
hammer that is being used for more different things than I can count.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 May 2020 09:42:57 +1200

Thanks Joel. "Overloading" is a good choice of word. To be clear,
my concern is not with operators choosing to overload addresses
with specific semantics; it's that there seems to be a risk of
proprietary overloading by vendors, and that can lead to interop
issues and customer capture.

Regards
   Brian