Re: Size of CR in CRH

[Robert Raszuk <[e-mail]>]

Hi Ron,

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

[image: image.png]

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 <[e-mail]> 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
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Thursday, May 21, 2020 6:30 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *Subject:* Re: Size of CR in CRH
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, May 21, 2020 4:05 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *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".
>
>
>
> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, May 21, 2020 3:14 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, May 21, 2020 11:25 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, May 21, 2020 10:35 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, May 20, 2020 6:20 PM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* 6man <[e-mail]>
> *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.
>
>