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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Tue, 26 May 2020 06:21:52 +0000

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 <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Saturday, May 16, 2020 at 8:46 PM
To: Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>, "Darren Dukes (ddukes)" <ddukes=[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> On Behalf Of Greg Mirsky
Sent: Saturday, May 16, 2020 4:24 PM
To: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
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=[email-masked]<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 <[email-masked]<mailto:[email-masked]>> on behalf of Bob Hinden <[email-masked]<mailto:[email-masked]>>
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
[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!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr$>
--------------------------------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 May 2020 07:16:51 +0000

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 <[email-masked]> On Behalf Of Zafar Ali (zali)
Sent: mardi 26 mai 2020 08:22
To: Greg Mirsky <[email-masked]>; Ron Bonica <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

Thanks

Regards … Zafar

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Saturday, May 16, 2020 at 8:46 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>, IPv6 List <[email-masked]<mailto:[email-masked]>>, "Darren Dukes (ddukes)" <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Ron,

Regards,
Greg

                                                         Ron

Hi Darren,

Regards,
Greg

Thanks
  Darren

Regards,
Bob and Ole

---

From: James Guichard <[email-masked]>
Date: Tue, 26 May 2020 10:52:47 +0000

Folks,

One point of concern that I would like to highlight is the fact that when forwarding is based upon an identifier that is not self-describing one cannot determine much about a packet in flight as the identifiers are meaningless without first resolving the indirection of the mapping. Whether or not this is of great concern to a network operator I will let them comment but presumably a set of tools to resolve the mapping along a path will be necessary so that the full source routed path and current position of a packet along that path can be determined during a troubleshooting event. If you contrast that with SRv6 you can see that the same issue does not apply as the SIDs carried within the SRH are IPv6 addresses that are globally unique and therefore self-describing so the origination, current position along a source routed path, and ultimate destination of the packet are easily determined; this is also true if any compression techniques are used within the SRH as each SID will have a common prefix.

My .2c

Jim

Sent: Tuesday, May 26, 2020 2:22 AM

Hi,

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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FYA_WW7w1xp5aRBpModqMdoF5vTU%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735948368&sdata=58xRxTcBw7u55dHDq%2FzhTGxZfgmd86qocp5B7uGDi5Q%3D&reserved=0>

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8029&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735948368&sdata=VICTnQ2UDLbMMg0Yq6hB6852JAcA2yn8i6goYrBLxbk%3D&reserved=0>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?”

Thanks

Regards … Zafar

Hi Ron,

Regards,
Greg

                                                         Ron

Hi Darren,

Regards,
Greg

Thanks
  Darren

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735958327&sdata=iu8ruBp3tvY5xAxu0BLeD%2BXHVDwcQf7I0prE9hNyvCo%3D&reserved=0>

Regards,
Bob and Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735958327&sdata=cXCYXFbNspnV5%2BjQraF1GICEgNuJmiAIDlH00I9rGRA%3D&reserved=0>
--------------------------------------------------------------------

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 May 2020 13:21:43 +0200

Hi Jim,

On that very point I would rather disagree a bit. And this is not because I
just proposed Reference based Routing schema.

My disagreement is based on the fact that almost all networks today use
mapping. So just looking at the packet you actually never know how it will
get to the destination

Example:

* VPN labels are an indirection (can be per prefix or per ce or per VRF)
without knowing BGP table or in per vrf egress RIB you really can not say
to which CE it will be forwarded

* MPLS labels are indirection ... looking at the labeled packet you can't
tell much as labels are of local significance to LSRs until you either
intercept LDP or look at LIB of the immediate LSR

* IP routes are also indirection ... till you know RIB and exact next hop
you can't be sure how the packet will be forwarded.

Perhaps only if you really want to atomically specify adj by adj how to
send a packet placing adj SIDs will be helpful.

Last in all cases you still have an inner packet which has an unmodified
src and dst address pair.

Not that I find CRH mapping compelling at all as compared with SR-MPLS
already present. CRH scaling properties are sort of self destructive.

Many thx,
Robert.

On Tue, May 26, 2020 at 12:53 PM James Guichard <
[email-masked]> wrote:

> Folks,
>
>
>
> One point of concern that I would like to highlight is the fact that when
> forwarding is based upon an identifier that is not self-describing one
> cannot determine much about a packet in flight as the identifiers are
> meaningless without first resolving the indirection of the mapping. Whether
> or not this is of great concern to a network operator I will let them
> comment but presumably a set of tools to resolve the mapping along a path
> will be necessary so that the full source routed path and current position
> of a packet along that path can be determined during a troubleshooting
> event. If you contrast that with SRv6 you can see that the same issue does
> not apply as the SIDs carried within the SRH are IPv6 addresses that are
> globally unique and therefore self-describing so the origination, current
> position along a source routed path, and ultimate destination of the packet
> are easily determined; this is also true if any compression techniques are
> used within the SRH as each SID will have a common prefix.
>
>
>
> My .2c
>
>
>
> Jim
>
>
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of * Zafar Ali (zali)
> *Sent:* Tuesday, May 26, 2020 2:22 AM
> *To:* Greg Mirsky <[email-masked]>; Ron Bonica <[email-masked]
> >
> *Cc:* IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>;
> Darren Dukes (ddukes) <ddukes=[email-masked]>
> *Subject:* CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6
> Compact Routing Header (CRH)"
>
>
>
> Hi,
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FYA_WW7w1xp5aRBpModqMdoF5vTU%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735948368&sdata=58xRxTcBw7u55dHDq%2FzhTGxZfgmd86qocp5B7uGDi5Q%3D&reserved=0>
>
>
>
> [ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in
> https://tools.ietf.org/html/rfc8029
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8029&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735948368&sdata=VICTnQ2UDLbMMg0Yq6hB6852JAcA2yn8i6goYrBLxbk%3D&reserved=0>
> .
>
> 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 <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Saturday, May 16, 2020 at 8:46 PM
> *To: *Ron Bonica <[email-masked]>
> *Cc: *Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>,
> "Darren Dukes (ddukes)" <ddukes=[email-masked]>
> *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 <[email-masked]> wrote:
>
> Greg,
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Saturday, May 16, 2020 4:24 PM
> *To:* Darren Dukes (ddukes) <ddukes=[email-masked]>
> *Cc:* IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
> *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=
> [email-masked] <40cisco.com@dmarc..ietf.org>> wrote:
>
> Hi Bob and Ole.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> ------------------------------
>
> *From:* ipv6 <[email-masked]> on behalf of Bob Hinden <
> [email-masked] <[email-masked]>>
> *Sent:* Friday, May 15, 2020 6:14 PM
> *To:* IPv6 List
> *Cc:* Bob Hinden
> *Subject:* Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
>  https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735958327&sdata=iu8ruBp3tvY5xAxu0BLeD%2BXHVDwcQf7I0prE9hNyvCo%3D&reserved=0>
>
> 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.
>
> 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
>
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C6cee44e900ae4c6abd2808d8013d366c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260709735958327&sdata=cXCYXFbNspnV5%2BjQraF1GICEgNuJmiAIDlH00I9rGRA%3D&reserved=0>
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Jim Guichard <[email-masked]>
Date: Tue, 26 May 2020 07:51:56 -0400

Hi Robert,

No doubt but with IP I can at the very least determine where the packet is
going (full path) as the SRH tells me (each entry has meaning) even if I
can’t be sure how it will get there.

Jim

On Tue, May 26, 2020 at 7:22 AM Robert Raszuk <[email-masked]> wrote:

> Hi Jim,
>
> On that very point I would rather disagree a bit. And this is not
> because I just proposed Reference based Routing schema.
>
>> *To:* Greg Mirsky <[email-masked]>; Ron Bonica <
>> [email-masked]>
>> “[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.
>>
>> 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
>>
>>
>>
>> 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

---

From: James Guichard <[email-masked]>
Date: Tue, 26 May 2020 12:08:52 +0000

Hi Robert,

I might add that you may recall the horrific issues you and I had to troubleshoot in the early days of MPLS where packets were being silently discarded because the mappings were wrong (here in entered LDP-IGP synchronization feature). Fun times 😊 ..

Jim

From: Jim Guichard <[email-masked]>
Sent: Tuesday, May 26, 2020 7:52 AM
To: Robert Raszuk <[email-masked]>
Cc: Bob Hinden <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; IPv6 List <[email-masked]>; James Guichard <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>
Subject: Re: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Robert,

No doubt but with IP I can at the very least determine where the packet is going (full path) as the SRH tells me (each entry has meaning) even if I can’t be sure how it will get there.

Jim

On Tue, May 26, 2020 at 7:22 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jim,

On that very point I would rather disagree a bit. And this is not because I just proposed Reference based Routing schema.

My disagreement is based on the fact that almost all networks today use mapping. So just looking at the packet you actually never know how it will get to the destination

Example:

* VPN labels are an indirection (can be per prefix or per ce or per VRF) without knowing BGP table or in per vrf egress RIB you really can not say to which CE it will be forwarded

* MPLS labels are indirection ... looking at the labeled packet you can't tell much as labels are of local significance to LSRs until you either intercept LDP or look at LIB of the immediate LSR

* IP routes are also indirection ... till you know RIB and exact next hop you can't be sure how the packet will be forwarded.

Perhaps only if you really want to atomically specify adj by adj how to send a packet placing adj SIDs will be helpful.

Last in all cases you still have an inner packet which has an unmodified src and dst address pair.

Not that I find CRH mapping compelling at all as compared with SR-MPLS already present. CRH scaling properties are sort of self destructive.

Many thx,
Robert.

On Tue, May 26, 2020 at 12:53 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

My .2c

Jim

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Zafar Ali (zali)
Sent: Tuesday, May 26, 2020 2:22 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:[email-masked]>>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FYA_WW7w1xp5aRBpModqMdoF5vTU%2F&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321478531&sdata=1HljRgqDoSCDkIIu%2BuHnkE9SVvPbdGkqiV3YRrgg53g%3D&reserved=0>

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8029&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321478531&sdata=gmKYsnNA2GI39kQuDW7Tk%2FnkZJIcyi5vF%2B32U%2FHNmM4%3D&reserved=0>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?”

Thanks

Regards … Zafar

Hi Ron,

Regards,
Greg

                                                         Ron

Hi Darren,

Regards,
Greg

Thanks
  Darren

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321488525&sdata=L86bPgxUPprmxltcQu%2B%2BqFOGOnuzokLpwFKNV4QwKOs%3D&reserved=0>

Regards,
Bob and Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr%24&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321488525&sdata=CEBxHGI5v4BXKw9v%2FAtJtt1LPmJBcB%2FjRZGaf8bPpAE%3D&reserved=0>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321498520&sdata=%2BbhnEMj%2Bo8DAddNtvZfC5%2BcHgVr1q0byejIyGq%2FLkMo%3D&reserved=0>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cea94fd8f5d854ddcbd0308d8016b382f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260907321498520&sdata=%2BbhnEMj%2Bo8DAddNtvZfC5%2BcHgVr1q0byejIyGq%2FLkMo%3D&reserved=0>
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Tue, 26 May 2020 15:06:17 +0000

Zafar,

Tracing the path of an IPv6 packet containing CRH is somewhat easier than tracing the path of an MPLS LSP. In order to trace the path of an MPLS LSP, you need to deploy either RFC 4950 or RFC 8029. However, you don't need to deploy anything special to trace the path of an IPv6 packet that contains CRH. Traceroute just works.

Furthermore, when you trace the path of an IPv6 packet that contains CRH, each node returns either an ICMP Time exceeded message or an ICMP parameter problem message. From those messages, you can infer contents of the CRH-FIB at each node. So, there is no need for a special OAM mechanism to query the CRH-FIB.

                                                                                                             Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Tuesday, May 26, 2020 2:22 AM
To: Greg Mirsky <[email-masked]>; Ron Bonica <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>; Darren Dukes (ddukes) <ddukes=[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

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/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrcckxlUnJI$>

"[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<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrccvQJcKGT$>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?"

Thanks

Regards ... Zafar

Hi Ron,

Regards,
Greg

The question may be moot. I don't foresee any CRH OAM work. PING and TRACEROUTE "just work".

                                                         Ron

Hi Darren,

Regards,
Greg

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

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.

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.

Thanks
  Darren

Regards,
Bob and Ole

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 May 2020 18:08:14 +0200

Ron,

"just works" is great. But let's zoom in and explore how it works in
practice.

Imagine on ingress PE I am mapping to engineered north CRH path flows using
TCP dst port 80 dst IPv6 X::Y

Further imagine on the very same PE I am also mapping flows using TCP port
22 going to IPv6 dst X::Y to take south CRH path via my network.

Then mgmt station does ICMP ping  and traceroute  ... and it wants to ping
and trace from this PE over both paths. What are the four commands I
would use ?

Many thx,
Robert.

On Tue, May 26, 2020 at 5:15 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Zafar,
>
>
>
> Tracing the path of an IPv6 packet containing CRH is somewhat easier than
> tracing the path of an MPLS LSP. In order to trace the path of an MPLS LSP,
> you need to deploy either RFC 4950 or RFC 8029. However, you don’t need to
> deploy anything special to trace the path of an IPv6 packet that contains
> CRH. Traceroute just works.
>
>
>
> Furthermore, when you trace the path of an IPv6 packet that contains CRH,
> each node returns either an ICMP Time exceeded message or an ICMP parameter
> problem message. From those messages, you can infer contents of the CRH-FIB
> at each node. So, there is no need for a special OAM mechanism to query the
> CRH-FIB.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> *From:* Zafar Ali (zali) <[email-masked]>
> *Cc:* Bob Hinden <[email-masked]>; IPv6 List <ipv6@ietf..org>;
> Darren Dukes (ddukes) <ddukes=[email-masked]>; Zafar Ali
> (zali) <[email-masked]>
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/YA_WW7w1xp5aRBpModqMdoF5vTU/__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrcckxlUnJI$>
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc8029__;!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrccvQJcKGT$>
> .
>
> [email-masked] <40cisco.com@dmarc..ietf.org>> wrote:
>
> Hi Bob and Ole.
>
>
>
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK$>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr$>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 26 May 2020 17:10:45 +0000

Thanks for Robert’s example.

In addition, Mapping Table based solutions usually don’t scale well.

There are many documents in SPRING WG to extend the SRv6 solution ([RFC8402]) for the specific purpose of minimizing the MTU overhead and/or supporting very long SID-lists on legacy hardware. It seems to me that CRH is just another solution. If not compatible with others, is there any benefit of having another solution?

Linda Dunbar
From: ipv6 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, May 26, 2020 11:08 AM
To: Ron Bonica <rbonica=[email-masked]>
Cc: Darren Dukes (ddukes) <ddukes=[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Ron,

"just works" is great. But let's zoom in and explore how it works in practice.

Imagine on ingress PE I am mapping to engineered north CRH path flows using TCP dst port 80 dst IPv6 X::Y

Further imagine on the very same PE I am also mapping flows using TCP port 22 going to IPv6 dst X::Y to take south CRH path via my network.

Then mgmt station does ICMP ping  and traceroute  ... and it wants to ping and trace from this PE over both paths. What are the four commands I would use ?

Many thx,
Robert.

On Tue, May 26, 2020 at 5:15 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Zafar,

Tracing the path of an IPv6 packet containing CRH is somewhat easier than tracing the path of an MPLS LSP. In order to trace the path of an MPLS LSP, you need to deploy either RFC 4950 or RFC 8029. However, you don’t need to deploy anything special to trace the path of an IPv6 packet that contains CRH. Traceroute just works.

                                                                                                             Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 26, 2020 2:22 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <ipv6@ietf..org<mailto:ipv6@ietf..org>>; Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: CRH "mapping table" and OAM - Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FYA_WW7w1xp5aRBpModqMdoF5vTU%2F__%3B!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrcckxlUnJI%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408927812&sdata=IwKnYtn9NjM%2BJ%2Fg0ZYI0JjIe8B0CggcWAKYC0%2BjLKSM%3D&reserved=0>

[ZA] Not at all. SR-MPLS uses MPLS OAM tool kit defined in https://tools.ietf.org/html/rfc8029<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Frfc8029__%3B!!NEt6yMaO-gk!WbC9uTY5VNVXPVe2D0Y1GtlupaWhs5jlj8ZwtFCmvNNLZaxU_04lGDrccvQJcKGT%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408937769&sdata=U%2B1F9AhJGoiFL8nA2JCJoocAfhWxolNgqabWb%2FHbziU%3D&reserved=0>.
[ZA] Are you suggesting you will introduce something similar to RFC8029?”

Thanks

Regards … Zafar

Hi Ron,

Regards,
Greg

                                                         Ron

Hi Darren,

Regards,
Greg

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

Thanks
  Darren

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulNkCsQgK%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408937769&sdata=jX2J%2FUP6QH3kvBJHhOV3XvfIDTlRWqYTIULrKZOAUPA%3D&reserved=0>

Regards,
Bob and Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6__%3B!!NEt6yMaO-gk!WxlH9jPuRZnF6DX0UIsFN2cS5t76jXU-Z3NMUNXACufRqrY7xBnnYVSulCrJN_hr%24&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408947727&sdata=Y2YfSda0sjvKWcu0nZYEgerocW9mgogrmidy1QM%2B5zA%3D&reserved=0>
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cef70a9c2ec6f483d3f7908d8018f189d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637261061408947727&sdata=qhE9JjN7UWGviKLJtQ5Nmq9oFx0T1P2ksXYQbJ0Ix2k%3D&reserved=0>
--------------------------------------------------------------------

---

From: Sander Steffann <[email-masked]>
Date: Tue, 26 May 2020 22:25:58 +0200

> There are many documents in SPRING WG to extend the SRv6 solution ([RFC8402]) for the specific purpose of minimizing the MTU overhead and/or supporting very long SID-lists on legacy hardware. It se…

Yes, there is
Sander