RE: CRH and RH0

Ron, 

Isn't Spring's control plane the same that is being proposed for CRH (i.e. ISIS, OSPF, BGP, PCEP, etc.) ? Please list the protocols if CRH is using something different.

I am referring to your draft in LSR WG : https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/ ... where you have Prefix and Adjacency SIDs (same as SR-MPLS) to signal/distribute the SIDs that are used for provisioning the CRH-FIB.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ron Bonica
Sent: 13 May 2020 22:47
To: Ole Troan <otroan@employees.org>; Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
Subject: RE: CRH and RH0

Ole,

First, can we at least agree that CRH is not SPRING, because it doesn't rely on SPRING's control plane.

Once we establish that, I can address the other points.

                                                           Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Ole Troan
Sent: Wednesday, May 13, 2020 1:09 PM
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 6man <6man@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
Subject: Re: CRH and RH0

[External Email. Be cautious of content]

Ron,

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

That seems at first glance to be too simplistic. At least something we need to explore further.

RH0 requires no control plane or coordination between nodes.
SRH and CRH both require a coordinated control plane. In the CRH case the tag to forwarding method and I guess similarly SID to forwarding instruction for SRH.
How you distribute this information doesn’t seem to be the distinguishing factor. Both SRH and CRH could surely use cli, netconf or a routing protocol, right?

What in my mind distinguishes RH0 from CRH/SRH is also the concept of forwarding method. RH0 does destination based forwarding. SRH has forwarding instructions. CRH has forwarding methods. Which seems to indicate that a tag can map to an arbitrary “forwarding“ instruction.

In any case, given that every node needs to be programmed this is far from generic.

Is it an option to make it generic? Not requiring the coordination? Along the lines of what Tom is proposing?

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

Cheers
Ole

> -----Original Message-----
> From: Bob Hinden <bob.hinden@gmail.com>
> Sent: Wednesday, May 13, 2020 12:16 PM
> To: 6man <6man@ietf.org>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Ron Bonica <rbonica@juniper.net>; Robert Raszuk <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> 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-6man-comp-rtg-hdr-10__;!!NEt6yMaO-gk!R-N-KViI1KQrhZq4nzP7rQB5a6QqY2jsqeNXqPK8fqJPDq1gUClNhIjOI_w4L79x$
>>
>> On Wed, May 13, 2020 at 5:41 PM Ron Bonica <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>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; 6man <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>
>> Sent: Wednesday, May 13, 2020 11:22 AM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; 6man <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> 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>
>> Sent: Wednesday, May 13, 2020 3:22 AM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: Bob Hinden <bob.hinden@gmail.com>; 6man <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
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-N-KViI1KQrhZq4nzP7rQB5a6QqY2jsqeNXqPK8fqJPDq1gUClNhIjOI9Qu5sXb$
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!R-N-KViI1KQrhZq4nzP7rQB5a6QqY2jsqeNXqPK8fqJPDq1gUClNhIjOI9Qu5sXb$
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------