Re: Size of CR in CRH

["Joel M. Halpern" <[e-mail]>]

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


On 5/21/2020 11:04 PM, Brian E Carpenter wrote:
> Joel,
> On 22-May-20 12:21, Joel M. Halpern wrote:
>> 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?
> 
> 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
> 
>>
>> 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.
>>>
>>> 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]
>>> <mailto:[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] <mailto:[e-mail]>>
>>>      *Sent:* Thursday, May 21, 2020 4:05 PM
>>>      *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
>>>      *Cc:* 6man <[e-mail] <mailto:[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]
>>>      <mailto:[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]
>>>          <mailto:[e-mail]>>
>>>          *Sent:* Thursday, May 21, 2020 3:14 PM
>>>          *To:* Ron Bonica <[e-mail] <mailto:[e-mail]>>
>>>          *Cc:* 6man <[e-mail] <mailto:[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]
>>>          <mailto:[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]
>>>              <mailto:[e-mail]>>
>>>              *Sent:* Thursday, May 21, 2020 11:25 AM
>>>              *To:* Ron Bonica <[e-mail]
>>>              <mailto:[e-mail]>>
>>>              *Cc:* 6man <[e-mail] <mailto:[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] <mailto:[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]
>>>                  <mailto:[e-mail]>>
>>>                  *Sent:* Thursday, May 21, 2020 10:35 AM
>>>                  *To:* Ron Bonica <[e-mail]
>>>                  <mailto:[e-mail]>>
>>>                  *Cc:* 6man <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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]
>>>                          <mailto:[e-mail]>>
>>>                          *Sent:* Wednesday, May 20, 2020 6:20 PM
>>>                          *To:* Ron Bonica <[e-mail]
>>>                          <mailto:[e-mail]>>
>>>                          *Cc:* 6man <[e-mail] <mailto:[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.____
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>