Re: Size of CR in CRH

[Gyan Mishra <[e-mail]>]

The brilliance behind this invention of using a tag or index or pointer
whatever you would like to call it to reference the CRH-FIB instead of
carrying the full 128 bit IPv6 address or compressed v6 address in the RH
is Ron Bonica.

Kind regards

Gyan

On Sat, May 23, 2020 at 7:38 PM Gyan Mishra <[e-mail]> wrote:

> 
>
> 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
>> --------------------------------------------------------------------
>>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD