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

[Robert Raszuk <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> *On Behalf Of * Zafar Ali (zali)
> *Sent:* Tuesday, May 26, 2020 2:22 AM
> *To:* Greg Mirsky <[e-mail]>; Ron Bonica <[e-mail]
> >
> *Cc:* IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>;
> Darren Dukes (ddukes) <ddukes=[e-mail]>
> *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 <[e-mail]> on behalf of Greg Mirsky <
> [e-mail]>
> *Date: *Saturday, May 16, 2020 at 8:46 PM
> *To: *Ron Bonica <[e-mail]>
> *Cc: *Bob Hinden <[e-mail]>, IPv6 List <[e-mail]>,
> "Darren Dukes (ddukes)" <ddukes=[e-mail]>
> *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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Greg Mirsky
> *Sent:* Saturday, May 16, 2020 4:24 PM
> *To:* Darren Dukes (ddukes) <ddukes=[e-mail]>
> *Cc:* IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
> *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=
> [e-mail] <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 <[e-mail]> on behalf of Bob Hinden <
> [e-mail] <[e-mail]>>
> *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
> [e-mail]
> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>