RE: CRH and RH0

Darren,

If I were to add the following sections to the draft, would they address your concern. If not, what else is needed? Please be specific.

                                                                          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.
  *   All nodes can maintain a CRH-FIB that maps SIDs to IPv6 addresses and forwarding methods
  *   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 intermediate 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: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>
Sent: Wednesday, May 13, 2020 6:01 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>; Mark Smith <markzzzsmith@gmail.com>; 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
Subject: Re: CRH and RH0

[External Email. Be cautious of content]

Hi Ron, like Shuping mentioned, SHR has an architecture document (RFC8402), problem statement (RFC7855) and use cases in RFC8354 & RFC8355 to justify need for a SRH (RFC8754).

CRH now has none.  Where are its architecture, applicability statement, use-cases documents?  This will let the WG evaluate the overall solution.
You used to have a normative reference to SRm6 but you removed it apparently to distance this work from SPRING and SRm6.

Darren

On May 13, 2020, at 4:39 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>> wrote:

Robert,

As Darren points out, the SRH has so much stuff that CRH lacks:

  *   Tags
  *   Flags
  *   TLVs

The CRH is a humble routing header that steers a packet along a delivery path. It can be describe in fourteen pages, with lots of white space.

Maybe it should be called the Unpretentious Routing Header (URH) 😉

                                                                 Ron

Juniper Business Use Only
From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Sent: Wednesday, May 13, 2020 4:16 PM
To: Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>>
Cc: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>; Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Subject: Re: CRH and RH0

[External Email. Be cautious of content]

> Compact Routing Header.

I am actually completely shocked what happened and why is it not being called SRH+ ....

;-)

Take care,
R.

On Wed, May 13, 2020 at 10:09 PM Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>> wrote:
Compact Routing Header.
On Thu, 14 May 2020, 05:58 Ron Bonica, <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Erik,

I could rename the CRH to something else. Maybe the Programmed Routing Header (PRH)? But would that make a difference to the folks who are voicing objections?

                                                 Ron

Juniper Business Use Only

-----Original Message-----
From: Erik Kline <ek.ietf@gmail.com<mailto:ek.ietf@gmail.com>>
Sent: Wednesday, May 13, 2020 1:56 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
Subject: Re: CRH and RH0

[External Email. Be cautious of content]

I too find myself agreeing with Bob.

Two random comments:

  [1] there might be a better term than "compressed" with less baggage (naming is hard)

  [2] for many, the architecture for distributing CP information is "my SDN", so I'm not convinced all the CP distribution needs to be worked out in advance

On Wed, May 13, 2020 at 9:27 AM Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
>
> Bob,
>
> I think that your analysis is absolutely correct. Anything that relies on SPRING routing protocols is SPRING.
>
> I would add the corollary statement, anything that does not rely on SPRING routing protocols is not SPRING.
>
> Therefore, if CRH can be deployed in the absence of any routing protocol at all  (i.e., with static routes and a statically configured CRH-FIB), it is not SPRING.
>
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>
> Sent: Wednesday, May 13, 2020 12:16 PM
> To: 6man <6man@ietf.org<mailto:6man@ietf.org>>
> Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; Ron Bonica
> <rbonica@juniper.net<mailto:rbonica@juniper.net>>; Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> Subject: Re: CRH and RH0
>
> Gentlepeople,
>
> IPv6 routing headers starting with RFC1883 published in 1995 used the term “segments” to identify elements in the list of addresses.   In that sense, all IPv6 routing headers do some form of segment routing.  It’s a generic term that has been around for 25 years.
>
> I think the underlying question with CRH is does it conflict with what is being done in the Spring w.g.
>
> To my thinking, what is being done in Spring is an architecture for distributing information that can be used to create source routes for SRH (RFC8754).   Anything that relies on that set of Spring routing protocols is part of the working being done in Spring.
>
> Likewise, to my thinking I don’t think that means that all new IPv6 routing headers conflict with the work being done in the Spring w.g.
>
> Bob
>
>
> > On May 13, 2020, at 8:55 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
> >
> > Ron,
> >
> > Oh - haven't we established just yesterday that you will not be referencing RH0 any longer with CRH proposal  ?
> >
> > It's like you are trying to build a vehicle  .. it has wheels, steering and even seats (no engine and no belts for now). But you keep insisting - it is not a car.
> >
> > See if you put normative reference to segment routing up to version -10 then suddenly drop it with no major change to the body of the draft the intentions are just obvious:
> >
> > 13.  References
> >
> >
> >
> > 13.1.  Normative References
> >
> >
> >    [
> > I-D.bonica-spring-srv6-plus
> > ]
> >               Bonica, R., Hegde, S., Kamite, Y., Alston, A., Henriques,
> >               D., Jalil, L., Halpern, J., Linkova, J., and G. Chen,
> >               "Segment Routing Mapped To IPv6 (SRm6)",
> > draft-bonica-
> > spring-srv6-plus-06 (work in progress), October 2019.
> >
> > REF:
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica>
> > -6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305D
> > lUw8Cr1FGDjAbPI5e93Il4WpTsbTWL9bL9$
> >
> > On Wed, May 13, 2020 at 5:41 PM Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
> > Robert,
> >
> >
> >
> > Oh, btw. RH0 had a “Segments Left” field. Because it talked about segments, would you like to claim that it was also SR?
> >
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> > From: Ron Bonica
> > Sent: Wednesday, May 13, 2020 11:40 AM
> > To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> > Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
> > Subject: RE: CRH and RH0
> >
> >
> >
> > Robert,
> >
> >
> >
> > So, you are really sure that these people don’t exist. Would you like to make a more explicit statement?
> >
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> > From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> > Sent: Wednesday, May 13, 2020 11:22 AM
> > To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
> > Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
> > Subject: Re: CRH and RH0
> >
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> >
> > Hi Ron,
> >
> >
> >
> > >  Are you questioning whether that statement is true?
> >
> >
> >
> > Yes. Especially this point: " Are not interested in SR"
> >
> >
> >
> > Your draft only talks about SIDs and segments so no matter how you call it the core purpose is segment routing.
> >
> >
> >
> > Take care,
> > R.
> >
> >
> >
> > On Wed, May 13, 2020 at 5:13 PM Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
> >
> > Robert,
> >
> >
> >
> > At the interim meeting, I said that there are IPv6 operators who:
> >
> >
> >
> > ·         Want CRH
> >
> > ·         Are not interested in SR
> >
> > ·         Are averse to SRv6
> >
> >
> >
> > Are you questioning whether that statement is true?
> >
> >
> >
> >                                                           Ron
> >
> >
> >
> >
> >
> >
> >
> > Juniper Business Use Only
> > From: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
> > Sent: Wednesday, May 13, 2020 3:22 AM
> > To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
> > Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>; 6man <6man@ietf.org<mailto:6man@ietf.org>>
> > Subject: Re: CRH and RH0
> >
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> >
> > Hi Ron,
> >
> >
> >
> > Given that it is only fifteen pages long, I suspect that progressing it would be less work than arguing about whether to progress it.
> >
> >
> >
> > Sometimes committing a bit more work yields much better results in the long run ...
> >
> >
> >
> > So it is clear that you are not just trying to fix suboptimalities of IPv6 encoding out of the woods. The goal is clear to get this in and use it as a hook to show in SPRING and other routing WGs in IETF that since you have CRH accepted as a WG docs in 6man other groups should follow along and work on SRm6 encodings.
> >
> >
> >
> > The mapping plane between SIDs and labels is already in place in SR-MPLS. Just changing few bit here and there does not make new proposal to stand on its own.
> >
> >
> >
> > I think it has been clearly stated by 6man chairs and AD that any work on SRm6 can be taken on only after SPRING WG accepts the main concept and adopts the main doc as a WG item.
> >
> >
> >
> > So I recommend we go via this proper path with the full picture in mind and the ultimate objective for CRH.
> >
> >
> >
> > Best regards,
> >
> > R.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org<mailto:ipv6@ietf.org>
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
> __;!!NEt6yMaO-gk!QcAL7_ALlBjQGtAnsGVN1JsDVd305DlUw8Cr1FGDjAbPI5e93Il4W
> pTsbVcgbtWl$
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TjE3Uqlf3fJa9c2ENZOsvyJsNfZo_fj0sAV2EQTo1IIC8Q3TyFLz3m5vPgpU7JdB$>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFHzGcUlAy_yKte9j0LvSMyl512vVcOHpMtJNak9PgeVCPi4-rmsxuwpNLvR631g$>
--------------------------------------------------------------------