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 <robert@raszuk.net> 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 <
> james.n.guichard@futurewei.com> 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 <ipv6-bounces@ietf.org> *On Behalf Of * Zafar Ali (zali)
>> *Sent:* Tuesday, May 26, 2020 2:22 AM
>> *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/
>> <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>
>>
>>
>>
>> “[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://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?”
>>
>>
>>
>> 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> on behalf of Greg Mirsky <
>> gregimirsky@gmail.com>
>> *Date: *Saturday, May 16, 2020 at 8:46 PM
>> *To: *Ron Bonica <rbonica@juniper.net>
>> *Cc: *Bob Hinden <bob.hinden@gmail.com>, IPv6 List <ipv6@ietf.org>,
>> "Darren Dukes (ddukes)" <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> 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> *On Behalf Of *Greg Mirsky
>> *Sent:* Saturday, May 16, 2020 4:24 PM
>> *To:* Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org>
>> *Cc:* IPv6 List <ipv6@ietf.org>; Bob Hinden <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 <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> on behalf of Bob Hinden <
>> bob..hinden@gmail.com <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://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.
>>
>> 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
>> 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>
>> --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>