Re: Size of CR in CRH

[Gyan Mishra <[e-mail]>]



Ketan

Here is a easier way to understand CRH and it’s relationship to Spring WG SRM6 architecture and how  CRH can maintain its own individuality in the 6MAN WG context.

You can think of of words “overloading” “over engineering” as a way of describing SRM6 and SRV6 in the context of Spring WG,  and use of the KISS “keep it simple and stupid” acronym as a way of describing CRH in the context of 6MAN WG.

SRM6 is the Spring “overloaded” version that contains all the architecture drafts below.

The following are links to the SRm6 drafts:
 
Overview: https://datatracker.ietf.org/doc/draft-bonica-spring-sr-mapped-six/
CRH: https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/
VPN Service Labels: https://datatracker.ietf.org/doc/draft-bonica-6man-vpn-dest-opt/
SFC: https://datatracker.ietf.org/doc/draft-bonica-6man-seg-end-opt/
 
IGP Extesnsions: https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/

The 6MAN draft for CRH introduces 2 new EH routing headers and stands on its own as the “KISS” I-D.

The CRH I-D stands on its own as is a completely independent entity separate from the SRM6 architecture documents.  The CRH draft is just a single component of the overall SRM6 architecture, but since CRH is the main component even with its simplicity it has the power to stand independently on its own with a manual or controller based CRH-FIB creation.  

CRH can stands independently of Spring SRM6 documents even though CRH is a component SRM6, and how that is accomplished is that CRH as Ron mentioned would not use the SRM6 IGP extension draft. 

As far as provisioning with 64k nodes intra domain, this can still be achieved with a centralized PCE controller as manual CLI option would not be feasible. 

As far as scalability of 16 versus 24, 32 64 size I agree 16 is more then sufficient for intra domain used in a Data Center or Tier 1 Service provider Network like Verizon or any of the other Tier 1 or 2 providers.  

As far as massive massive massive scalability for both CRH and SRM6 -> both can scale well beyond SRv6 or SRv6 even with the six plus compression techniques and as far as extremely long traffic steering strict paths due to the basic concept of the routing segment in the RH being a “tag or pointer or index” If you will and not a compressed IPv6 prefix as done with the other SRv6 compression techniques. 

As far as the extremely long paths note that the the KISS rule with CRH is where it shines with much less architectural baggage and can be viable solution as compares to SRv6 or any of the compression variants. 

I don’t think we really need to allocate RH for larger then 16 bit use case now unless we really have an immediate use case for the short term.

6lo mentioned by Pascal as a RPL new RH did that does not have a separation architecture or use case drafts and is an RFC and is outside of Spring WG.

https://tools.ietf.org/html/rfc8138#section-5.1

Fred as well mentioned a draft for variable sized RH to be used over the internet part of this thread also outside of Spring WG.

Kind regards 

Gyan

> On Thu, May 21, 2020 at 1:33 PM Ketan Talaulikar (ketant) <ketant=[e-mail]> wrote:
> Hi Ron,
> 
> Looks like the CRH solution is spread over multiple napkins and you are now taking them out of your pocket one by one 😉
> 
> I would wish that everything was documented and put before the WG adoption for a proper evaluation of what it is - i.e. the architecture, applicability, use-cases and requirements.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Ron Bonica
> Sent: 21 May 2020 01:04
> To: [e-mail]
> Cc: 6man <[e-mail]>
> Subject: RE: Size of CR in CRH
> 
> Ole,
> 
> Tags have node local scope. And an node may be associated with multiple tags. Assume the following:
> 
> - Router R resides in a domain with many other routers
> - Router R has 100 neighbors, N1 through N100
> 
> So, every router in the network maintains a CRH-FIB entry that contains:
> 
> - One of Router R's IP addresses
> - A forwarding method indicating that the packet is loosely routed
> 
> R's neighbors, N1 through N100, each maintain a second CRH-FIB entry. Each of these contains:
> 
> - One of Router R's IP addresses
> - A forwarding method indicating that the packet is strictly routed
> - An interface identifier
> 
> Again, tags have node local scope. However, for the purposes of operational simplicity, an operator might allocate tags that represent loose source routing as if they had domain wide significance. For example, we said that every router in the network maintains a CRH-FIB entry that contains:
> 
> - One of Router R's IP addresses
> - A forwarding method indicating that the packet is loosely routed
> 
> All of these could be identified by the tag R. But this is not strictly required.
> 
>                                                                                                                             Ron
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]> 
> Sent: Wednesday, May 20, 2020 5:10 AM
> To: Ron Bonica <[e-mail]>
> Cc: 6man <[e-mail]>
> Subject: Re: Size of CR in CRH
> 
> [External Email. Be cautious of content]
> 
> 
> > The following factors figured into the decision to specify 2 Routing types, one with a 16-bit identifier and the other with a 32-bit identifier:
> >
> >       - Today, very few networks contain more than 65,000 routers. So, most networks could obtain best compression with a 16-bit identifier.
> >       - When 5G is deployed, we may see networks that contain more than 65,000 Cell Site Routers. These networks will need an identifier that is wider than 16 bits.
> >       - It is unlikely that we will ever see a network that contains more than 4,000,000 routers. So, we will never need an identifier that is wider than 32 bits.
> >
> > If Routing header types were in short supply, and only one were available to us, we would have to do one of the following:
> >
> >       - Select a single length (16, 24 or 32 bits)
> >       - Use the fifth byte of the Routing header to indicate the identifier length.
> >
> > The first option isn't very appealing. A 16-bit identifier is too short for some networks. A 24-bit identifier may be difficult for some ASICs to process. A 32-bit identifier gives suboptimal compression for all existing networks.
> >
> > The second option isn't very appealing either. If we use the fifth byte to indicate the identifier length, and we want the first identifier to begin on a 32-bit boundary, the next 24 bits would be wasted.
> >
> > Fortunately, Routing header types are not in short supply. The Routing Type registry has room for 255 entries. Since it was established 25 years ago, only 6 types have been allocated. Of those, two have been deprecated (RH0 and Nimrod) and two are for special use (Experiment 1 and Experiment 2).
> >
> > So, allocating two Routing types may be the best solution.
> 
> I don't think we necessarily need to settle this as part of the adoption call.
> Although it might influence someone's opionion if this adds 1 (additional) solution to the table or 2.
> 
> For clarification:
>  - Are these tags meant to be unique within the controlled domain or do they only need to be unique per node?
>  - A tag identifies a forwarding method. One node could then use many tags,
>    e.g have one tag map to each of it's outgoing interfaces? Or a tag significy a VNI?
>  - Method specific parameters. Are they meant to be embedded in the tag or somewhere else, if so where?
> 
> Best regards,
> Ole
> 
> --------------------------------------------------------------------
> 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
> --------------------------------------------------------------------