RE: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Dear all

I’m not even sure I reply to the right thread; but since a lot of people are working very hard and sharing great ideas at network programming, there’s a use case that I want to make sure is covered in the solution space that you guys are working on, unless we want RAW and/or DetNet to come up with yet another RH.

The RAW WG was just formed in the routing are a, and for now is documenting the problem space, use cases, and the architecture/framework that we think addresses that space. We do not have WG docs yet so all I can point you on FWIW is personal submissions. In particular there’s the (very) early https://tools.ietf.org/html/draft-pthubert-raw-architecture-03#section-7.3 . If you open that doc you’ll find that RAW separates the PCE and the new SRE that makes the forwarding decision, and that BIER and SRv6 are envisioned in the solution space. This happens in particular when the SRE is located at the ingress only, and the forwarding plan in programmed into the packets.

Keep safe;

Pascal

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Zafar Ali (zali)
Sent: mardi 26 mai 2020 08:22
To: Greg Mirsky <gregimirsky@gmail.com>; Ron Bonica <rbonica@juniper.net>
Cc: IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>; Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

I agree with Greg. OAM is not only ping/traceroute.

The CRH “mapping table” also bring additional operation complexities and hence need for OAM tools to debug.

Even for the use of Traceroute in a CRH network, I would like to remind Ron of the following email thread.
https://mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/

“[RB] In reality, the debuggability characteristics of SRv6+ are very similar to those of SR-MPLS. We have the same mapping from a short identifier (SRv6+ SID or SR-MPLS Label) to an IPv6 address.
[RB] So, would you like to argue that debuggability is a huge issue in SR-MPLS?

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029.
[ZA] Are you suggesting you will introduce something similar to RFC8029?”

Ron then responded with the need for extending RFC 5837 (which is essentially bringing SR-MPLS OAM tool kit for IPv6).

This is not surprising as CRH is just a poor re-engineering of SR-MPLS Data Plane with IPv6 Control Plane [RFC8663].

Thanks

Regards … Zafar

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Saturday, May 16, 2020 at 8:46 PM
To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>
Cc: Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>, IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>, "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org<mailto:ddukes=40cisco.com@dmarc.ietf.org>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Ron,
I agree that ICMP will work under CRH as it works today without it. But OAM is not only ping/traceroute. I think that there is value in checking out all known FM and PM OAM tools. Though, I would not be surprised to find out that everything works with CRH out-of-the-box way.

Regards,
Greg

On Sat, May 16, 2020, 17:04 Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
Greg,

The question may be moot. I don’t foresee any CRH OAM work. PING and TRACEROUTE “just work”.

                                                         Ron

Juniper Business Use Only
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Greg Mirsky
Sent: Saturday, May 16, 2020 4:24 PM
To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Cc: IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>; Bob Hinden <bob.hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[External Email. Be cautious of content]

Hi Darren,
I'm confused by what I think is a suggestion that any work on OAM relevant to an IPv6 EH does not belong in 6man WG. If that is what you've suggested, then what about draft-ietf-6man-spring-srv6-oam, which is in WGLC, and Ali and I are working to resolve comments? Are you suggesting that we should stop the authors of that draft find a different WG to anchor or hold the BoF? I'm puzzled.

Regards,
Greg

On Sat, May 16, 2020 at 7:00 AM Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc..ietf.org>> wrote:
Hi Bob and Ole.

I’m not supporting the draft for adoption by 6man. I know you’re shocked ;).

I have one main concern with 6man adoption that I think many can agree with.

This draft will require substantial work related to the 16/32bit identifier (CP and OAM) that is not ipv6 nor ipv6 maintenance and for which this working group does not have a mandate nor, traditionally, expertise to drive.

Others have said “this is not 6man’s concern” and I agree because 6man is an ipv6 maintenance WG, not the segment mapping working group.  I believe the authors should find a WG with that concern to drive this work. I know starting work without requirements is fun and exciting, but you will likely end up at the wrong destination.

Brian had one suggestion on this topic.

In the past I’ve suggested SPRING, or if the authors desire, a BOF to build consensus and gather requirements for its parent SRm6 work or some variant of it.

I hope the authors, WG, chairs and AD consider these points during this adoption call.

Thanks
  Darren

________________________________
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Bob Hinden <bob..hinden@gmail.com<mailto:bob.hinden@gmail.com>>
Sent: Friday, May 15, 2020 6:14 PM
To: IPv6 List
Cc: Bob Hinden
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

This message starts a two-week 6MAN call on adopting:

 Title:          The IPv6 Compact Routing Header (CRH)
 Authors:        R. Bonica, Y. Kamite, T. Niwa, A. Alston, L. Jalil
 File Name:      draft-bonica-6man-comp-rtg-hdr-21
 Document date:  2020-05-14

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK$>

as a working group item. Substantive comments regarding adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.

Please note that this is an adoption call, it is not a w.g. last call for advancement, adoption means that it will become a w.g. draft.  As the working group document, the w.g. will decide how the document should change going forward.

This adoption call will end on 29 May 2020.

The chairs note there has been a lot of discussions on the list about this draft.   After discussing with our area directors, we think it is appropriate to start a working group adoption call.  The authors have been active in resolving issues raised on the list.

Could those who are willing to work on this document, either as contributors, authors or reviewers please notify the list.   That gives us an indication of the energy level in the working group
to work on this.

Regards,
Bob and Ole
--------------------------------------------------------------------
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!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr$>
--------------------------------------------------------------------