Subject: Applicability, Use-cases, and Architecture for the CRH

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 00:41:20 +0000

Darren,
In previous emails, you suggest that the CRH draft needs information regarding Applicability, Use-cases and Architecture. After the call for adoption, we could add the proposed text, below.
Would this text address your concerns. If not, please provide specific recommendations.
                                                                         Ron

PROPOSED TEXT
----------------------

9.0 Applicability

The CRH can be used within any network where:

  *   All nodes implement IPv6.
  *   Edge node can filter inbound packets that contain the CRH.
  *   Selected nodes can process the CRH. If a node is identified in a CRH, and it is not the packet's ultimate destination, it must be able to process the CRH.
  *   All nodes can maintain a basic FIB that maps IPv6 prefixes to next-hops.
  *   Selected nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods. If a node is identified in a CRH, and it is not the packet's ultimate destination, it must be able to
  *   CRH overhead is acceptable
CRH-16  overhead is as follows:

  *   2 SIDs can be stored in a 8-byte CRH
  *   6 SIDs can be stored in a 16-byte CRH
  *   10 SIDs can be stored in a 24-byte CRH
  *   14 SIDs can be stored in a 32-byte CRH
  *   Etc.
CRH-32  overhead is as follows:

  *   1 SIDs can be stored in a 8-byte CRH
  *   3 SIDs can be stored in a 16-byte CRH
  *   5 SIDs can be stored in a 24-byte CRH
  *   7 SIDs can be stored in a 32-byte CRH
  *   Etc.

10.0 Use-cases

The CRH can be used to provide traffic steering in:

  *   Data centers
  *   Service provider networks
  *   Enterprise networks
Each of these networks may have a preferred method for populating the basic FIB and the CRH-FIB. For example, a data center may use a controller to populate both FIBs while a service provider may use an IGP to populate both FIBs.
The CRH can implemented on:

  *   ASIC-based routers
  *   Software-based routers
     *   Stand-alone
     *   In a container on a server in a data center

11.0 Architecture

CRH architecture determined entirely by RFC 8200. Specifically:

  *   IPv6 source nodes use the CRH to determine nodes that a packet visits on route to is ultimate destination.
  *   The CRH does not subsume the function of any other IPv6 extension header. For example, the CRH cannot be used for authentication, or to deliver optional internet-layer information to the packet's ultimate destination node.
  *   A packet that contains the CRH can also contain any valid combination of IPv6 extension headers. All extension header should function as per their specifications.
  *   The CRH assumes that IPv6 Destination Address semantics are as defined in RFC 8200 and RFC 4291.
  *   The CRH is processed identically on every node (See Section 5 of this document). Processing rules do not depend upon information encoded in the IPv6 Destination Address.
  *
The CRH conforms to the letter and spirit of RFC 8200. For example:

  *   A packet cannot contain two instances of the CRH
  *   A CRH cannot be added or deleted by any node along a packet's processing path

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2020 13:40:41 +1200

Hi Ron,

Looking at your draft plus this extra material, I still think that the concept of a SID is helicoptered in to some extent. It isn't obvious to me that a SID in CRH is semantically the same thing as a SID in the Spring WG. Either it is, in which case you should cite the relevant SID RFC, or it isn't, in which case there is some more writing to do.

I think you could also give an ack to the C-SIDs in https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00

Regards
   Brian Carpenter

On 16-May-20 12:41, Ron Bonica wrote:
>   * Selected nodes can process the CRH. If a node is identified in a CRH, and it is not the packet’s ultimate destination, it must be able to process the CRH.
>   * Selected nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods. If a node is identified in a CRH, and it is not the packet’s ultimate destination, it must be able to
>       o Stand-alone
>       o In a container on a server in a data center
> 
>  
> 
>  
> 
> 11.0 Architecture
> 
>  
> 
>   * The CRH does not subsume the function of any other IPv6 extension header. For example, the CRH cannot be used for authentication, or to deliver optional internet-layer information to the packet’s ultimate destination node.
>   * A CRH cannot be added or deleted by any node along a packet’s processing path
> 
>  
> 
>  
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 03:45:09 +0000

Brian,

An SRH SID is semantically very different from a CRH SID. So, I would be happy to rename the CRH SID to something else. Maybe the CRH-FIB-ID?

I would also be glad to recognize the contributions of draft-lc-6man-generalized-srh-00.

                                                                                                                 Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Friday, May 15, 2020 9:41 PM
To: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: Applicability, Use-cases, and Architecture for the CRH

[External Email. Be cautious of content]

Hi Ron,

I think you could also give an ack to the C-SIDs in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH9tRrUf-$

Regards
   Brian Carpenter

On 16-May-20 12:41, Ron Bonica wrote:
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH-k2Yi-w$

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2020 16:45:46 +1200

Ron,

Definitely, if it isn't the same, I would rename it. I like memorable acronyms, so could I suggest FIDO (Forwarding IDentity Object)?

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 May 2020 15:08:58 +1000

On Sat, 16 May 2020, 14:46 Brian E Carpenter, <[email-masked]>
wrote:

> Ron,
>
> Definitely, if it isn't the same, I would rename it. I like memorable
> acronyms, so could I suggest FIDO (Forwarding IDentity Object)?
>

The longer term used in RFC 8200 for these things is "route segments"
(although another issue with RFC 8200 is that it doesn't specifically
explicitly define what they are).

So in CRH I think they should be called "Route Segments", and identified
with "Route Segment Identifiers" (RSIDs, pronounced "R-SIDs") or "Compact
Route Segment Identifiers" (CRSIDs, pronounced "C-R-SIDs").

Regards,
Mark.

Regards,
Mark.

> > An SRH SID is semantically very different from a CRH SID. So, I would be
> happy to rename the CRH SID to something else. Maybe the CRH-FIB-ID?
> >
> > Looking at your draft plus this extra material, I still think that the
> concept of a SID is helicoptered in to some extent. It isn't obvious to me
> that a SID in CRH is semantically the same thing as a SID in the Spring WG.
> Either it is, in which case you should cite the relevant SID RFC, or it
> isn't, in which case there is some more writing to do.
> >
> > I think you could also give an ack to the C-SIDs in
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH9tRrUf-$
> >
> > Regards
> >    Brian Carpenter
> >
> >> In previous emails, you suggest that the CRH draft needs information
> regarding Applicability, Use-cases and Architecture. After the call for
> adoption, we could add the proposed text, below.
> >>
> >>   * Selected nodes can process the CRH. If a node is identified in a
> CRH, and it is not the packet’s ultimate destination, it must be able to
> process the CRH.
> >>   * Selected nodes can maintain a CRH-FIB that maps SIDs to IPv6
> addresses and forwarding methods. If a node is identified in a CRH, and it
> is not the packet’s ultimate destination, it must be able to
> >> Each of these networks may have a preferred method for populating the
> basic FIB and the CRH-FIB. For example, a data center may use a controller
> to populate both FIBs while a service provider may use an IGP to populate
> both FIBs.
> >>
> >>   * IPv6 source nodes use the CRH to determine nodes that a packet
> visits on route to is ultimate destination.
> >>   * The CRH does not subsume the function of any other IPv6 extension
> header. For example, the CRH cannot be used for authentication, or to
> deliver optional internet-layer information to the packet’s ultimate
> destination node.
> >>   * A packet that contains the CRH can also contain any valid
> combination of IPv6 extension headers. All extension header should function
> as per their specifications.
> >>   * The CRH is processed identically on every node (See Section 5 of
> this document). Processing rules do not depend upon information encoded in
> the IPv6 Destination Address.
> >>   *
> >>
> >> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH-k2Yi-w$

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 05:24:03 +0000

Folks,

RSID and CRSID both work for me. However,  I shouldn't  be allowed to name anything. I liked FIDO, too!

                                                                                         Ron

Juniper Business Use Only
From: Mark Smith <[email-masked]>
Sent: Saturday, May 16, 2020 1:09 AM
To: Brian E Carpenter <[email-masked]>
Cc: Ron Bonica <[email-masked]>; 6MAN <[email-masked]>
Subject: Re: Applicability, Use-cases, and Architecture for the CRH

On Sat, 16 May 2020, 14:46 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
Ron,

The longer term used in RFC 8200 for these things is "route segments" (although another issue with RFC 8200 is that it doesn't specifically explicitly define what they are).

So in CRH I think they should be called "Route Segments", and identified with "Route Segment Identifiers" (RSIDs, pronounced "R-SIDs") or "Compact Route Segment Identifiers" (CRSIDs, pronounced "C-R-SIDs").

Regards,
Mark.

Regards,
Mark.

   Brian
On 16-May-20 15:45, Ron Bonica wrote:
> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
> To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> I think you could also give an ack to the C-SIDs in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH9tRrUf-$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-lc-6man-generalized-srh-00__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH9tRrUf-$>
>
> Regards
>    Brian Carpenter
>
>> [email-masked]<mailto:[email-masked]>
>> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH-k2Yi-w$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WQLMM8SDvQVSEuBWhatHjEAZG7SR40xhu6n19XNDr1U4m9iTxWJQ17mZH-k2Yi-w$>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WXCRJ4mKHyPNgylXL328rFqHfGcPdZ1-dIWT4SOhYotZaFVp3acki1gwvdyPC-vH$>
--------------------------------------------------------------------

---

From: John Scudder <[email-masked]>
Date: Sat, 16 May 2020 19:43:19 +0000

> Definitely, if it isn't the same, I would rename it. I like memorable acronyms, so could I suggest FIDO (Forwarding IDentity Object)?

If Ron adopts that nomenclature, let me encourage renaming the PSSI to the Destination IDentity Object, DIDO.

—John

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 May 2020 15:56:44 -0400

Hi Ron

The draft updates looks good pertaining to Darren’s architecture request
and what was pointed out as to using different nomenclature for CRH SID as
it is completely different and giving any foo sid name you desire.

Kind regards

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 May 2020 14:01:39 -0700

Hi Brian,
comparing how CRH and G-SID proposals approach the task of the compact
segment routing in IPv6 network I find the solutions quite different. At
the same time, the solution described in the Unified Identifier in IPv6
Segment Routing Networks
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> may be
compared with the benefits of using CRH.  What do you think?

Regards,
Greg

On Fri, May 15, 2020 at 6:41 PM Brian E Carpenter <
[email-masked]> wrote:

> https://tools.ietf.org/html/draft-lc-6man-generalized-srh-00
>
> Regards
>    Brian Carpenter
>

---

From: [email-masked]
Date: Sun, 17 May 2020 00:19:00 +0200

> RSID and CRSID both work for me. However,  I shouldn’t  be allowed to name anything. I liked FIDO, too!

"There are two hard problems in computer science. Cache invalidation, naming and off by one errors."

Assuming these identifiers can map to any "packet instruction" you could possibly imagine, why not something generic like "tag" or "label".
And if you need to be specific CRH tag (or CRH label).

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 May 2020 11:42:27 +1200

Hi Greg,
On 17-May-20 09:01, Greg Mirsky wrote:
> Hi Brian,
> comparing how CRH and G-SID proposals approach the task of the compact segment routing in IPv6 network I find the solutions quite different. 

Yes, because the G-SID authors took the decision to be compatible with SRH. But the idea of a short identifier that acts as a lookup index for the SID seems to be essentially the same.

> At the same time, the solution described in the Unified Identifier in IPv6 Segment Routing Networks <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> may be compared with the benefits of using CRH.  What do you think?

I think that a reasoned comparison of alternative proposals is very desirable during an adoption discussion, so I'd welcome it, but I'm not competent to write it.

Rgds,
   Brian

> 
> Regards,
> Greg
> 
> On Fri, May 15, 2020 at 6:41 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Ron,
> 
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Ron Bonica <[email-masked]>
Date: Sun, 17 May 2020 00:19:41 +0000

Brian,

The PPSI has already been rename to the Tunnel Payload Forwarding Option. But FIDO and DIDO would have been great names.

                                                     Ron

-----Original Message-----
From: John Scudder <[email-masked]> 
Sent: Saturday, May 16, 2020 3:43 PM
To: Brian E Carpenter <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]
Subject: Re: Applicability, Use-cases, and Architecture for the CRH

—John

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 20 May 2020 10:12:05 +0000

Hi Brian, 

Many thanks for mentioning C-SID. Actually, the concepts of C-SID is really easy to be understood, and it is almost there in the IPv6 address natively due to the address planning.

Also,  this concept of C-SID is described in https://tools.ietf.org/html/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01 as well.

In G-SRv6 for compression[1], a C-SID can be called as Generalized SID(G-SID), and actually, they are the same thing.

Anyway, it is always good to make the concepts clear. 

Will read the documents of CRH ASAP, though it takes times :(

Thanks,
Cheng

[1]. https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cmpr-01

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Saturday, May 16, 2020 9:41 AM
To: Ron Bonica <rbonica=[email-masked]>; [email-masked]
Subject: Re: Applicability, Use-cases, and Architecture for the CRH

Hi Ron,

Regards
   Brian Carpenter