Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

From: Bob Hinden <[email-masked]>
Date: Fri, 15 May 2020 15:13:55 -0700

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

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 May 2020 09:52:38 +1000

I support adoption.

The argument that this working group can't adopt CRH without a whole suite
of supporting control plane protocols doesn't apply in my opinion.

This working group didn't define OSPFv3, IS-IS extensions for IPv6 or
Multi-protocol BGP support for IPv6 itself either - they were developed in
other working groups.

This working group defines the IPv6 protocol building blocks upon which
others can use to build upon.

I am willing to commit time to working on CRH, as it solves a problem that
has existed since RFC 1883 - the overhead of a source route with a set of
128 bit addresses.

It is not a new problem. What is relatively new (3-4 years or so) is the
recognition of the significance of the overhead of using 128 bit addresses
in a source route, due to SPRING's work.

6man need to solve this problem in a way that is consistent with both the
architecture and design of IPv6, in a way that is compatible with the
existing, very "brownfield" deployment of billions of IPv6 capable nodes.

Regards,
Mark.

On Sat, 16 May 2020, 08:14 Bob Hinden, <[email-masked]> wrote:

> 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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Andrew Alston <[email-masked]>
Date: Sat, 16 May 2020 00:06:00 +0000

I also  support the adoption of this draft – and echo  Mark’s sentiments below.

It also point out that the argument that because additional protocols may be needed this is out of scope of 6man is specious at best, when we consider it was 6man that developed the SRH, which the same individuals are arguing makes CRH unnecessary, while at the same time developing a raft of additional control plane mechanisms to support the SRH in a series of other working groups.

As Mark points out, CRH is a building block – upon which people may build – be in that in the context of standardized protocols or even if they choose to do so, internal applications.  The ability of CRH to be used for a raft of different purposes is one the major attractions to me, since it allows innovation to be built on top of it, both in the context of the IETF and outside of the IETF.

Hence, I fully support this draft and am proud to have my name on it.

Thanks

Andrew

From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Date: Saturday, 16 May 2020 at 02:53
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I support adoption.

The argument that this working group can't adopt CRH without a whole suite of supporting control plane protocols doesn't apply in my opinion.

This working group didn't define OSPFv3, IS-IS extensions for IPv6 or Multi-protocol BGP support for IPv6 itself either - they were developed in other working groups.

I to support the adoption of this draft – and echo

This working group defines the IPv6 protocol building blocks upon which others can use to build upon.

I am willing to commit time to working on CRH, as it solves a problem that has existed since RFC 1883 - the overhead of a source route with a set of 128 bit addresses.

It is not a new problem. What is relatively new (3-4 years or so) is the recognition of the significance of the overhead of using 128 bit addresses in a source route, due to SPRING's work.

6man need to solve this problem in a way that is consistent with both the architecture and design of IPv6, in a way that is compatible with the existing, very "brownfield" deployment of billions of IPv6 capable nodes.

Regards,
Mark.

On Sat, 16 May 2020, 08:14 Bob Hinden, <[email-masked]<mailto:[email-masked]>> wrote:
This message starts a two-week 6MAN call on adopting:

 https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr>

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://www.ietf.org/mailman/listinfo/ipv6>
--------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 May 2020 20:19:58 -0400

This document is clear.  It describes a useful extension header that 
addresses real needs that have been identified by operators.
As such, I believe the working group should adopt this document, and 
work towards publishing it.

Yours,
Joel

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 00:30:43 +0000

Bob,

This shouldn't be a surprise, but I also support adoption.

CRH doesn't break any existing technology. It doesn't consume scarce resource (e.g., Routing type numbers). It isn't so complex that it will consume many review cycles. (Version 21 of this draft is fourteen pages long, including boilerplate, references and lots of whitespace).

It has an implementation and an experimental deployment.  It is also applicable in many deployment scenarios, some of which are known today, and some of which will be discovered in the future.

                                                                                                                Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Andrew Alston
Sent: Friday, May 15, 2020 8:06 PM
To: Mark Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

[External Email. Be cautious of content]

I also  support the adoption of this draft - and echo  Mark's sentiments below.

As Mark points out, CRH is a building block - upon which people may build - be in that in the context of standardized protocols or even if they choose to do so, internal applications.  The ability of CRH to be used for a raft of different purposes is one the major attractions to me, since it allows innovation to be built on top of it, both in the context of the IETF and outside of the IETF.

Thanks

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Mark Smith <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 16 May 2020 at 02:53
To: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I support adoption.

I to support the adoption of this draft - and echo

Regards,
Mark.

 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!RtzalVTSBqPzq9-L37sgXXFTWbf3NWZWySgk3Wb5vTektwLyifAcVwQdBXcHFCyD$>

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!RtzalVTSBqPzq9-L37sgXXFTWbf3NWZWySgk3Wb5vTektwLyifAcVwQdBTcs6O-a$>
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Fri, 15 May 2020 18:44:35 -0700

I support WG adoption. CRH defines a very clean and efficient routing
header.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 May 2020 13:47:52 +1200

Mark, and everybody,
On 16-May-20 11:52, Mark Smith wrote:
...
> The argument that this working group can't adopt CRH without a whole suite of supporting control plane protocols doesn't apply in my opinion.

I agree with that; it isn't our job. On the other hand, progressing this draft without advice from the Routing Area that it is needed would be a bit foolish IMHO.
So can we ask the chairs or AD to ask the Routing ADs for their input?

This draft, like SRV6, creates a significant ops and management challenge. It's easy to say "just use NETCONF" and a lot harder to do it. At some point, we probably need to hear from the Ops ADs too.

    Brian

> On Sat, 16 May 2020, 08:14 Bob Hinden, <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>
>     Administrative Requests: https://www..ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 02:43:10 +0000

Hi WG,
My main concern is the security aspect.
It has been in discussion in another thread "Questions regarding the security mechanisms".
Hope it could be carefully considered and discussed, especially there is the painful example of RH0 deprecated by RFC5095.
There is of course RFC6554 and RFC8754 which is designed later after the deprecation and which could be carefully learned and referenced.

Ole said and repeated that "In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain."
https://mailarchive.ietf.org/arch/msg/ipv6/UyXsGeI7IDM9_Z1lipG70gIzTLY/

I was even worried about whether such attack could happen from Internet if there is no mandatory and deployable security mechanism on the wide boundary of a network.

Brian observed the "limited-domain" pattern that is widely used in modern protocol design and put the heavy emphasis on the domain boundary security.
https://tools.ietf.org/html/draft-carpenter-limited-domains-13

The RFC8754 section 5.1 IMO is the only boundary security mechanism operable/controllable/deployable so far I've seen for an IPv6 network that is widely connected to Internet.
Please correct me if you have some other better ones.
https://tools.ietf.org/html/rfc8754

BTW: 
I don't think it deserved to throw away everything that SRv6/SRH have worked out (e.g., the RFC8754 section 5.1) just to claim the independence on them.
I have an I-D of IPv6-EH using many of the design patterns of SRv6/SRH with a reference to RFC8754 but I still insist and show its independent part.

Thanks and Best wishes,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Xing Li <[email-masked]>
Date: Sat, 16 May 2020 10:34:05 +0800

I support WG adoption. CRH.

We have tested the SRv6 and CRH in CERNET2 (which is one of the largest 
IPv6-only backbones in the world). Both techniques work smoothly. 

One of the important fact is that the CRH can operate with current IS-IS 
support of different vendors in the CERNET2 backbone and CRH can 
co-exist with SRv6 in the backbone.

In summary, as an operator, we see the great value of CRH and therefore 
support its WG adoption.

Regards,

xing
CERNET Center

Bob Hinden 写道:
> ------------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 May 2020 13:04:35 +1000

On Sat, 16 May 2020, 12:43 Xiejingrong (Jingrong), <[email-masked]>
wrote:

> Hope it could be carefully considered and discussed, especially there is
> the painful example of RH0 deprecated by RFC5095.
> There is of course RFC6554 and RFC8754 which is designed later after the
> deprecation and which could be carefully learned and referenced.
>
> Ole said and repeated that "In fact I don't see how the CRH draft prevents
> the RFC5095 attack to happen inside of the CRH limited domain."
> I was even worried about whether such attack could happen from Internet if
> there is no mandatory and deployable security mechanism on the wide
> boundary of a network.
>
> Brian observed the "limited-domain" pattern that is widely used in modern
> protocol design and put the heavy emphasis on the domain boundary security.
> The RFC8754 section 5.1 IMO is the only boundary security mechanism
> operable/controllable/deployable so far I've seen for an IPv6 network that
> is widely connected to Internet.

RFC4193, a limited domain and local network only address space.

See also slide 50.

"Getting IPv6 Private Addressing Right"
https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/2.3_Mark_Smith_AusNOG2019.pdf

>
> BTW:
> I don't think it deserved to throw away everything that SRv6/SRH have
> worked out (e.g., the RFC8754 section 5.1) just to claim the independence
> on them.
> I have an I-D of IPv6-EH using many of the design patterns of SRv6/SRH
> with a reference to RFC8754 but I still insist and show its independent
> part.
>
> Thanks and Best wishes,
> Jingrong
>

---

From: Ron Bonica <[email-masked]>
Date: Sat, 16 May 2020 04:04:33 +0000

Jingrong,

The CRH security model is nearly identical to the SRH security model. In both cases, domain ingress nodes deploy ACLs that filter potentially harmful packets.

In the case of the SRH, ACLs filter packets addressed to SIDs in the network interior. In the case of CRH, ACLs filter packets that contain the CRH and are addressed to interfaces in the network interior.

In both cases, the processing node can be assured that the Routing header (SRH or CRH) came from a trusted source inside of the network.

                                                                   Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Friday, May 15, 2020 10:43 PM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi WG,

Ole said and repeated that "In fact I don't see how the CRH draft prevents the RFC5095 attack to happen inside of the CRH limited domain."
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/UyXsGeI7IDM9_Z1lipG70gIzTLY/__;!!NEt6yMaO-gk!XNBw5zIRuL9n6EU2w2SwjVeEwumn_mwyb7jKLAdahntyDvjhPixAv0cv2DEng7f6$

Brian observed the "limited-domain" pattern that is widely used in modern protocol design and put the heavy emphasis on the domain boundary security.
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-carpenter-limited-domains-13__;!!NEt6yMaO-gk!XNBw5zIRuL9n6EU2w2SwjVeEwumn_mwyb7jKLAdahntyDvjhPixAv0cv2CLne-AK$

The RFC8754 section 5.1 IMO is the only boundary security mechanism operable/controllable/deployable so far I've seen for an IPv6 network that is widely connected to Internet.
Please correct me if you have some other better ones.
https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8754__;!!NEt6yMaO-gk!XNBw5zIRuL9n6EU2w2SwjVeEwumn_mwyb7jKLAdahntyDvjhPixAv0cv2JoLLr1M$

BTW:

Thanks and Best wishes,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

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

Regards,
Bob and Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!XNBw5zIRuL9n6EU2w2SwjVeEwumn_mwyb7jKLAdahntyDvjhPixAv0cv2NhaaFJ2$
--------------------------------------------------------------------

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Sat, 16 May 2020 08:14:59 +0200

I support adoption.

CRH is extremely simple, containing only few fields (most of them are mandatory in any routing header anyway), making it very easy to parse. It has experimental deployment, and both ASIC and Linux based implementations. Is very compact (six segments fit in a 16-byte CRH), and inline with overall IPv6 framework (e.g. AH). And, it has applicability beyond Segment Routing.

Thanks,
Krzysztof

> On 2020 -May-16, at 00:13, Bob Hinden <[email-masked]> wrote:
>

---

From: Melchior Aelmans <[email-masked]>
Date: Sat, 16 May 2020 09:10:06 +0200

I support adoption of this work, thanks authors so far!
I’m willing to invest some time to contribute or review if needed. 
The work is valuable, already made good progression and is applicable beyond only SR. 

Thanks,
Melchior

> Op 16 mei 2020 om 00:14 heeft Bob Hinden <[email-masked]> het volgende geschreven:
>

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 07:29:52 +0000

Hi Ron,
Thanks for the quick response. 
Let's move to the "Questions regarding the security mechanisms" thread for the security mechanism discussion.
(I have added some additional response mails there, including the difference of "CRH security model" and the "SRH security model" in my understanding)

Best regards
Jingrong

-----Original Message-----
From: Ron Bonica [mailto:[email-masked]] 
Sent: Saturday, May 16, 2020 12:05 PM
To: Xiejingrong (Jingrong) <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Jingrong,

                                                                   Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Xiejingrong (Jingrong)
Sent: Friday, May 15, 2020 10:43 PM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi WG,

BTW:

Thanks and Best wishes,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 16 May 2020 08:18:32 +0000

Hi Mark
Thanks for the introduction of RFC4193.
The RFC8754 boundary security mechanism is still unique IMO.
The IPv6 ULA is just a candidate element of the mechanism, instead of the mechanism itself.

Thanks
Jingrong

From: Mark Smith [mailto:[email-masked]]
Sent: Saturday, May 16, 2020 11:05 AM
To: Xiejingrong (Jingrong) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

On Sat, 16 May 2020, 12:43 Xiejingrong (Jingrong), <[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

See also slide 50.

BTW:

Thanks and Best wishes,
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 16 May 2020 11:16:57 +0100

>   https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr

I'd like to see this adopted.  Simplified path steering would be rather 
useful for internet exchanges, many of which have deployed vxlan in 
preference to mpls.

Nick

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 16 May 2020 10:37:55 +0000

I support the adoption.
Mark has said what I wanted to say. It's a simple, clean, useful and generic building block in IPv6, and ready to be worked on by the WG.

Jeffrey

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Friday, May 15, 2020 7:53 PM
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I support adoption.

Regards,
Mark.

 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!XblpMb4jqsF-EHjM1SrhkgeZi4EvdQPastanzPbwlzprRPhYrL8LwSxEFHRbRx9m$>

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!XblpMb4jqsF-EHjM1SrhkgeZi4EvdQPastanzPbwlzprRPhYrL8LwSxEFBSoarzw$>
--------------------------------------------------------------------

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sat, 16 May 2020 13:59:48 +0000

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]> on behalf of Bob Hinden <[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)"

Regards,
Bob and Ole

---

From: Andrew Alston <[email-masked]>
Date: Sat, 16 May 2020 14:44:24 +0000

Darren…

Can you please explain the double standard here – where the additional development on segment routing was done in other working groups (IDR/LSR/SPRING etc) – but – last I checked –

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26

That 6man – does refer to this working group right?  Or am I confused.

Now – let me be very clear before someone claims we’re trying to replace the SRH – which is not the case – I am merely contrasting your arguments to another case where a routing header was developed – and the rest of the work – was done elsewhere as needed, and which you had nom issue with.

So – to be frank – from my perspective  and speaking only for myself – I see this as yet another red herring popped out of thin air.

Thanks

Andrew

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

Hi Bob and Ole.

Thanks
  Darren

Regards,
Bob and Ole

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 16 May 2020 08:51:11 -0700

I support strongly the adoption of this draft.

First, as to the SRH/CRH discussion, please either clearly define and apply
the _same_ standard and discussion to all those header drafts or don't
apply any "asks" (security, a "must" for architecture and other real
concerns as well as herrings thrown out) otherwise I'm not sure what
"process" is being run here. Something that doesn't have a clear, objective
process should not apply any "decision standard" since it will only produce
a race to the bottom in logical fallacy emails which some of the threads
here suffered from already. If you supply the standard, either adopt all
drafts that fulfill the standard and work on them or reject all/stop
working on them.

The extension is simple & IMO practical if one needs to source route stuff
(which is architecturally and operationally a discussion in itself
independent of this draft of course) and gives careful consideration both
to practical ASIC implementation and those pesky things like OAM. Also, it
does not change the semantics of an IPv6 address to be "something else we
can change daily as to its semantics" which always triggered my feeble
security concerns detector.

--- tony

On Sat, May 16, 2020 at 7:45 AM Andrew Alston <
[email-masked]> wrote:

> Darren…
>
>
>
> Can you please explain the double standard here – where the additional
> development on segment routing was done in other working groups
> (IDR/LSR/SPRING etc) – but – last I checked –
>
>
>
> Now – let me be very clear before someone claims we’re trying to replace
> the SRH – which is not the case – I am merely contrasting your arguments to
> another case where a routing header was developed – and the rest of the
> work – was done elsewhere as needed, and which you had nom issue with.
>
>
>
> So – to be frank – from my perspective  and speaking only for myself – I
> see this as yet another red herring popped out of thin air.
>
>
>
> Thanks
>
>
>
> Andrew
>
>
>
> *From: *ipv6 <[email-masked]> on behalf of "Darren Dukes (ddukes)"
> <ddukes=[email-masked]>
> *Date: *Saturday, 16 May 2020 at 17:00
> *To: *Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
> *Cc: *Bob Hinden <[email-masked]>
> *Subject: *Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> 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]>
> *Sent:* Friday, May 15, 2020 6:14 PM
> *To:* IPv6 List
> *Cc:* Bob Hinden
> *Subject:* Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>

---

From: Vishal Singh <[email-masked]>
Date: Sat, 16 May 2020 18:13:16 +0000

I "support" the adoption of this draft. 

It's simple and it has applicability even beyond Segment Routing.

Thanks & Regards 
Vishal Singh 

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Friday, May 15, 2020 6:14 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: John Scudder <[email-masked]>
Date: Sat, 16 May 2020 18:50:47 +0000

Hi All,

I support adoption of this document.

Much of the discussion up to this point has focused on some variation of “we’ve already got one, it’s very nice”. And it’s true that we’ve already got more than one way to do source routing, so I think it’s reasonable to address why I think the WG should spend our time on yet another one.

First, it’s self-evident at this point that source routing is of interest. This has always been true to some extent of course, that’s why we had RH0, and before that IPv4’s LSRR. But it’s increasingly true now. 

Second, there appears to be no serious dispute that doing source routing with big ol’ 128-bit IPv6 addresses in the source route is problematic, at least for some deployments. 

So that brings us to the “we’ve already got one” part. It’s true that there are proposals for more-or-less compact source routes. In all cases I’m aware of these bring with them a considerable amount of additional architectural and deployment baggage (uSID, for example) and may also drag along some extra layers of cruft that were introduced for expedient deployment (SRoMPLSoUDPoIPv6, say). CRH, by contrast, seems to me to be a minimalist building block; it does one thing, it’s small enough to spec on a napkin (well not quite) and describe in a short, simple, slide deck. Possibly most important for this WG, it’s a from-the-ground-up IPv6 design. It fits comfortably and naturally into the IPv6 paradigm. To me, none of the other solutions quite do this. Is it a complete architecture for deploying a service? Nope, and that’s fine. Neither is IPv6 itself.

I don’t mean to turn this into a beauty contest, either, despite having mentioned certain examples above. You think your baby is beautiful? Stipulated, your baby is beautiful. But that doesn’t mean it should be the only baby the WG works on. Different tools for different problems.

In short I think IPv6 should have a native, natural, minimal, composable way of doing packet steering. This document is a good starting point. Let’s do it.

—John

P.S.: Yes, I expect to actively participate in the development and review of the document.

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 May 2020 13:24:19 -0700

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

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 16 May 2020 13:27:08 -0700

Sorry, I've meant "Zafar and I are working together".

Regards,
Greg

On Sat, May 16, 2020 at 1:24 PM Greg Mirsky <[email-masked]> wrote:

>> 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: Gyan Mishra <[email-masked]>
Date: Sat, 16 May 2020 19:01:35 -0400

Hi All,

As co-author and unbiased operators point of view I strongly and fully
support the CRH draft.

There has been a lot of discussion comparing CRH with SRH as well as with
the Spring document SRM6.  SRM6 is a another flavor or SR which is why it
falls in the Spring WG and is strictly and MPLS replacement technology as
is it’s competitor technologies SR-MPLS and SRv6

CRH introduces two new compact EH routing headers used with the IPv6 data
plane that does not have the security issues inherent with RH0.

The new RH CRH has ubiquitous use cases with its simplicity allows it to be
used for both public and private traffic steering as well as use with MPLS
replacement and non MPLS use cases.

The major gain from an operators perspective is that both CRH and SRM6
solve what SR  both SR-MPLS and SRV6 was touted to solve and was the
primary reason for any operator to migrate to this new technology “intent
based traffic steering” strict hop by hop strict path which has issues with
MSD(Maximum SID Depth).

So now with CRH compact 16 and 32 bit routing segment and SRM6 16 and 32
bit SID, steering can be accomplished without MSD issues and without
requiring another technology to make strict hop by hop steering even
remotely viable.

There is another  technology mentioned in some of the CRH threads namely
PPR (Preferred path routing) steering which uses the IGP path objects to
help both SR-MPLS and SRv6 with MSD issues to make those two technologies
viable.

https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#page-17

1.3 <https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#section-1.3>.
Mitigation with MSD

   The number of SIDs in the stack a node can impose is referred as
   Maximum SID Depth (MSD) capability
   [I-D.ietf-isis-segment-routing-msd
<https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#ref-I-D.ietf-isis-segment-routing-msd>],
which must be taken into
   consideration when computing a path to transport a data packet in a

Chunduri, et al.        Expires December 18, 2018               [Page 5]

  <https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#page-6>Internet-Draft
   Preferred Path Routing (PPR) in IS-IS        June 2018

   network implementing segment routing.  [I-D.ietf-isis-mpls-elc
<https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00#ref-I-D.ietf-isis-mpls-elc>]
   defines another MSD type, Readable Label Depth (RLD) that is used by
   a head-end to insert Entropy Label pair (ELI/EL) at appropriate
   depth, so it could be read by transit nodes.  There are situations
   where the source routed path can be excessive as path represented by
   SR SIDs need to describe all the nodes and ELI/EL based on the
   readability of the nodes in that path.

   MSDs (and RLD type) capabilities advertisement help mitigate the
   problem for a central entity to create the right source routed path
   per application/operator requirements.  However the availability of
   actual paths meeting these requirements are still limited by the
   underlying hardware and their MSD capabilities in the data path.

Gyan

On Sat, May 16, 2020 at 2:51 PM John Scudder <jgs=
[email-masked]> wrote:

> Much of the discussion up to this point has focused on some variation of
> “we’ve already got one, it’s very nice”. And it’s true that we’ve already
> got more than one way to do source routing, so I think it’s reasonable to
> address why I think the WG should spend our time on yet another one.
>
> First, it’s self-evident at this point that source routing is of interest.
> This has always been true to some extent of course, that’s why we had RH0,
> and before that IPv4’s LSRR. But it’s increasingly true now.
>
> Second, there appears to be no serious dispute that doing source routing
> with big ol’ 128-bit IPv6 addresses in the source route is problematic, at
> least for some deployments.
>
> So that brings us to the “we’ve already got one” part. It’s true that
> there are proposals for more-or-less compact source routes. In all cases
> I’m aware of these bring with them a considerable amount of additional
> architectural and deployment baggage (uSID, for example) and may also drag
> along some extra layers of cruft that were introduced for expedient
> deployment (SRoMPLSoUDPoIPv6, say). CRH, by contrast, seems to me to be a
> minimalist building block; it does one thing, it’s small enough to spec on
> a napkin (well not quite) and describe in a short, simple, slide deck.
> Possibly most important for this WG, it’s a from-the-ground-up IPv6 design.
> It fits comfortably and naturally into the IPv6 paradigm. To me, none of
> the other solutions quite do this. Is it a complete architecture for
> deploying a service? Nope, and that’s fine. Neither is IPv6 itself.
>
> I don’t mean to turn this into a beauty contest, either, despite having
> mentioned certain examples above. You think your baby is beautiful?
> Stipulated, your baby is beautiful. But that doesn’t mean it should be the
> only baby the WG works on. Different tools for different problems.
>
> In short I think IPv6 should have a native, natural, minimal, composable
> way of doing packet steering. This document is a good starting point. Let’s
> do it.
>
> —John
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 May 2020 09:09:11 +1000

Hi Jingrong,

> The IPv6 ULA is just a candidate element of the mechanism, instead of the

So the ULA address space inherently has a lot of the security properties of
the measures described in RFC8754, and that is by design.

If packets with ULA DAs leak because of a default route pointing out of the
local network, they'll be dropped by the first default free Internet router
they encounter.

By default, the ULA prefix of fc00::/7 and longer are not supposed to be
advertised to or accepted by external networks, unless there is an
agreement to route their ULA /48s between them, so interdomain routing of
ULAs is not the default, unlike IPv6 public GUA addresses.

Packets that leak with a ULA source addresses will be caught by an upstream
BCP38 source address filter.

ACLs should be used with ULA address spaces, however they only add to the
existing inherent ULA security properties. ACLs used with global IPv6
addresses would be the only security measure, making the ACL
mechanism/enforcement a single point of failure.

A lot of things have to go wrong for a packet that leaks with a ULA source
or destination address to cause a negative effect on an external node. If
that is still a concern, AH could be used so the packet fails
authentication when it arrives at the external node, or ESP could be used
so the payload looks like a bunch of random bits.

The intended forwarding and reachability domain for a network 's ULA prefix
is the local network only, in contrast to global IPv6 GUA addresses where
the forwarding and reachability domain is anywhere on the Internet.

So the ULA address space is a natural fit for traffic that is intended to
be constrained to the local network, such as this case for the local
network imposed tunnelling encapsulation to add information via the CRH.

Regards,
Mark.

>
>
> Thanks
>
> Jingrong
>
>
>
> *From:* Mark Smith [mailto:[email-masked]]
> *Sent:* Saturday, May 16, 2020 11:05 AM
> *To:* Xiejingrong (Jingrong) <[email-masked]>
> *Cc:* Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> *Subject:* Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 May 2020 11:37:37 +1200

Another thing is that ULAs work. People seem to be scared of them for some reason, but they just work straight out of the box. As many /48s as you want, for free, in parallel with whatever you got from IANA.

Choosing ULAs for the ANIMA autonomic control plane was a no-brainer, for all the reasons Mark gives, plus the benefit that the prefix itself can be auto-generated if wanted. Since we will surely need more and more automated configuration with these increasingly complex technologies, I think that a prefix capable of automatic generation is a strategic choice. Why would we want to configure 48 bit numbers by hand?

Regards,
   Brian

On 17-May-20 11:09, Mark Smith wrote:
> Hi Jingrong,
> 
> On Sat, 16 May 2020, 18:18 Xiejingrong (Jingrong), <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Mark____
> 
>     Thanks for the introduction of RFC4193.____
> 
>     The RFC8754 boundary security mechanism is still unique IMO. ____
> 
> So the ULA address space inherently has a lot of the security properties of the measures described in RFC8754, and that is by design.
> 
> If packets with ULA DAs leak because of a default route pointing out of the local network, they'll be dropped by the first default free Internet router they encounter.
> 
> By default, the ULA prefix of fc00::/7 and longer are not supposed to be advertised to or accepted by external networks, unless there is an agreement to route their ULA /48s between them, so interdomain routing of ULAs is not the default, unlike IPv6 public GUA addresses.
> 
> Packets that leak with a ULA source addresses will be caught by an upstream BCP38 source address filter.
> 
> ACLs should be used with ULA address spaces, however they only add to the existing inherent ULA security properties. ACLs used with global IPv6 addresses would be the only security measure, making the ACL mechanism/enforcement a single point of failure.
> 
> A lot of things have to go wrong for a packet that leaks with a ULA source or destination address to cause a negative effect on an external node. If that is still a concern, AH could be used so the packet fails authentication when it arrives at the external node, or ESP could be used so the payload looks like a bunch of random bits.
> 
> The intended forwarding and reachability domain for a network 's ULA prefix is the local network only, in contrast to global IPv6 GUA addresses where the forwarding and reachability domain is anywhere on the Internet.
> 
> So the ULA address space is a natural fit for traffic that is intended to be constrained to the local network, such as this case for the local network imposed tunnelling encapsulation to add information via the CRH.
> 
> Regards,
> Mark.
> 
>     ____
> 
>     __ __
> 
>     Thanks____
> 
>     Jingrong____
> 
>     __ __
> 
>     *From:*Mark Smith [mailto:[email-masked] <mailto:[email-masked]>]
>     *To:* Xiejingrong (Jingrong) <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Bob Hinden <[email-masked] <mailto:[email-masked]>>; IPv6 List <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"____
> 
>     __ __
> 
>     __ __
> 
>     On Sat, 16 May 2020, 12:43 Xiejingrong (Jingrong), <[email-masked] <mailto:[email-masked]>> wrote:____
> 
>         Hi WG,
>         https://tools.ietf.org/html/rfc8754____
> 
>     __ __
> 
>     RFC4193, a limited domain and local network only address space.____
> 
>     __ __
> 
>     See also slide 50.____
> 
>     __ __
> 
>     "Getting IPv6 Private Addressing Right"____
> 
>     https://www.ausnog.net/sites/default/files/ausnog-2019/presentations/2.3_Mark_Smith_AusNOG2019.pdf____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
> 
> 
>         BTW:
>         From: ipv6 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bob Hinden
>         To: IPv6 List <[email-masked] <mailto:[email-masked]>>
>         Cc: Bob Hinden <[email-masked] <mailto:[email-masked]>>
>         -------------------------------------------------------------------- ____
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 May 2020 19:47:39 -0400

Brian E Carpenter <[email-masked]> wrote:
    > Another thing is that ULAs work. People seem to be scared of them for
    > some reason, but they just work straight out of the box. As many /48s
    > as you want, for free, in parallel with whatever you got from IANA.

Given my very limited understanding of how CRH will be used, and the really
long thread about leaking that I 99% ignored, I would be happier if we also
allowed for ULA-C to be defined and made operational (through RIRs or IANA or
a service like sixxs used to offer for registering ULA-R).
{Maybe I'm repeating that thread}

This WG has not been that interested in persuing ULA-C, but I'll review CRH
again to ask if it wouldn't benefit.

Being able to track a leak back to it's origin is pretty important
operationally.  {RFC1918 has been used by stupid ISPs at times, and it has
caused disasters when they leak... I'm seeing ULAs used by ISPs as
router-IDs, which is even dumber}

    > Choosing ULAs for the ANIMA autonomic control plane was a no-brainer,
    > for all the reasons Mark gives, plus the benefit that the prefix itself
    > can be auto-generated if wanted. Since we will surely need more and
    > more automated configuration with these increasingly complex
    > technologies, I think that a prefix capable of automatic generation is
    > a strategic choice. Why would we want to configure 48 bit numbers by
    > hand?

+1

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ron Bonica <[email-masked]>
Date: Sun, 17 May 2020 00:04:10 +0000

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]> 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)"

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

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

________________________________
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)"

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

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: Greg Mirsky <[email-masked]>
Date: Sat, 16 May 2020 17:46:36 -0700

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,
>
>
>
> The question may be moot. I don’t foresee any CRH OAM work. PING and
> TRACEROUTE “just work”.
>
>
>
>                                                          Ron
>
>
>
>
>
>
>
> *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]>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Darren,
>
> [email-masked] <40cisco.com@dmarc..ietf.org>> wrote:
>
> Hi Bob and Ole.
>
>
>
> [email-masked] <[email-masked]>>
> <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: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sun, 17 May 2020 03:26:38 +0000

Hi Andrew.  You say...

I think you are confused, but that’s OK, it’s easy to explain.
SPRING defined segment routing, the terminology, usecases, problem statement, and protocol extensions.
6man defined the routing header.
See section 1 of https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-00 where this context was given when 6man adopted the document.

RPL appears similar, see section 1.

https://tools.ietf.org/html/draft-ietf-6man-rpl-option-00

I hope this helps.

  Darren

________________________________
From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, May 16, 2020 10:44 AM
To: Darren Dukes (ddukes); Bob Hinden; IPv6 List
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Darren…

Thanks

Andrew

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

Hi Bob and Ole.

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)"

Regards,
Bob and Ole

---

From: Andrew Alston <[email-masked]>
Date: Sun, 17 May 2020 06:26:21 +0000

Hi Darren,

Nah – wasn’t confused after all – you confirmed what I thought.

Last I checked – CRH was a routing header – and as stated many times – is a building block – upon which other things can be built.  As was stated in the interim meeting by Sander – things that utilize it may require architecture documents.  That doesn’t mean those individual architectures for the various things you can do with this will sit in 6man.  Last I checked – we never stated in any way shape or form that as people use the CRH for its various applications – that any further work done would have to sit in 6man. We did say – that this si a building block – and a routing header – and hence, belongs very much in 6man.

Let me try and use some analogies to paint you a picture you may understand – sometimes is easier that way.

In about 7000 BC someone invented this thing called the Brick.  About 9000 years later – someone came up with the architectural plans for the building at 170 West Tasman Drive.  In between – architectural plans use cases for this wondering thing called the Brick – were drawn up for some pretty spectacular things -  you know, like, the Acropolis, the Taj Mahal, the Empire State building, the Palace of Versailles – the list goes on.  I’m sure someone even wrote some use cases documents as to why they wanted those buildings, and I’d hope there was a business case behind building 170 West Tasman Drive, but – long before any of that – there was the simple, easy to use, brick – the building block.

I hope this makes sense to you – I realize that some of these concepts can sometimes be a little confusing and daunting when someone is used to dealing with things that have a single purpose designed by one group of people and have been taught that that group of people are the only ones that are capable of drawing up use cases and having ideas.  It’s similar to what I see in so many areas – where people are told to constrain their ideas to that which created by others, rather than taking the building blocks and closing their eyes and letting their imagination guide them.

See – there is a strong case for creating building blocks – so that people can well – build on them – with the freedom to do so as the innovative ideas come.  And that – is what this is – a building block – rather than a dictation of what the innovation of tomorrow should look like.

Thanks

Andrew

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Sunday, 17 May 2020 at 06:26
To: Andrew Alston <[email-masked]>
Cc: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Andrew.  You say...

I think you are confused, but that’s OK, it’s easy to explain.
SPRING defined segment routing, the terminology, usecases, problem statement, and protocol extensions.
6man defined the routing header.
See section 1 of https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-00<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-00> where this context was given when 6man adopted the document.

https://tools.ietf.org/html/draft-ietf-6man-rpl-option-00<https://tools.ietf.org/html/draft-ietf-6man-rpl-option-00>

I hope this helps.

  Darren

Darren…

https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26>

Thanks

Andrew

Hi Bob and Ole.

Thanks
  Darren

Regards,
Bob and Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 May 2020 09:00:45 +0000

Hello Darren

Since you mentioned RPL, I felt invited. We’ve had the same problems of RH insertion and saturating MTU as you guys, and been chewing them it for a very long time (like, ~ 15 years).

To make a long story short, we went through the hassles of inserting routing headers in the RPL domain, many implementations still do that (see for historic purpose https://tools.ietf.org/html/draft-hui-6man-rpl-headers-00).
We used a HbH header (0x63) that was supposed to ensure that an escaping packet would be discarded outside the domain. As you know, RFC8200 made it clear that we cannot count on it.
We also tried smaller tweaks like use the flow label in our own way inside the RPL domain (see https://datatracker.ietf.org/doc/draft-thubert-6man-flow-label-for-rpl/)

So yes we went to 6MAN a good number of times to get IPv6 optimizations in our very constrained environments and the response was usually negative, with the exception that you point out (the HbH header).

So where are we now?

The key thing is that we have provided a compressed routing header.  And by routing we do not mean the SRH but all thing sthat the router needs to look at. It’s RFC 8138, the 6LoWPAN Routing Header (6LoRH).  RFC 8138 compresses both the IP-in-IP and the source routing headers. It also compresses the HbH header we wanted to place in the flow labels, and that gives us multi-topology routing and micro-loop avoidance. That’s how we made IP-in-IP and the HbH acceptable on highly constrained MTUs.

The consequences of RFC 8138 are:
- inside a RPL domain, the RH is compressed statelessly based on common prefix with the previous hop
- the compressed packet is logically equivalent to the full IPv6 packet, but easier to handle when forwarding (e.g., no swapping games in the source routing header like RH0 does);
- outside the RPL domain, the compression format is not recognized and the packet is dropped as invalid so, to Stewart’s point and like for MPLS, there’s no escapees;
- as imposed/suggested/whatever by IPv6 we use IP in IP to protect the RH encapsulation, as it goes that improves the compression since the encapsulator (the RPL root for us) in the same domain shares a prefix with the SRH next hops. https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ details how we do all those things now, and the complexity of resulting spec says a lot.

You’ll note that 6LoRH is not linked to anything else 6LoWPAN, and could be made to apply in a domain that is not a RPL. Maybe part of defining something new should be to look at the existing art.

I hope this helps,

Pascal

From: ipv6 <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: dimanche 17 mai 2020 05:27
To: Andrew Alston <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Andrew.  You say...

I hope this helps.

  Darren

Darren…

Thanks

Andrew

Hi Bob and Ole.

Thanks
  Darren

Regards,
Bob and Ole

---

From: Wen Lin <[email-masked]>
Date: Tue, 19 May 2020 16:10:00 +0000

I support the adoption of this document.

It is simple, efficient,  and clearly defined.  It fits well with IPv6 paradigm.

Thanks,
Wen

On 5/15/20, 6:14 PM, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Bob and Ole

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Tue, 19 May 2020 23:51:20 +0000

Hi Pascal, thanks for that history and the context it sets.

I think this meshes well with the point I was trying to make in this thread - the domain specific expertise within ROLL triggered the building of these IPv6 extensions (HBH or RH) in 6man.

Of course you expand significantly past that…

Perhaps RFC8138 should be evaluated if it offers a more general purpose compressed source routing header vs CRH.

Darren

On May 18, 2020, at 5:00 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> wrote:

Hello Darren

So where are we now?

I hope this helps,

Pascal

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Darren Dukes (ddukes)
Sent: dimanche 17 mai 2020 05:27
To: Andrew Alston <[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)"

Hi Andrew.  You say...

I hope this helps.

  Darren

Darren…

Thanks

Andrew

Hi Bob and Ole.

Thanks
  Darren

Regards,
Bob and Ole

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 May 2020 12:28:35 +0000

Hi Bob & Ole,

I am opposed to the WG adopting this draft and I am sharing the reasons for the same objectively based on the guidelines in https://tools.ietf.org/html/rfc7221#section-2.2

Reference: https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22

*  Is there a charter milestone that explicitly calls for such a document?

KT> No.

*  Is the topic of the I-D within scope for the working group?

KT> No. This is 6man WG; not anymore IPNG or IPV6. The WG charter clearly says "It is not chartered to develop major changes or additions to the IPv6 specifications."

KT> A new Source Routing technology (as claimed by the authors) is in the domain of expertise of the Routing Area (as the name suggests). Note that the authors have clarified that the target is not IPv6 Internet but some (yet undefined) "limited domain" in an operator's private network. The WG has not been made aware of any discussion with Routing ADs on how this solution work (and not just this RH document) is going to proceed.

KT> Contrary to the claims by the authors, I would assert that this work simply brings a new IPv6 data-plane proposal for the Spring WG's Segment Routing solution. It borrows (without any attribution) a lot of Spring architectural constructs (e.g. Prefix and Adjacency SID). So, the current document still leans on Spring work even if the authors have removed references from the previous versions. Therefore, it is not a new Source Routing solution but a new IPv6 data-plane that offers a reduced Segment Routing functionality.

*  Is the purpose of the draft sufficiently clear?

KT> The purpose is not clear since the new IPv6 Source Routing solution claimed by the authors is not documented in the draft in terms of its applicability, use-cases and requirements. The header format and simplistic forwarding rules documented do not describe the architectural concepts of what a SID is, it's semantics, "forwarding methods", "method specific parameters", etc.

KT> As observed in the WG discussion, members seem to be guessing or speculating on what would be a good size for the SIDs and how they would be used/deployed. This is clear proof that the solution is not described clearly.

*  Does the document provide an acceptable platform for continued effort by the working group?

KT> It would be odd if the 6man WG is going to own up the work of documenting the architecture - I request to chairs to clarify their position on this. This work will result in a lot of extensions being introduced for multiple protocols in the Routing Area. Unlike Spring WG, there is no WG to define the requirements and set the framework or context for those other protocol work. This would result in largely uncoordinated and ill-defined work across multiple WGs in the IETF.

*  What are the process or technical objections to adoption of the draft?

KT> Process objections are covered above - not in charter, not well specified. Technical objections have been shared on the list on multiple threads before the WG adoption started. Fundamentally, the documentation of the proposal is inadequate for a proper technical review.

*  Is the draft likely to be completed in a timely manner?

KT> Unable to determine at this juncture. The draft seems highly contentious at this point.

*  Does the intended status of the document seem reasonable to the working group?

KT> At best, this seems to be experimental work that is exploratory in nature and not fully defined as expected for standards development for a multi-vendor development and production deployment.

*  If not already in scope, is a simple modification to the charter feasible and warranted?

KT> Changing scope would require change of name of the WG. Instead if this is new Source Routing work and different from Spring WG charter then perhaps a BOF followed by a new WG in Routing Area would be more appropriate.

*  Does the draft carry known intellectual property rights issues?

KT> There is one IPR from a vendor/co-author.

*  Is there strong working group support for working on the draft?

KT> This would be something that is to be determined at the end of the ongoing poll.

In my conclusion, this work is intended to introduce a new data-plane for Spring architecture on IPv6 and we need to go back to the technical discussion on these options in Spring WG before this document is adopted by 6man.

If this work is unrelated to Spring (as claimed by the authors) and introducing a new Source Routing solution in the IETF, then the proponents of this solution need to follow the due IETF process by documenting its architecture, applicability, use-cases and requirements for other protocols to realize this new solution. That would help determine where the work should reside and how it should get done (perhaps a BoF?).

The motivation for following the IETF procedure like when introducing a new solution is to ensure a proper technical review from diverse expertise from whatever areas and WGs required and to provide a coordinated development of the solution across IETF (this is what was done by Spring and the other WGs that required new RHs).  Otherwise there is a chance for this adoption attempt being seen as a set of individuals getting a shortcut path for publishing their proposal as standards.

Thanks,

Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 16 May 2020 03:44
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

to work on this.

Regards,

Bob and Ole

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 21 May 2020 13:56:03 +0000

Hello Spring WG,

You might be very interested in this ongoing WG adoption poll for the CRH proposal (what was previously introduced in Spring as part of the SRm6 proposal).

The authors are now claiming that theirs is a new IPv6 source routing proposal that is unrelated to work/charter of Spring WG and not Segment Routing [1] & [2].

The authors and 6man chairs seem to agree that this is not related to Spring [3].

However, following the conversations in 6man, it seems clear to me that this is indeed a new IPv6 data-plane proposal that builds on Spring work [RFC8402] but avoids attribution to it to give an illusion of it being a new standalone IPv6 Source Routing solution.

If you were looking for a document that describes the architecture, applicability, use-cases or requirements for this "new solution", well there isn't anything other than the CRH draft itself [4] (the new version does not talk about SRm6 anymore).

Just thought of letting know ... 

Thanks,
Ketan 

[1] https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/
[2] https://mailarchive.ietf.org/arch/msg/ipv6/acyQ6VoObjnUVk6oOz7RoVLNey8/
[3] https://mailarchive.ietf.org/arch/msg/ipv6/BMoJM1NfneU5o0KRKUCkCj96g8c/
[4] https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22 

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: 16 May 2020 03:44
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 21 May 2020 16:02:26 +0000

Hi Xing,

Is there any documentation you could share, e.g., on the trial of "CRH can co-exist with SRv6 in the backbone"?

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Xing Li <[email-masked]>
Date: Friday, May 15, 2020 at 10:48 PM
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,

xing
CERNET Center

Bob Hinden 写道:

Regards,
Bob and Ole

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 21 May 2020 22:29:28 +0530

Yours,
Naveen.

---

From: John Scudder <[email-masked]>
Date: Thu, 21 May 2020 20:36:55 +0000

Hi Ketan,

On May 21, 2020, at 8:28 AM, Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>> wrote:
...
*  Is the purpose of the draft sufficiently clear?

KT> The purpose is not clear since the new IPv6 Source Routing solution claimed by the authors is not documented in the draft in terms of its applicability, use-cases and requirements.

[and this text is repeated in your conclusion]

Ron did respond to this complaint in a reply to Darren Dukes on May 14 (see https://mailarchive.ietf.org/arch/msg/ipv6/OG3XDVKUYVYaLP3F2T6E1NK3uOQ/), offering some draft text and asking

"If I were to add the following sections to the draft, would they address your concern. If not, what else is needed? Please be specific.”

If you haven’t reviewed his proposed text, please do. If you have, and if it doesn’t address your concerns, it seems you should offer something more specific than “not documented in the draft”.

Regards,

—John

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 09:32:38 +1200

Hi,
On 22-May-20 00:28, Ketan Talaulikar (ketant) wrote:
...
> **  Is there a charter milestone that explicitly calls for such a document?   ** *** 
> KT> No.

That is not an exclusionary argument. If it *was* a milestone, that would be supportive. But the absence of a milestone is like any other absence of evidence.
 
> **  Is the topic of the I-D within scope for the working group?   ** ***  
> 
> KT> No. This is 6man WG; not anymore IPNG or IPV6. The WG charter clearly says “It is not chartered to develop major changes or additions to the IPv6 specifications.” 

That's a judgment call. IMHO a new routing header type is not "major". It's maintenance.
 
> KT> A new Source Routing technology (as claimed by the authors) is in the domain of expertise of the Routing Area (as the name suggests). 

Nobody can deny that, but a new RH type is in 6MAN's competence, as proved by the SRH case. I said the other day that advice from the Routing ADs is needed, and that remains true. But again, this is not an exclusionary argument.

> KT> Contrary to the claims by the authors, I would assert that this work simply brings a new IPv6 data_-_plane proposal for the Spring WG’s Segment Routing solution. 

Again, that's why this WG needs advice from the Routing ADs. But if it builds on SPRING work, so what? We build on each other's work constantly in the IETF, and that's a good thing. SPRING has no monopoly, and SRH has no monopoly.
 
> **  Is the purpose of the draft sufficiently clear?   ** ***
> 
> KT> The purpose is not clear since the new IPv6 Source Routing solution claimed by the authors is not documented in the draft in terms of its applicability, use-cases and requirements. The header format and simplistic forwarding rules documented do not describe the architectural concepts of what a SID is, it’s semantics, “forwarding methods”, “method specific parameters”, etc. 

That's been discussed already with some new text proposed. But of course after the draft is adopted, we (the WG) own the the draft and can extend it as needed.

> KT> As observed in the WG discussion, members seem to be guessing or speculating on what would be a good size for the SIDs and how they would be used/deployed. This is clear proof that the solution…

That's of no importance at the adoption stage. The WG can improve the draft as needed. 
> **  Does the document provide an acceptable platform for continued effort by the working group?   ** ***

6MAN's job is limited to specifying the routing header. After that, it's up to the Routing Area to do the rest.

Your remaining questions are all irrelevant at the adoption stage. We are nowhere near talking about WG last call or submission to the IESG.

Regards
    Brian Carpenter

---

From: Xing Li <[email-masked]>
Date: Fri, 22 May 2020 10:08:39 +0800

Hi, Zafar,

> can co-exist with SRv6 in the backbone"?
Currently there are only internal documents. If people are interested, 
we may submit an ID in v6ops  ^_^.

I can share some information here.

CERNET2 is an IPv6-only backbone,  the routing for internal 
infrastructure is via IS-IS and the customer  and external routes are 
via BGP. The CERNET2  backbone has four vendors.

We have done 3 type of testing.

(1) SRv6 enabled points are using Linux open source  (static routing).
(2) SRv6 enabled points are using one vendor's equipment (static routing).
(3) CRH enabled points are using another vendor's implementation (IS-IS).

The SRv6 and SRH testing  pathes are  cross different vendors and 
running  concurrently,

We are in the process to conduct more testings.

Regards,

xing

>  
>
> Thanks
>
>  
>
> Regards … Zafar
>
>  
>
> *From: *ipv6 <[email-masked]> on behalf of Xing Li 
> <[email-masked]>
> *Date: *Friday, May 15, 2020 at 10:48 PM
> *To: *Bob Hinden <[email-masked]>
> *Cc: *IPv6 List <[email-masked]>
>     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.
>
>      
>
>     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
>
>      
>
>      
>
>      
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 02:52:46 +0000

Hi John,

Please check inline below.

From: John Scudder <[email-masked]>
Sent: 22 May 2020 02:07
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Ketan,

If you haven’t reviewed his proposed text, please do.
[KT] I have reviewed it and it is insufficient. One only needs to follow the discussions during the adoption call to understand this.

If you have, and if it doesn’t address your concerns, it seems you should offer something more specific than “not documented in the draft”.
[KT] Are you asking me to guess what the proposal is? It does seem however that you are aware of the intricate details of the proposal. You are also an expert on routing with experience in definition of the architecture of one Source Routing solution (Spring). As such may be you could help the authors explain the proposal – a good reference might be the following:

https://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-00 that later became RFC8402
https://tools.ietf.org/html/draft-previdi-spring-problem-statement-00 that later became RFC7855
https://tools.ietf.org/html/draft-martin-spring-segment-routing-ipv6-use-cases-00 that later became RFC8354

In the spirit of IETF, I request the authors to do the work so that the proposal can be reviewed by the community in proper context.

Judging by Ron’s email responses he does seem to have a lot more context that what’s in the draft - otherwise he would be making things up as we go. If it is the latter case, he should perhaps state so – at least then the WG knows this is an exploratory/experimental thing.

So why the rush and the shortcuts – why not the proper documentation before asking for WG adoption?

Thanks,
Ketan

Regards,

—John

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 03:09:41 +0000

Hi Brian,

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Sent: 22 May 2020 03:03
To: Ketan Talaulikar (ketant) <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

...

[KT] I never said this statement/argument was exclusionary. Neither does RFC7221 that I took this from.

[KT] I was talking about the introduction of a new IPv6 Source Routing solution not just the CRH. If some other WG had defined this new Source Routing solution and 6man were doing just the CRH specification then it would be well within the scope of 6man and following precedence of how other RH work was done in the past. But we don’t have the solution as a reference, do we? So it would follow that 6man is taking the lead and defining a new IPv6 Source Routing solution which cannot be seen as maintenance work.

> KT> A new Source Routing technology (as claimed by the authors) is in the domain of expertise of the Routing Area (as the name suggests).

Nobody can deny that, but a new RH type is in 6MAN's competence, as proved by the SRH case.

[KT] And I am not arguing otherwise. My point is where is the solution description that 6man can refer to when designing the new RH?

I said the other day that advice from the Routing ADs is needed, and that remains true. But again, this is not an exclusionary argument.

[KT] Indeed, you had made this point earlier and it is very valid and pertinent. I would also look for response on this from the chairs and the ADs.

> KT> Contrary to the claims by the authors, I would assert that this work simply brings a new IPv6 data_-_plane proposal for the Spring WG’s Segment Routing solution.

Again, that's why this WG needs advice from the Routing ADs.

[KT] Indeed – we are not aware of what was done or the agreement for proceeding with this work.

But if it builds on SPRING work, so what? We build on each other's work constantly in the IETF, and that's a good thing. SPRING has no monopoly, and SRH has no monopoly.

[KT] Definitely. We constantly build on existing work. SRm6 was trying to do that. But the current document does not provide any attribution to Spring architecture and body or work. The authors in fact deny this has anything to do with Segment Routing. It would seem like the authors are not giving the due to years of work done in Spring. And that makes one wonder why so because the previous versions of this document did have such references to Spring work that was purposefully removed by the authors.

[KT] You see this is nothing but the new IPv6 Source Routing architecture being discussed and being developed – not just the CRH design. So is 6man chartered to develop new IPv6 Source Routing solution? That is my question.

[KT] How can a work be considered for adoption when its scope, purpose and usage is not known. This kind of exploratory work is suitable to start a BOF and not new work in 6man that is chartered with maintenance. Not to mention the wide impact this work would result on other WGs in routing area.

[KT] And how does 6man do it’s job without having a specification that describes the architecture, use-case, applicability, … we come back to it.

Thanks,

Ketan

Regards

    Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2020 15:14:50 +1200

On 22-May-20 14:52, Ketan Talaulikar (ketant) wrote:
...
> */So why the rush and the shortcuts – why not the proper documentation before asking for WG adoption?/*

Because it's only WG adoption. There is no requirement for supporting documentation at this stage in the IETF process.

It's not long ago that I recall an AD saying to a WG that formal requirements and use case documents are usually a waste of time anyway. Maybe the IESG has changed its mind about that recently? But in any case, it's a Routing Area decision whether CRH is a good idea; 6MAN is not the place for that part of the discussion.

   Brian

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 22 May 2020 03:38:18 +0000

Hi Brian,

I am copying Routing ADs to get their perspective and pointing them to my original email objections to this adoption call https://mailarchive.ietf.org/arch/msg/ipv6/-ikF-zt_muGxz4exwjx0ZTWZpHY/

Please check inline.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Sent: 22 May 2020 08:45
To: Ketan Talaulikar (ketant) <[email-masked]>; John Scudder <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

...

It's not long ago that I recall an AD saying to a WG that formal requirements and use case documents are usually a waste of time anyway.

[KT] I could agree if it is a standalone piece of work and something that is not a new solution/architecture that is going to result in several 10s of drafts/work in other WGs (this is not a guess – the authors have proposed a few such drafts already in routing area WGs that perhaps people in 6man are not aware of).

Maybe the IESG has changed its mind about that recently? But in any case, it's a Routing Area decision whether CRH is a good idea;

[KT] Agree. And has this question been asked of the Routing Area? If not, is it ok to adopt CRH work in 6man without their decision? If yes, what is their decision? And what were the documents/details that they referred to arrive at such a decision (I ask since the CRH draft seems short on details from a solution perspective to me).

Thanks,

Ketan

6MAN is not the place for that part of the discussion.

   Brian

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 22 May 2020 11:07:21 +0000

Bob, Ole,

I do not support the adoption of this document. Reasons below:

1.- 6man is an IPv6 maintenance group. This proposal is defining a new routing header with no sort of document, input or requirement from the Routing Area.

While certainly this group does not need any sort of permission from routing, uncoordinated protocol development is harmful. This point has already been made by others.

2.- This is not a standalone document. Despite from the document stating that the CRH-FIB will be populated by means of CLI, I think everyone in this group would oppose to that; configuring all 2^16 labels manually in all routers is an operational burden...

We will need control plane extensions such as draft-bonica-lsr-crh-isis-extensions, but again, we do not have the requirements or use-cases from Routing Area as to know what we need to support/build.

3.- The authors have not provided a document discussing applicability,  use-cases or requirements. This approach of building a solution without understanding the problem is in my opinion utterly wrong.

This is already causing confusion as for example in the 16b vs 32b discussion.

Also, from BCP22:

"   Standards track documents must include a description of the protocol.

   This description must address the protocol's purpose, intended

   functions, services it provides, and, the arena, circumstances, or

   any special considerations of the protocol's use.

   The authors of a protocol specification will have a great deal of

   knowledge as to the reason for the protocol.  However, the reader is

   more likely to have general networking knowledge and experience,

   rather than expertise in a particular protocol.  An explanation of

   it's purpose and use will give the reader a reference point for

   understanding the protocol, and where it fits in the Internet.  The

   STD 54/RFC 2328 was recommended to the STDGUIDE working group as

   providing a good example of this in its "Protocol Overview" section.

   The protocol's general description must also provide information on

   the relationship between the different parties to the protocol. This

   can be done by showing typical packet sequences.

   This also applies to the algorithms used by a protocol.  A detailed

   description of the algorithms or citation of readily available

   references that give such a description is necessary."

In summary, we are polling whether to adopt a document that is ignoring BCPs, doing uncoordinated development within the IETF areas, and with a bunch of unanswered technical questions on the mailer.

Additionally, I believe this proposal has issues with scalability, and requires additional ASIC resources as recognized by the authors [1].

Thanks,

Pablo.

[1].- https://mailarchive.ietf.org/arch/msg/spring/aLhIQ2btTfNkJ4ghruuXbm3zY30/

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: sábado, 16 de mayo de 2020 0:14
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

to work on this.

Regards,

Bob and Ole

---

From: Andrew Alston <[email-masked]>
Date: Fri, 22 May 2020 12:42:43 +0000

Let me highlight the problem I have with what you are saying about the BCP.... Please note the italics.

Last I checked - an extensión header is not a protocol - it is a building block upon which protocols are built.  What would define a new protocol - is if we were coming out with something that fundamentally stepped out bounds of RFC8200 - or overloaded the address space in such a way that an address was no longer just an identifier - or inserted and removed headers on the wire in a way that another protocol wouldn't allow - or a host of other things - except - I don't see any of that happening here - have seen plenty of it in the context of other proposed work - but - not here.

Thanks

Andrew

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 22 May 2020 12:41:39 +0000

[Removing my internet area director hat for this post]

While I understand that the document will evolve, I cannot "throw my voice" yet for WG adoption because:
1) the justification for this I-D is a mere 9 lines in section 1 and there is requirement neither from other IETF WG nor from other SDOs;
2) the management and security considerations are really weak in the current draft [1].

Personally (and still no hat), I would prefer to see the above points fixed before adopting the document.

Regards

-éric

[1] I am sure that Ron Bonica and his co-authors will improve these sections.

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Saturday, 16 May 2020 at 00:14
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Regards,
    Bob and Ole

---

From: John Scudder <[email-masked]>
Date: Fri, 22 May 2020 19:05:14 +0000

Ketan,

> On May 21, 2020, at 11:10 PM, Ketan Talaulikar (ketant) <ketant=[email-masked]> wrote:
> 

I’m not aware of the authors having denied that CRH is factored out from their earlier work on SRm6 (it would be silly to do that since SRm6 cites CRH normatively), nor that SRm6 is in the SR space (it’s right there in the name). On the contrary, my recollection is that this has been explicitly acknowledged during one or more 6man meetings. Although I don’t speak for them, I have confidence the authors would be willing to update the acks as appropriate (for that matter, if it becomes a WG document it’s not solely the authors’ choice to make). 

I’m not an author so I won’t presume to answer for them regarding references that were removed, but generally when I’m writing a document I provide the references needed to support the body text, neither more nor less; if the refactoring of the work makes it possible to understand without reference to those documents, then they shouldn’t be in the references. The SRm6 draft does indeed cite the CRH draft, and this is as it should be — upper layers cite lower layers, not the other way around. BGP cites TCP, but TCP doesn’t cite BGP, etc. In fact, idnits will complain if a document is cited but never mentioned in the body text, this is so much of a best practice it’s baked into our tool chain.

Regarding “previous versions of this document did have such references to Spring work”, I looked back in the document history and see that 00 through 04 cite draft-ietf-6man-segment-routing-header, because those versions list all defined routing headers in the introduction, and that’s one of them. Later versions shorten the introduction and thus the reference isn’t needed. It seems like overreach to try to ascribe some kind of nefarious purpose to this simple edit. Various other RH were also cited by 00 through 04, and then the citations removed (e.g. to RFC 5095), for the same reason.

Your insinuation that there’s an attempt by the authors to engage in some kind of plagiaristic behavior is both hurtful and disruptive. If you can support your insinuations with facts, please present them if you feel it advances the dialogue, otherwise please stop.

Thanks,

—John

---

From: Parag Kaneriya <[email-masked]>
Date: Sat, 23 May 2020 06:32:59 +0000

I Support the adoption of CRH draft by 6man WG

The proposed solution is simple and compact. It has applicability beyond the segment routing. 

Regards
Parag Kaneriya

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Friday, May 15, 2020 6:14 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

 https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!T325GkDnXYNOrC-7UIHjusKS8pk85ToUEFnWK9GQn280Tjwvj_oXZ7qappTs5OR4$

Regards,
Bob and Ole

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!T325GkDnXYNOrC-7UIHjusKS8pk85ToUEFnWK9GQn280Tjwvj_oXZ7qapictFX1a$
--------------------------------------------------------------------

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sun, 24 May 2020 05:32:15 +0000

Hi John,

I believe that you have misrepresented my intentions and, in your email below, have put words in my mouth that are contrary to the points that I was trying to make. I find this very unfortunate.

Let me clarify that none of my arguments during this adoption call have been related to the use of CRH in the scope of SRm6 solution. Since the WG adoption is based on the premise that it is for use-cases other than Spring / Segment Routing (please correct me if that is not so).

So I am looking for documentation and explanation for the IPv6 Source Routing solution with CRH that is not-related the Segment Routing (i.e. Spring architecture) from the authors.

That was the context of my entire discussion thread with Brian : https://mailarchive.ietf.org/arch/msg/ipv6/DsRMOzMlHNoGNOHqFbq8CLdWyjQ/ 

There are these forwarding methods, method specific parameters, the semantics of the SID (e.g. its scope), etc. that are not well defined in the document. In my mind, these can be straightaway mapped to constructs in Spring Architecture with proper references. The authors could just use those references to explain them or in the case that they mean something different then we need to see those specified fully along with how they are going to be used.

Thanks,
Ketan

-----Original Message-----
From: John Scudder <jgs=[email-masked]> 
Sent: 23 May 2020 00:35
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Ketan,

Thanks,

—John

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Sun, 24 May 2020 05:45:21 +0000

Hi Eric,

Agree, I also believe that the authors will improve these two parts.

When I read the introduction, I see that the requirements come from the overhead introduced of header, I assume that this is a problem of SRv6, and we also can learn it from the previous revision of this document.  If not from SRv6, it is better to specify the requirements.

Regarding the security part, the rules should be settled down, two many discussions of it, it seems that it is not clear right now. As a foundational building brick, security is really important. Jingrong’s input may help.

Best,
Cheng

李呈 Cheng Li
Mobile: +86-15116983550<tel:+86-15116983550>
Email: [email-masked]<mailto:[email-masked]>

From: Eric Vyncke (evyncke)<evyncke=[email-masked]<mailto:evyncke=[email-masked]>>
To: Bob Hinden<[email-masked]<mailto:[email-masked]>>;IPv6 List<[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
Time: 2020-05-22 21:44:43

Regards

-éric

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Saturday, 16 May 2020 at 00:14
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Regards,
    Bob and Ole

---

From: John Scudder <[email-masked]>
Date: Sun, 24 May 2020 16:22:34 +0000

Hi Ketan,

> On May 24, 2020, at 1:32 AM, Ketan Talaulikar (ketant) <ketant=[email-masked]> wrote:
> 

I take you at your word that you didn’t intend to call into question the authors’ integrity, thank you for clarifying that. I apologize for saying otherwise and thank you for taking care with your language going forward.

Regards,

—John

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:33:40 +0000

Cheng, Eric,

I would be glad to enhance these sections.

                                    Ron

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Chengli (Cheng Li)
Sent: Sunday, May 24, 2020 1:45 AM
To: Eric Vyncke (evyncke) <evyncke=[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Reply: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi Eric,

Best,
Cheng

李呈 Cheng Li

Regards

-éric

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Bob Hinden <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 16 May 2020 at 00:14
To: IPv6 List <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

     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!T3tgk4cj64JkWGd_84nCpchIqzpiED7yHjz2CDQxNqC_cWXkyyVTPgiIbMoIkXWd$>

    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!T3tgk4cj64JkWGd_84nCpchIqzpiED7yHjz2CDQxNqC_cWXkyyVTPgiIbCcfLfXK$>
--------------------------------------------------------------------

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 25 May 2020 18:48:55 +0800

Hi Chairs，

I’m not supporting the adoption. 

CRH draft intends to provide a compressed segment list for a source-routed
policy in IPv6 networks. In fact, SRv6 has been deployed by many operators
and the several simple ways to support compressed segment list have been
posted. For example, G-SID for Compression
[https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cmpr-01].

There is no need for defining a brand-new data plane (CRH) and the
associated new control plane.

I hope the WG consider the point during this adoption call.

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Bob Hinden
发送时间: 2020年5月16日 06:14
收件人: IPv6 List
抄送: Bob Hinden
主题: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Huzhibo <[email-masked]>
Date: Mon, 25 May 2020 14:09:25 +0000

Hi 6man, 
I do not support the adoption.

I don't know what is the requirement of the CRH. If CRH is used for steering SR-MPLS traffic over IP network, then RFC8663 has provided a really good solution. If CRH is aiming to address the overhead problem of SRv6, then it is recommended to define a mechanism under SRv6 framework, instead of inventing a huge set of control plane and data plane solutions. Also, we think G-SRv6 for compression has solved the overhead problem of SRv6.[1]

Best regards,
Zhibo Hu

[1]https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cmpr-01

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 25 May 2020 07:34:53 -0700

> [1]https://tools.ietf.org/html/draft-cl-spring-generalized-srv6-for-cmpr-01
Hi Zhibo,

With respect to that draft I have a few questions:

1. Doesn't G-SRv6 require a different routing type? I don't see how
G-SRv6 compatible could be compatible with RFC8754 which clearly
defines SIDs to be 128 bits.
2. Where would the work for G-SRv6 be done? Since work for SRH was
done in 6man, I tend to think G-SRv6 should also be in 6man.
3. Given that Flags, Tag, and TLVs are not critical and unused in the
common case, and with no TLVs Last Entry is unnecessary, can't these
fields simply be omitted in the compressed format to reduce overhead?

Tom

---

From: Huzhibo <[email-masked]>
Date: Tue, 26 May 2020 02:22:40 +0000

Hi Tom,

1. Doesn't G-SRv6 require a different routing type? I don't see how
G-SRv6 compatible could be compatible with RFC8754 which clearly
defines SIDs to be 128 bits.
[Zhibo] No, we don't require a different routing type, because we don't modify the format of SRH. Segment Left points to a 128 bit SID, and it may contain multiple G-SIDs. The appearance of G-SID is indicated by COC Flavor.

2. Where would the work for G-SRv6 be done? Since work for SRH was
done in 6man, I tend to think G-SRv6 should also be in 6man.
[Zhibo] Well, we think the architecture should be done in SPRING, because we need to define a new flavor of SIDs. Regarding the dataplane extension, it should be done in 6man.

[Zhibo] Of cause you can do that. Like CRH.  But we think Flags, Tag and TLVs are important since it provides flexibilities and programmability. We can use these fields to support many per-path of per-segment use cases. The value of them worth to get 32 bits.

When considering overhead reducing, it is VERY IMPORTANT to not sacrifice features. 

Reducing overhead by deleting features  seems not clever.

RH was defined in 6man. 

Thanks
Zhibo Hu

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, May 25, 2020 10:35 PM
To: Huzhibo <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: G-SRv6 (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

On Mon, May 25, 2020 at 7:09 AM Huzhibo <[email-masked]> wrote:
> I don't know what is the requirement of the CRH. If CRH is used for 
> steering SR-MPLS traffic over IP network, then RFC8663 has provided a 
> really good solution. If CRH is aiming to address the overhead problem 
> of SRv6, then it is recommended to define a mechanism under SRv6 
> framework, instead of inventing a huge set of control plane and data 
> plane solutions. Also, we think G-SRv6 for compression has solved the 
> overhead problem of SRv6.[1]
>
> Best regards,
> Zhibo Hu
>
Hi Zhibo,

1. Doesn't G-SRv6 require a different routing type? I don't see how
G-SRv6 compatible could be compatible with RFC8754 which clearly defines SIDs to be 128 bits.
2. Where would the work for G-SRv6 be done? Since work for SRH was done in 6man, I tend to think G-SRv6 should also be in 6man.
3. Given that Flags, Tag, and TLVs are not critical and unused in the common case, and with no TLVs Last Entry is unnecessary, can't these fields simply be omitted in the compressed format to reduce overhead?

Tom

---

From: stefano previdi <[email-masked]>
Date: Tue, 26 May 2020 15:40:03 +0200

Hi,

As author of the original SRH proposal, I follow with quite some interest the discussion around the need of compression of the segment list. At this stage I see at least 4 proposals, each of which brings some valid and interesting arguments:
. draft-bonica-6man-comp-rtg-hdr
. draft-decraene-spring-srv6-vlsid
. draft-lc-6man-generalized-srh
. draft-filsfils-spring-net-pgm-extension-srv6-usid
. (maybe there are more...)

Also, it looks to me that the ongoing discussion is focused only on one of the above. Are we going to re-spin the same debate for each of these or do we want the WG to conduct an analysis on all of them prior to select one (or maybe two) that would be candidate for adoption ? Certainly, I’d prefer the latter.

So, at this stage I don't support the adoption of draft-bonica-6man-comp-rtg-hdr and would prefer to see the WG to start an exhaustive analysis on all of the proposals.

Thanks.
s.

> On May 16, 2020, at 12:13 AM, Bob Hinden <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 26 May 2020 07:00:41 -0700

On Mon, May 25, 2020, 7:41 PM Huzhibo <[email-masked]> wrote:

> [Zhibo] No, we don't require a different routing type, because we don't
> modify the format of SRH. Segment Left points to a 128 bit SID, and it may
> contain multiple G-SIDs. The appearance of G-SID is indicated by COC Flavor.
>

Zhibo,

Thanks for the clarification, but it's still not clear to me exactly how
this works. Can you provide an example of what a SRH with G-SIDs looks
like? For instance, suppose there are one or two SIDs that can be
compressed to 16 bits-- this could be sent in an 8 byte CRH (4 bytes for
header and 4 bytes for two SIDs 2*2). Similarly, in a 16 byte CRH we can
encode 3, 4, 5, or 6 16 bit SIDs. Can you describe the analogous format and
header sizes for these scenarios in G-SRv6?

Also, how does segments left work if it only points to a 128 bit SID that
SID may itself be composed of multiple G-SIDs?

> [Zhibo] Well, we think the architecture should be done in SPRING, because
> we need to define a new flavor of SIDs. Regarding the dataplane extension,
> it should be done in 6man.
>
> [Zhibo] Of cause you can do that. Like CRH.  But we think Flags, Tag and
> TLVs are important since it provides flexibilities and programmability. We
> can use these fields to support many per-path of per-segment use cases. The
> value of them worth to get 32 bits.
>

It's not so much removing features as it is compressing out fields that are
not commonly used. I suspect the vast majority of SRH implementations send
zeros in these fields which make them a good candidate for compression.

Tom

> 2. Where would the work for G-SRv6 be done? Since work for SRH was done in
> 6man, I tend to think G-SRv6 should also be in 6man.
> common case, and with no TLVs Last Entry is unnecessary, can't these fields
> simply be omitted in the compressed format to reduce overhead?
>
> Tom
>
> > 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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 26 May 2020 14:26:53 +0000

if you look into the details RFC8663 from a data-plane operation is very similar to CRH. It uses a tag and derives a destination ipv6 address from it.
On top it if you look at the requirements which are discussed on the mailing list, the following is possible with RFC8663
 
It can steer the packet through a specific path. Implementations exists which do well beyond 8
No new VPN encapsulation is required
No new service chaining needed and various options possible.
Compliant to SPRING
Uses MPLS but it is used here as a lookup tag, not any different than the CRH proposal. In essence if you look at the details you can implement this with a complete v6 infrastructure and use the tag as a steering function. And uses 32 bit.
 
As such I don’t see why we need another encap to achieve something we already can do and is available in various implementations and is as efficient on the wire (looking at 32 bit, which is what people agree upon).

So I would vote against adoption.

On 16/05/2020, 00:14, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Bob and Ole

---

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

Stephano,

The drafts that you mention below can be categorized as follows:

- those that are entirely independent of the SRv6 architecture
- those thar are entirely dependent upon the SRv6 architecture

The CRH falls into the first category because it does not rely upon instructions being encoded in the IPv6 destination address. It assumes RFC 4291 address semantics.

All of the other drafts rely on some special interpretation of the IPv6 address. Either:

- The IPv6 address includes an instruction that describes how subsequent routing headers are to be processed
- The IPv6 address represents a path instead of an interface

For that reason, it makes sense to:

- progress the CRH draft, independently of SRv6
- let the SPRING WG evaluate the other drafts and send one of them to 6man.

                                                                                   Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of stefano previdi
Sent: Tuesday, May 26, 2020 9:40 AM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Hi,

Thanks.
s.

> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8I19DrKX$
>
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$
--------------------------------------------------------------------

---

From: Ahmed Abdelsalam <[email-masked]>
Date: Tue, 26 May 2020 19:30:18 +0200

Dear Bob and Ole, 

I don't support the adoption of “draft-bonica-6man-comp-rtg-hdr”. Please see below: 

The CRH has no native way to support SFC. Either you rely NSH or Destination options header. The former requires an SFC forwarder that needs to keep state for each service chain and the latter requires TLV processing. So both don’t scale 
An analysis/comparison between the different compression proposals (e.g., [1] [2] [3] [4]) is required before the adoption. 

Regards 
Ahmed 

[1] https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/ <https://datatracker.ietf.org/doc/draft-bonica-6man-comp-rtg-hdr/>
[2] https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/ <https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/>
[3] https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc/ <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc/>
[4] https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/ <https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/>

> On 16 May 2020, at 00:13, Bob Hinden <[email-masked]> wrote:
> 
> <Message signed with OpenPGP.asc>--------------------------------------------------------------------

---

From: stefano previdi <[email-masked]>
Date: Tue, 26 May 2020 20:02:50 +0200

Hi Ron,

> On May 26, 2020, at 6:25 PM, Ron Bonica <[email-masked]> wrote:
> 
> Stephano,

/ph/f   ;-)

> - those thar are entirely dependent upon the SRv6 architecture

I don’t disagree but, in my humble view and opinion, the 4 mentioned drafts aim to the same objective which is related to the size of the routing header (whatever flavor) containing the segment list.

I really wish that 6man will take time to review and process all these proposals before calling for adoption individual ones. Ideally, we shouldn’t standardize competing options or, at least, we should try to rationalize the spectrum of available solutions.

You argument about architectural linkage is very welcome to be discussed during this evaluation process (well, in fact it looks it’s already well discussed ;-)

Let’s keep the door open and let’s bring _all_ the options on the table before jumping to conclusions. An adoption today would give the message that one option is already the preferred one. This, I think, it’s not reflected in the state of the discussion.

For all these reasons I still don’t support the adoption of draft-bonica-6man-comp-rtg-hdr.

Thanks.
s.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 May 2020 12:02:24 -0700

Hi Stefano, et al.,
I agree that it is beneficial to have the discussion of the shorter SID in
SR over IPv6 (I'd like to differentiate the case from "classical" SRv6 as
defined in RFCs 8402 and 8754) one time rather than go over it again and
again. With that idea, we've started work on
draft-cheng-spring-shorter-srv6-sid-requirement
<https://datatracker.ietf.org/doc/draft-cheng-spring-shorter-srv6-sid-requirement/>
and
welcome comments and suggestions. If those interested in the topic agree
that the use case for a shorter SID in SR over IPv6 is practical, then
there may be not much use in discussing the above-mentioned draft and we
can proceed to the analysis of the proposed technical solutions. And to
your list, I'd like to add draft-mirsky-6man-unified-id-sr
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> that
has been presented to 6man (don't recall presenting it to SPRING). Since
we're going to have another series of virtual interim meetings, perhaps one
can be planned for the discussion of this topic - shorter SID in SR over
IPv6.

Regards,
Greg

On Tue, May 26, 2020 at 11:03 AM stefano previdi <[email-masked]>
wrote:

> I don’t disagree but, in my humble view and opinion, the 4 mentioned
> drafts aim to the same objective which is related to the size of the
> routing header (whatever flavor) containing the segment list.
>
> I really wish that 6man will take time to review and process all these
> proposals before calling for adoption individual ones. Ideally, we
> shouldn’t standardize competing options or, at least, we should try to
> rationalize the spectrum of available solutions.
>
> You argument about architectural linkage is very welcome to be discussed
> during this evaluation process (well, in fact it looks it’s already well
> discussed ;-)
>
> Let’s keep the door open and let’s bring _all_ the options on the table
> before jumping to conclusions. An adoption today would give the message
> that one option is already the preferred one. This, I think, it’s not
> reflected in the state of the discussion.
>
> > The CRH falls into the first category because it does not rely upon
> instructions being encoded in the IPv6 destination address. It assumes RFC
> 4291 address semantics.
> >
> > As author of the original SRH proposal, I follow with quite some
> interest the discussion around the need of compression of the segment list.
> At this stage I see at least 4 proposals, each of which brings some valid
> and interesting arguments:
> > Also, it looks to me that the ongoing discussion is focused only on one
> of the above. Are we going to re-spin the same debate for each of these or
> do we want the WG to conduct an analysis on all of them prior to select one
> (or maybe two) that would be candidate for adoption ? Certainly, I’d prefer
> the latter.
> >
> > So, at this stage I don't support the adoption of
> draft-bonica-6man-comp-rtg-hdr and would prefer to see the WG to start an
> exhaustive analysis on all of the proposals.
> >
> > Thanks.
> > s.
> >
> >
> >> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$
> > Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!S1aUaf8ierFVerfLLA2pLHDrMNPcbbuXLHgUr_2D-ggrgxdFATJJn5IQ8DARFpA5$

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 26 May 2020 19:40:54 -0400

Wim

SR-MPLS reuses the MPLS data plane.  That is a nice brown field migration
option for MPLS customers that want to eliminate ldp state.

Don’t get me wrong SR-MPLS has its place and its for brown field MPLS
deployments and SRv6 has its place as well for cases mostly intra domain
where you don’t have inter domain traffic steering with very long strict
paths which run into SR-TE MSD issues.

For deployments that want to use the IPv6 data plane and have ubiquitous
use cases inter or intra domain and not have the extra baggage 🧳 of SRv6
programming SID depth overhead with strict paths or  SR-MPLS - MPLS data
plane which also has MSD SID depth issue with long strict paths = CRH
shines and is the best solution

Thanks

Gyan

On Tue, May 26, 2020 at 10:27 AM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> if you look into the details RFC8663 from a data-plane operation is very
> similar to CRH. It uses a tag and derives a destination ipv6 address from
> it.
> On top it if you look at the requirements which are discussed on the
> mailing list, the following is possible with RFC8663
>
> Uses MPLS but it is used here as a lookup tag, not any different than the
> CRH proposal. In essence if you look at the details you can implement this
> with a complete v6 infrastructure and use the tag as a steering function.
> And uses 32 bit.
>
> As such I don’t see why we need another encap to achieve something we
> already can do and is available in various implementations and is as
> efficient on the wire (looking at 32 bit, which is what people agree upon).
>
> On 16/05/2020, 00:14, "ipv6 on behalf of Bob Hinden" <
> [email-masked] on behalf of [email-masked]> wrote:
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 May 2020 02:24:54 +0000

If the draft intents to provide a mapping based Segment Routing solution, there are SR-MPLS, SR-MPLS over IP exist, and there are implementations that work very well; seems no need to define a new one;

If the draft intents to provide a header compression solution to SRv6, there are several candidate solutions under discussion; seems it's premature to consider just adopting one and ignoring others;

If the draft intents to be one of the building blocks of a new competing IPv6 based Segment Routing solution, given the community has been working on SRv6 for so many years, it needs to prove that the new solution has much better merits than SRv6;

So, based on the above, I do not support the adoption at this moment. 

Best regards,
Mach

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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 May 2020 03:32:23 +0000

Mach,

The CRH is unique in the following respect. It does not rely on an instruction or a path being encoded in the IPv6 Destination Address. It relies only on RFC 4291 IP Address semantics.

Can you show me another IPv6 traffic steering solution that:

- is equally compressed
- does not rely on an instruction being encoded in the IPv6 destination address
- does not rely on all endpoints being numbered from the same IPv6 prefix

                                                                                                  Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Mach Chen
Sent: Tuesday, May 26, 2020 10:25 PM
To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Best regards,
Mach

> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-6
> man-comp-rtg-hdr__;!!NEt6yMaO-gk!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8
> UyCSeGfcx_3QbeQW7FjgwyIXhFe$
>
> document should be directed to the mailing list.  Editorial 
> 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.
>
> 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.
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8UyCSeGfcx_3QbeQW7Fjg-IpFdTb$
--------------------------------------------------------------------

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 03:33:58 +0000

Gyan, if you look in the details of RFC8663, you can do all of the things you mentioned. You can do loose path which are connected via ipv6 island exactly like CRH is proposing and more. As said here is a misconception that RFC8663 is strictly MPLS and I have to repeat it is not. You can do all the things that are suggested with CRH and more, with the same addressing mechanism, etc that is proposed in CRH. On top you get the natural extensions we are defining for free.
There is no need to reinvent the wheel here.

From: Gyan Mishra <[email-masked]>
Date: Wednesday, 27 May 2020 at 01:41
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Wim

SR-MPLS reuses the MPLS data plane.  That is a nice brown field migration option for MPLS customers that want to eliminate ldp state.

Don’t get me wrong SR-MPLS has its place and its for brown field MPLS deployments and SRv6 has its place as well for cases mostly intra domain where you don’t have inter domain traffic steering with very long strict paths which run into SR-TE MSD issues.

For deployments that want to use the IPv6 data plane and have ubiquitous use cases inter or intra domain and not have the extra baggage 🧳 of SRv6 programming SID depth overhead with strict paths or  SR-MPLS - MPLS data plane which also has MSD SID depth issue with long strict paths = CRH shines and is the best solution

Thanks

Gyan

On Tue, May 26, 2020 at 10:27 AM Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
if you look into the details RFC8663 from a data-plane operation is very similar to CRH. It uses a tag and derives a destination ipv6 address from it.
On top it if you look at the requirements which are discussed on the mailing list, the following is possible with RFC8663

On 16/05/2020, 00:14, "ipv6 on behalf of Bob Hinden" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Regards,
    Bob and Ole

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 03:37:09 +0000

Ron, as I mentioned in another thread, RFC8663 does this. Same addressing mechanisms as you highlight and is equally compressed (comparing 32 bit)

On 27/05/2020, 05:32, "ipv6 on behalf of Ron Bonica" <[email-masked] on behalf of rbonica=[email-masked]> wrote:

    Mach,

    - is equally compressed

                                                                                                      Ron

    -----Original Message-----
    From: ipv6 <[email-masked]> On Behalf Of Mach Chen
    Sent: Tuesday, May 26, 2020 10:25 PM
    To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
    Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Best regards,
    Mach

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 26 May 2020 23:39:32 -0400

CRH is not a mapping based solution like SR-MPLS where each segment or SID
is a label allocated from the SRBB to build the dynamic path or binding sid
to create a SR-TE per VRF tunnel color mapping.

The only thing in common between CRH and SRv6 is they both utilize the IPv6
data plane and they both can be used for traffic steering.  How CRH
achieves the traffic steering is completely different then SRv6.  SRv6
performs steering natively using SRH and prefix SID end instantiation and
adjacency SID end.x instantiation and for per VRF custom traffic coloring
and use of flex algo utilizes SR-TE binding SID at the source node to
instantiate the steered path.

CRH does not use labels or index  for the segments in the SRH header as
does SR-MPLS which uses MPLS labels as SID for hop by hop steering or uses
an IPV6 128 bit address or a compressed or index based compressed IPv6
address as the SID instruction for steering.

CRH uses a new CRH-16 or CRH-32 RH which has a list of routing segments.
The routing segment is an index which identifies a CRH-FIB entry contains
an IPv6 address of the next hop to steer the packet.  The CRH-FIB can be
populated via CLI locally or PCE controller centralized model  or
distributed model via IGP extension.

The CRH draft is a component of SRM6 Spring draft which is why it states
that the CRH-FIB can be populated via IGP.  However the CRH draft can act
independently and a lean low overhead steering method and in that scenario
only CLI or PCE methods are available to populate the CRH-FIB.

In the context of Spring,  SRM6 draft has the same capabilities as SRV6 or
SR-MPLS and uses the same binding sid with SR-TE for per VRF coloring with
flex algo for steering Inter or intra domain in a service provider network.

CRH is a very lean draft that does not have those same capabilities of
steering with SR-TE but it does support flex algo as that is IGP extension
independent of SR.  All the steering by CRH is done natively using the new
routing headers.

Kind Regards

Gyan

On Tue, May 26, 2020 at 10:25 PM Mach Chen <[email-masked]> wrote:

> If the draft intents to provide a mapping based Segment Routing solution,
> there are SR-MPLS, SR-MPLS over IP exist, and there are implementations
> that work very well; seems no need to define a new one;
>
> If the draft intents to provide a header compression solution to SRv6,
> there are several candidate solutions under discussion; seems it's
> premature to consider just adopting one and ignoring others;
>
> If the draft intents to be one of the building blocks of a new competing
> IPv6 based Segment Routing solution, given the community has been working
> on SRv6 for so many years, it needs to prove that the new solution has much
> better merits than SRv6;
>
> this draft.
> contributors,
-- 

*Gyan Mishra*

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 May 2020 03:43:35 +0000

Ron, Wim:

I agree with Wim here.

Best regards,
Mach

> From: Henderickx, Wim (Nokia - BE/Antwerp)
> [mailto:[email-masked]]
> Sent: Wednesday, May 27, 2020 11:37 AM
> To: Ron Bonica <rbonica=[email-masked]>; Mach Chen
> <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List
> <[email-masked]>
> Ron, as I mentioned in another thread, RFC8663 does this. Same addressing
> mechanisms as you highlight and is equally compressed (comparing 32 bit)
> 
> On 27/05/2020, 05:32, "ipv6 on behalf of Ron Bonica"
> <[email-masked] on behalf of rbonica=[email-masked]>
> wrote:
> 
>     Mach,
> 
>     The CRH is unique in the following respect. It does not rely on an
> instruction or a path being encoded in the IPv6 Destination Address. It relies
> only on RFC 4291 IP Address semantics.
> 
>     If the draft intents to provide a mapping based Segment Routing
> solution, there are SR-MPLS, SR-MPLS over IP exist, and there are
> implementations that work very well; seems no need to define a new one;
> 
> there are several candidate solutions under discussion; seems it's premature
> to consider just adopting one and ignoring others;
> 
> IPv6 based Segment Routing solution, given the community has been
> working on SRv6 for so many years, it needs to prove that the new solution
> has much better merits than SRv6;
> 
> this
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
> ;!!NEt6yMaO-gk!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8UyCSeGfcx_3Qbe
> QW7Fjg-IpFdTb$

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 27 May 2020 00:16:05 -0400

Hi Wim

You mention SR-MPLS and SR-MPLS over IP as if they are two different
flavors of SR.  They are one and the same per RFC 8663.  Am I missing
something here?

SR-MPLS reuses the MPLS IPv4 LDPv4 data plane once LDPv4 is removed from
the network to provide a stateless SR-MPLS based on 4 byte MPLS shim now
containing new SRGB label range.

Are you referring to MPLSoUDP RFC 7510 or MPLS over GRE RFC 4023 and using
SR-MPLS reuse of MPLS data plane IPv4 and tunneling via GRE is UDP?

Not sure how that would work or make it similar to CRH.

I am not following how SR-MPLS is similar to CRH.

Please explain?

Gyan

On Tue, May 26, 2020 at 11:33 PM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> Gyan, if you look in the details of RFC8663, you can do all of the things
> you mentioned. You can do loose path which are connected via ipv6 island
> exactly like CRH is proposing and more. As said here is a misconception
> that RFC8663 is strictly MPLS and I have to repeat it is not. You can do
> all the things that are suggested with CRH and more, with the same
> addressing mechanism, etc that is proposed in CRH. On top you get the
> natural extensions we are defining for free.
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Wednesday, 27 May 2020 at 01:41
> *To: *"Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
> *Cc: *Bob Hinden <[email-masked]>, IPv6 List <[email-masked]>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: Mach Chen <[email-masked]>
Date: Wed, 27 May 2020 04:17:43 +0000

Hi Gyan,

Please see some responses inline…

Best regards,
Mach

From: Gyan Mishra [mailto:[email-masked]]
Sent: Wednesday, May 27, 2020 11:40 AM
To: Mach Chen <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

CRH is not a mapping based solution like SR-MPLS where each segment or SID is a label allocated from the SRBB to build the dynamic path or binding sid to create a SR-TE per VRF tunnel color mapping.

[Mach] IMHO, except for the place where to put SIDs list, I don’t think there are essential difference between CRH and SR-MPLS over IPv6. For SR-MPLS, the label can be from SRGB or SRLB, for CRH, the SID can be domain wide unique or local significance.  From forwarding point of view, the label or SID is just an identifier, no matter for SR-MPLS over IP or CRH, a node just maps a label/SID to an IP address and forward the packet.

The only thing in common between CRH and SRv6 is they both utilize the IPv6 data plane and they both can be used for traffic steering.  How CRH achieves the traffic steering is completely different then SRv6.  SRv6 performs steering natively using SRH and prefix SID end instantiation and adjacency SID end.x instantiation and for per VRF custom traffic coloring and use of flex algo utilizes SR-TE binding SID at the source node to instantiate the steered path.

[Mach] This is one of my concerns, both can provide the same functions but with different ways. Given that the community has spent a lot of energy on SRv6, why do we need to re-invent a new one? A straight forward way is to optimize/enhance the existing solution. If SRm6 and SRv6 change their places, I will have the same comment for SRv6.

CRH does not use labels or index  for the segments in the SRH header as does SR-MPLS which uses MPLS labels as SID for hop by hop steering or uses an IPV6 128 bit address or a compressed or index based compressed IPv6 address as the SID instruction for steering.

CRH uses a new CRH-16 or CRH-32 RH which has a list of routing segments.  The routing segment is an index which identifies a CRH-FIB entry contains an IPv6 address of the next hop to steer the packet.  The CRH-FIB can be populated via CLI locally or PCE controller centralized model  or distributed model via IGP extension.

[Mach] IMHO, the above does not make CRH special and supper, it just define a new way to achieve the goal.

The CRH draft is a component of SRM6 Spring draft which is why it states that the CRH-FIB can be populated via IGP.  However the CRH draft can act independently and a lean low overhead steering method and in that scenario only CLI or PCE methods are available to populate the CRH-FIB.

In the context of Spring,  SRM6 draft has the same capabilities as SRV6 or SR-MPLS and uses the same binding sid with SR-TE for per VRF coloring with flex algo for steering Inter or intra domain in a service provider network.

[Mach] As above, I am not sure it’s necessary to define a new solution to provide the same capabilities that an existing solution already supported.

CRH is a very lean draft that does not have those same capabilities of steering with SR-TE but it does support flex algo as that is IGP extension independent of SR.  All the steering by CRH is done natively using the new routing headers.

Kind Regards

Gyan

On Tue, May 26, 2020 at 10:25 PM Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
If the draft intents to provide a mapping based Segment Routing solution, there are SR-MPLS, SR-MPLS over IP exist, and there are implementations that work very well; seems no need to define a new one;

Best regards,
Mach

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 04:27:00 +0000

Gyan,

RFC 8663 is defining a framework to encap. SID(s) if you will in ipv4 or ipv6 and there are various encaps defined. UDP based, mainly for ipv4 and native v6 RFC 4023 or a GRE flavor.. If you look at the native v6 flavor of RFC4023 which is not using GRE, etc. What you get is a v6 header where we add SID(s) in the next header before the real payload. Think of them as instructions which define a behavior.

If you compare CRH, it is similar wrt the bevior. You have a v6 header where in an extensions header you encode some SID, which are instructions.

Now look at the intrinsic behavior that CRH has wrt steering. For the node that process the SID, you do a lookup and define the next behavior, which is essentially getting a v6 address for the next hop in the chain. You can do the same thing with RFC8663.

Date: Wednesday, 27 May 2020 at 06:16

Hi Wim

You mention SR-MPLS and SR-MPLS over IP as if they are two different flavors of SR.  They are one and the same per RFC 8663.  Am I missing something here?

SR-MPLS reuses the MPLS IPv4 LDPv4 data plane once LDPv4 is removed from the network to provide a stateless SR-MPLS based on 4 byte MPLS shim now containing new SRGB label range.

Are you referring to MPLSoUDP RFC 7510 or MPLS over GRE RFC 4023 and using SR-MPLS reuse of MPLS data plane IPv4 and tunneling via GRE is UDP?

Please explain?

Gyan

On Tue, May 26, 2020 at 11:33 PM Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>> wrote:
Gyan, if you look in the details of RFC8663, you can do all of the things you mentioned. You can do loose path which are connected via ipv6 island exactly like CRH is proposing and more. As said here is a misconception that RFC8663 is strictly MPLS and I have to repeat it is not. You can do all the things that are suggested with CRH and more, with the same addressing mechanism, etc that is proposed in CRH. On top you get the natural extensions we are defining for free.
There is no need to reinvent the wheel here.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 May 2020 at 01:41
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>, IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Wim

Thanks

Gyan

    Regards,
    Bob and Ole

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
Silver Spring, MD<https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 27 May 2020 14:02:40 +0800

Hi，folks, 
After reviewing the CRH documents, I don't think it is the right time to adopt CRH.
Our company has implementated SRv6 field trial in several provinces, so we are very concerned about the compatiblity of any new compressed header approach. We don't expect multiple compressed header standards in the future. Up to now, I haven't found any compatiblity of CRH with SRv6, so I don't support to adopt it now. Accordingly, we prefer to choose new approach which has consider the compatiblity with SRv6, such as G-SRv6, although it needs further improvement. 
Therefore, we think this is not a good time to adopt a specific solution right now, we should discuss the requirements and solutions before adoption any one solution.

Best regards
Chongfeng 
 
-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Bob Hinden
发送时间: 2020年5月16日 06:14
收件人: IPv6 List
抄送: Bob Hinden
主题: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

 

 

 
Regards,
Bob and Ole

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 27 May 2020 07:00:09 +0000

Hi, 

After reading this document, my understanding is that it provides similar functionality as Segment Routing, by introducing new data plane encodings. Considering that we already have SR-MPLS , SR-MPLS over IP and SRv6 for different network requirements, I'm not convinced why we need another data plane for the same function.

And as already mentioned by others, if the purpose is to provide source routing header compression in IPv6 environment, compatibility with SRv6 needs to be considered in the solution design. Also it is noted that there are other candidates for header compression, which means broader discussion and comparison is needed before adopting any specific solution. 

Thus I do not support the adoption of this document at this moment.

Best regards,
Jie

---

From: Reji Thomas <[email-masked]>
Date: Wed, 27 May 2020 13:16:15 +0530

I support the adoption.

CRH is well defined, being conformant to the v6 architecture is a useful
addition to the existing IPv6 protocol building blocks.  CRH already has
asic based implementation which demonstrates  packet forwarding at line
rate and any concern on forwarding efficiency doesn’t hold ground.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 May 2020 10:23:50 +0200

Hello Ron,

I recommend you take a look at this URL:

https://mailarchive.ietf.org/arch/msg/ipv6/Ef05LFFij45mm8fM8hLFXknxoIA/

with two additional observations:

#1 - Reference can be encoded into a new fixed and immutable RH (applied on
end hosts or ingress routers) ways easier than a chain of CRIDs.
Literally from IPv6 side you are not "encoding" the pointer into the
address. You are simply specifing next loopback address which is of 128
bits. Plain IPv6. Packets arriving at that loopback have mapped
instructions how to forward them.

#2 - For cases discussed recently where some folks are planning to use CRH
over Internet I am afraid a lot of third party networks may just blindly
fail to deliver such packets:
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06
Therefore for such use case I do recommend use of RbR.

Best regards,
R.

On Wed, May 27, 2020 at 5:32 AM Ron Bonica <rbonica=
[email-masked]> wrote:

> instruction or a path being encoded in the IPv6 Destination Address. It
> relies only on RFC 4291 IP Address semantics.
>

---

From: Antonio Cianfrani <[email-masked]>
Date: Wed, 27 May 2020 12:00:22 +0200

Dear All,

I don't support the adoption.

>From my point of view, CRH is not providing any advantage with respect to
SR (that is a mature technology now). Regarding header compression, several
solutions have been proposed for SRv6. Moreover, the SFC support is not
provided in CRH (NSH is needed). Finally, I believe that a detailed
comparison between CRH and SR is needed before proceeding with an adoption
call.

Kind regards,

Antonio Cianfrani
Associate Professor
University of Rome Sapienza

-- 

*Il tuo 5 diventa 1000 - *Fai crescere la tua università - Dona il 5 per 
mille alla Sapienza
Codice fiscale: *80209930587*

https://www.uniroma1.it/it/pagina/fai-crescere-la-tua-universita-con-il-cinque-mille 
<https://www.uniroma1.it/it/pagina/fai-crescere-la-tua-universita-con-il-cinque-mille>

-- 
________________________________________________________
Le informazioni 
contenute in questo messaggio di posta elettronica sono strettamente 
riservate e indirizzate esclusivamente al destinatario. Si prega di non 
leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non 
si è il legittimo destinatario dello stesso. Qualora tale messaggio sia 
stato ricevuto per errore, si prega di restituirlo al mittente e di 
cancellarlo permanentemente dal proprio computer.
The information contained 
in this e mail message is strictly confidential and intended for the use of 
the addressee only.  If you are not the intended recipient, please do not 
read, copy, forward or store it on your computer. If you have received the 
message in error, please forward it back to the sender and delete it 
permanently from your computer system.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 27 May 2020 13:03:41 +0200

Hello,

I would like to formally state that I do not support adoption
of draft-bonica-6man-comp-rtg-hdr

Reasons:

* Those interested in source routing with IPv6 can use existing solutions.
If current set of solutions lacks some functionality SPRING WG can be the
right forum to discuss the missing elements or for that matter to discuss
rational to specify new SRH TLV which could even carry CRIDs if WG decides
it is a good idea.

* Those however interested in zero overhead, simple IPv6 based path
engineering can use Reference based Routing (RbR) proposal which either
does not require any protocol changes at all or could define a new routing
header to only carry 32 bits reference ID irrespective of number of
midpoints to traverse. Ref:
https://mailarchive.ietf.org/arch/msg/ipv6/Ef05LFFij45mm8fM8hLFXknxoIA/

Kind regards,
Robert.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 27 May 2020 14:06:09 +0000

Hi,

I do not support the adoption of this document.

The reason being that there are multiple documents addressing the same problem, and I personally don't see the merit of this one vs the others.
Also, as discussed, when used with IPv6, RFC8663 can achieve the same goals.

Thanks.
Jorge

-----Original Message-----
From: ipv6 <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Date: Saturday, May 16, 2020 at 12:13 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Regards,
    Bob and Ole

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 14:54:24 +0000

Hi Folks,

I do not support the adoption of this work.

Why?
There seems to be only marginal behavior difference with RFC8663. 
RFC8663 is proven to work well during many years for many use-cases.
Both CRH and RFC8663 are mapping technologies and suffer the scale and characteristics of such architecture.
A powerful property of RFC8663 is no need for kernel access by applications, making it a convenient solution to implement and operate.
We do not need another mapping technology and cause additional interop problems

G/

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 00:14
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 27 May 2020 15:00:08 +0000

Hi Bob & WG,
My main concern is the security aspect, and there have been some discussions and ongoing improvements.
At the meantime, there are still some very basic points haven't been clear.
I would prefer to see these basic points clear and the security mechanism solid before adoption.
Therefore, I don't support the adoption in current stage.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Srihari Sangli <[email-masked]>
Date: Wed, 27 May 2020 15:06:43 +0000

I support the adoption. Thanks.

srihari…

On 16/05/20, 3:44 AM, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Bob and Ole

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 May 2020 15:56:38 +0000

Wm, Mach, Gunter,

Certainly you are not suggesting that:

- IPv6 doesn't need a native traffic steering mechanism
- All IPv6 applications that require traffic steering must rely on MPLS in some form (SR-MPLS over IP, MPLS over IP)

If you were making this argument, wouldn't it apply to all Routing headers, including the SRH?

There are a class of operators who:

- Cannot deploy MPLS on some nodes that need to be segment endpoints
- Would rather use the IPv6 Flow Label for load balancing than the UDP source port (as recommended by RFC 8663 via RFC 7510)

                                                                  Ron

-----Original Message-----
From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> 
Sent: Tuesday, May 26, 2020 11:37 PM
To: Ron Bonica <[email-masked]>; Mach Chen <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Mach,

    - is equally compressed

                                                                                                      Ron

    -----Original Message-----
    From: ipv6 <[email-masked]> On Behalf Of Mach Chen
    Sent: Tuesday, May 26, 2020 10:25 PM
    To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
    Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Best regards,
    Mach

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!QPUACt0y0m2WX2yQLbQraSGY4XAwZtROjp2esEmPZkcRW1pPY_Y6WykKXptMvNOl$
    --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 27 May 2020 16:15:49 +0000

I see value in CRH for real-world application areas including civil aviation and
worldwide ground transportation. I want to use it in the OMNI and AERO specs
that will apply to these domains and possibly many others.

Therefore, I support the adoption of draft-bonica-6man-comp-rtg-hdr.

Fred

>     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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 27 May 2020 16:49:51 +0000

Ron, the misconception that many people have is that RFC 8663 is requiring MPLS in a traditional way. As I mentioned RFC 8663 allows to do the same as what you are trying to do with CRH. The difference is that the traffic steering would use the bits in the next-header iso extension header and that's it.

The addressing as you highlighted is the same, no difference there; full RFC 4291 IP Address semantics. 
Some misconceptions:
- I need to run MPLS protocols for this. Answer is no.
- RFC 8663 does require UDP. Answer is no. You can use native RFC4023 which is not using UDP e.g. and you have the option to use native IP or with GRE encap, but to compare it against CRH use native ipv6 in RFC4023

Now to beauty of using RFC 8663 mechanism is that you don’t have to reinvent things in a new framework and new capabilities will be supported natively. Look at SFC, G/L-SID(s), OAM, etc etc.

So it allows also many scenario's like below. On top interworking with MPLS comes for free. Here are some examples.
- IP <-> IP <-> IP (e.g. CRH scenario)
- IP <-> MPLS <-> IP (e.g. scenario used in some DC(s) who want to leverage SR to compute)
- MPLS <-> IP <-> MPLS (e.g. interconnection networks across MPLS/IP links)

Given all of this, we should use the RFC 8663 for the use case you try to address here

On 27/05/2020, 17:56, "Ron Bonica" <[email-masked]> wrote:

    Wm, Mach, Gunter,

                                                                      Ron

    -----Original Message-----
    From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> 
    Sent: Tuesday, May 26, 2020 11:37 PM
    To: Ron Bonica <[email-masked]>; Mach Chen <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
    Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

        Mach,

        - is equally compressed

                                                                                                          Ron

        -----Original Message-----
        From: ipv6 <[email-masked]> On Behalf Of Mach Chen
        Sent: Tuesday, May 26, 2020 10:25 PM
        To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
        Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

        Best regards,
        Mach

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 May 2020 11:38:28 -0700

Hi Wim,
the use of EH brings one benefit, important in my opinion, for OAM -
preserving the path information. MPLS-over-IP, a.k.a., RFC 8663 does not
preserve the path traversed information. Of course, it is not critical for
getting packets from ingress to egress but is useful in troubleshooting,
fault localization, and performance measurement.

Regards,
Greg

On Tue, May 26, 2020 at 8:37 PM Henderickx, Wim (Nokia - BE/Antwerp) <
[email-masked]> wrote:

> On 27/05/2020, 05:32, "ipv6 on behalf of Ron Bonica" <
> [email-masked] on behalf of rbonica=[email-masked]>
> wrote:
>
>     Mach,
>
>     If the draft intents to be one of the building blocks of a new
> competing IPv6 based Segment Routing solution, given the community has been
> call
> about this draft.
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RFfjmZf_NdYDfA4BeXQjkrOe5nDx8fFfYnrJ8UyCSeGfcx_3QbeQW7Fjg-IpFdTb$

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 May 2020 11:46:49 -0700

Hi Gyan,
one comment to

I believe that is equally applicable to the Unified SID proposal
<https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/> that is
based on RFC 8754. The Unified SID does not introduce new RH types but
rather explicitly expresses the length of SID/index in the Flags field of
SRH. Would you agree that functionally CRH and the Unified SID are very
close?

Regards,
Greg

On Tue, May 26, 2020 at 8:40 PM Gyan Mishra <[email-masked]> wrote:

> The only thing in common between CRH and SRv6 is they both utilize the
> IPv6 data plane and they both can be used for traffic steering.  How CRH
>> for

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 May 2020 12:08:02 -0700

On Wed, May 27, 2020 at 11:47 AM Greg Mirsky <[email-masked]> wrote:

> is based on RFC 8754. The Unified SID does not introduce new RH types but

Greg,

Per RFC8754, SRH flags "MUST be 0 on transmission and ignored on receipt".
That means if a Unified SID SRH is sent to a legacy implementation the
receiver will ignore the flags and hence incorrectly process the SRH as
being a list of 128 bits as specified in RFC8754. Similarly tag and TLVs
can be ignored on receipt. Fundamentally, SIDs in SRH are 128 bits and
there's really no way to change that since there's no field in the header
that could serve as a robust codepoint for SID size. I think this is going
to be an issue with any attempts to compress SIDs and still use the same
SRH routing type, however I also don't think this is really a problem since
there are plenty of available routing types left to be allocated, so the
routing type can be used to indicate the SID size (as CRH proposes with two
routing types for 16 and 32 bits).

Tom

>> CRH is not a mapping based solution like SR-MPLS where each segment or
>> SID is a label allocated from the SRBB to build the dynamic path or binding
>> sid to create a SR-TE per VRF tunnel color mapping.
>>
>> In the context of Spring,  SRM6 draft has the same capabilities as SRV6
>> or SR-MPLS and uses the same binding sid with SR-TE for per VRF coloring
>> with flex algo for steering Inter or intra domain in a service provider
>> network.
>>
>>> to start a

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 May 2020 12:18:12 -0700

Hi Tom,
I agree that introduction of a new interpretation of a two bits-long field
in Flags creates a backward compatibility issue. We're planning to have
companion documents that explain how extensions to IGP and BGP-LS
advertise the new capability, i.e., support of the Unified SID.

Regards,
Greg

On Wed, May 27, 2020 at 12:08 PM Tom Herbert <[email-masked]> wrote:

>>> CRH uses a new CRH-16 or CRH-32 RH which has a list of routing
>>> segments.  The routing segment is an index which identifies a CRH-FIB entry
>>> contains an IPv6 address of the next hop to steer the packet.  The CRH-FIB
>>> can be populated via CLI locally or PCE controller centralized model  or

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 May 2020 12:39:30 -0700

> advertise the new capability, i.e., support of the Unified SID.

Then the format of a header in the datapath is no longer self-defining and
requires external information from the control plane just to be able to
parse it correctly. Why not just define new routing types for different
formats like CRH does, or even better why not try to unify Unified SID with
CRH given that the functionality of the proposals is very close as you
already pointed out?

Tom

Regards,
>> Per RFC8754, SRH flags "MUST be 0 on transmission and ignored on
>> receipt". That means if a Unified SID SRH is sent to a legacy
>> implementation the receiver will ignore the flags and hence incorrectly
>> process the SRH as being a list of 128 bits as specified in RFC8754.
>> Similarly tag and TLVs can be ignored on receipt. Fundamentally, SIDs in
>> SRH are 128 bits and there's really no way to change that since there's no
>> field in the header that could serve as a robust codepoint for SID size. I
>> think this is going to be an issue with any attempts to compress SIDs and
>> still use the same SRH routing type, however I also don't think this is
>> really a problem since there are plenty of available routing types left to
>> be allocated, so the routing type can be used to indicate the SID size (as
>> CRH proposes with two routing types for 16 and 32 bits).
>>
>> Tom
>>
>>
>>> Regards,
>>> Greg
>>>
>>>> The CRH draft is a component of SRM6 Spring draft which is why it
>>>> states that the CRH-FIB can be populated via IGP.  However the CRH draft
>>>> can act independently and a lean low overhead steering method and in that
>>>> scenario only CLI or PCE methods are available to populate the CRH-FIB.
>>>>
>>>>> call for

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 27 May 2020 20:07:28 +0000

I paused my replies for a while to see where the conversation went.

What I observed in my objection to 6man adopting this document is being highlighted by others.
"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.”

Some examples are:
- Why 16 or 32bit, why not one or the other, or why not 24, 48, 64?
- OAM and mapping table debugging will be an issue requiring more tools and standards.
- Realization that an “SDN” controller isn’t enough, BGP, ISIS, OSPF, other protocol work will be needed for mapping table distribution?
- ID ranges and how they are carved is not clear.
- What is the global vs local scope, how is conflict resolution handled, this has been mentioned a few times.

The IPv6-ness of this header ends at its routing header type.
Beyond that, the mapping of IDs is not IPv6 nor a 6man thing.
At best they are a subset of work SPRING has defined for the MPLS and IPv6 dataplanes.

If the intent is to be a general purpose IPv6 routing header within some limited domain, the WG may be better off looking at the compressed header in RFC8138. Or if tags are needed RFC8663 and calling it a day.

Thanks
  Darren

On May 16, 2020, at 9:59 AM, Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>> wrote:

Hi Bob and Ole.

Thanks
  Darren

Regards,
Bob and Ole

---

From: Martin Horneffer <[email-masked]>
Date: Wed, 27 May 2020 22:33:04 +0200

Dear working group,

as an operator I am currently working on getting SR-MPLS into a 
multi-AS, multi-service global core network. Managing a SID mapping for 
all relevant nodes and services has been done, but definitely was a 
serious effort in our environment as many different (company internal) 
parties need to be coordinated.

SRv6 seems to me like a great opportunity for further network technology 
consolidation in the future, covering all kinds of network domains. This 
opportunity is, in my eyes, only based on the huge and universal address 
space offered by IPv6. Any continued or even additional need to map 
topological nodes or services to SIDs would, in my opinion, thwart the 
main opportunities of SRv6. In comparison to the relatively simple 
deployment of SR-MPLS in the mere core network, any end-to-end 
deployment of SRv6 throughout all core, aggregation and access network 
domains as well as data centers and service areas would require even 
more organizational units to agree on a new central SID registry. Thus I 
believe the many SRv6 use cases will only practically work when _not_ 
relying on new maps or tables for any kind of SID.

Also the CRH does not solve a problem that I would consider as serious. 
 From all scenarios we have seen so far and all research we have seen I 
seriously doubt that more than a few segments will be needed. And even 
if the number of segments needed came close to something like 10, I do 
_not_ consider the mere overhead of the SRH of 168 byte a serious problem.

Overall I don't see how CRH solves more problems than SR-MPLS with a 
IPv6 control plane would do. And that would really be a less complex 
solution.

I would truly prefer implementors to concentrate on everything that is 
need to complete use cases based on the plain SRH, rather than inventing 
a new routing header every other year.

Thus I do _not_ support wg adoption of this draft.

Best regards, Martin

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 27 May 2020 13:33:01 -0700

Hi Tom,
thank you for the suggestion. I think that is one of the possibilities if
the WG decides to ask authors to work on the joint draft. At the same time,
we need to recognize those other proposals to address the need (it seems
that there's an implicit agreement) of a shorter SID in SR over IPv6 do
change, as I understand them, the interpretation of the Segment field in
the SRH. Hence, the Unified SID isn't alone to propose a solution to the
problem recognized by the community by updating RFC 8754.

Regards,
Greg

On Wed, May 27, 2020 at 12:39 PM Tom Herbert <[email-masked]> wrote:

>> I agree that introduction of a new interpretation of a two bits-long
>> field in Flags creates a backward compatibility issue. We're planning to
>> have companion documents that explain how extensions to IGP and BGP-LS
>>>>> CRH does not use labels or index  for the segments in the SRH header
>>>>> as does SR-MPLS which uses MPLS labels as SID for hop by hop steering or
>>>>> uses an IPV6 128 bit address or a compressed or index based compressed IPv6
>>>>> In the context of Spring,  SRM6 draft has the same capabilities as
>>>>> SRV6 or SR-MPLS and uses the same binding sid with SR-TE for per VRF
>>>>> coloring with flex algo for steering Inter or intra domain in a service
>>>>> provider network.
>>>>>
>>>>>> If the draft intents to provide a header compression solution to
>>>>>> SRv6, there are several candidate solutions under discussion; seems it's

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 27 May 2020 15:42:11 -0700

Agreed. I do not support the adoption of this document…

Thanks,
Tetsuya

> On May 22, 2020, at 4:07 AM, Pablo Camarillo (pcamaril) <pcamaril=[email-masked]> wrote:
> 
> Bob, Ole,
>  
> 2.- This is not a standalone document. Despite from the document stating that the CRH-FIB will be populated by means of CLI, I think everyone in this group would oppose to that; configuring all 2^16 labels manually in all routers is an operational burden… 
> “   Standards track documents must include a description of the protocol.
>    references that give such a description is necessary.”
>  
> [1].- https://mailarchive.ietf.org/arch/msg/spring/aLhIQ2btTfNkJ4ghruuXbm3zY30/ <https://mailarchive.ietf.org/arch/msg/spring/aLhIQ2btTfNkJ4ghruuXbm3zY30/>
>  
>  
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr <https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr>
>  
> 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.
>

---

From: Michael McBride <[email-masked]>
Date: Thu, 28 May 2020 02:19:41 +0000

Stefano,

> So, at this stage I don't support the adoption of draft-bonica-6man-comp-rtg-hdr and would prefer to see the WG to start an exhaustive analysis on all of the proposals.

+1. This is a good way to proceed. In bierwg we were given similar direction due to having several proposals for bier and ipv6 (we could still use guidance on this from 6man). We are subsequently developing a requirements document which also describes all of the proposals inc. header format comparisons: draft-ietf-bier-ipv6-requirements. We may want to do the same in 6man prior to considering adoption of any new proposals.

thanks,
mike

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7Ce23c8856f8f74dccf80608d8017a6089%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260972422587896&amp;sdata=lcQZOhdeXtr8KE%2FhpchuvdBs5xupe%2B0YZmGSh9kHAZU%3D&amp;reserved=0
> 
> Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7Ce23c8856f8f74dccf80608d8017a6089%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260972422587896&amp;sdata=OybNdRqqPmASS42FTTPuLAQTUhrdkfSWIZaVDa%2F9KZM%3D&amp;reserved=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7Ce23c8856f8f74dccf80608d8017a6089%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637260972422587896&amp;sdata=OybNdRqqPmASS42FTTPuLAQTUhrdkfSWIZaVDa%2F9KZM%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Tom Herbert <[email-masked]>
Date: Wed, 27 May 2020 19:47:32 -0700

On Wed, May 27, 2020, 1:33 PM Greg Mirsky <[email-masked]> wrote:

> the SRH.
Greg,

Yes, I've looked at the G-SID and vSID proposals also, and it does appear
they are also changing the format SRH without a using a new routing type. I
don't see these proposals are feasible in their current form since SRH has
no provision for extensibility that is also backwards compatible. This
would be a different story if flags field in SRH was defined to must be
checked to be zero at receiver instead of ignored.

Tom

Hence, the Unified SID isn't alone to propose a solution to the problem
> recognized by the community by updating RFC 8754.
>
> Regards,
> Greg
>
>> Then the format of a header in the datapath is no longer self-defining
>> and requires external information from the control plane just to be able to
>>>>>> CRH is not a mapping based solution like SR-MPLS where each segment
>>>>>> or SID is a label allocated from the SRBB to build the dynamic path or
>>>>>> binding sid to create a SR-TE per VRF tunnel color mapping.
>>>>>>
>>>>>> The only thing in common between CRH and SRv6 is they both utilize
>>>>>> the IPv6 data plane and they both can be used for traffic steering.  How
>>>>>> CRH achieves the traffic steering is completely different then SRv6.  SRv6
>>>>>> CRH is a very lean draft that does not have those same capabilities
>>>>>> of steering with SR-TE but it does support flex algo as that is IGP
>>>>>> extension independent of SR.  All the steering by CRH is done natively
>>>>>> using the new routing headers.
>>>>>>
>>>>>> Kind Regards
>>>>>>
>>>>>> Gyan
>>>>>>

---

From: Ran Pang(联通集团联通网络技术研究院本部) <[email-masked]>
Date: Thu, 28 May 2020 07:38:49 +0000

Hi WG,

It seems like CRH is not compatible with SRv6 and SRH. We need to discuss how CRH cooperates with uSID, G-SRv6 or other SRv6 header compression solutions before adoption, or whether CRH will cause difficulties in the deployment of G-SRv6 and other solutions. At present, we tend to choose solutions compatible with SRH.

Thanks,
Ran

From: Bob Hinden<mailto:[email-masked]>
Date: 2020-05-16 06:13
To: IPv6 List<mailto:[email-masked]>
CC: Bob Hinden<mailto:[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
This message starts a two-week 6MAN call on adopting:

Regards,
Bob and Ole

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Miya Kohno <[email-masked]>
Date: Thu, 28 May 2020 17:53:13 +0900

Hello,

I do not support this proposal.

At first glance it may look good because it adheres to the conventional
IPv6 standards, but in reality it is not.

- Many additional control planes [*] need to be developed,  in order to
make CRH work.

- And more importantly, it interferes the evolution of IPv6.
  -- There is a simpler, more scalable way to do it, but CRH can delay it,
sticking to the existing convention.
  -- This can take away the potential of IPv6 itself.
  -- IPv6 should evolve. Otherwise, we have no choice but to give way to
the new Non-IP or IPvx proposals.

Thanks!
Miya

[*]
draft-bonica-lsr-crh-isis-extensions
draft-alston-spring-crh-bgp-signalling
draft-ssangli-bess-bgp-vpn-srm6
draft-bonica-spring-sr-mapped-six
draft-bonica-6man-seg-end-opt
draft-bonica-6man-vpn-dest-opt

---

From: Kentaro Ebisawa <[email-masked]>
Date: Thu, 28 May 2020 18:17:43 +0900

Hello,

I do not support the adoption of this work. (at this timing)

There are a couple of similar proposals (i.e. G-SRH, uSID, VLSID), and I would like to see the discussion among them more matured before adopting any of them as a WG draft so we can avoid the remaining ones to be rejected in future just because there are one already selected as a WG item.

If CRH is not intended to be used for the same purpose as other proposals, then I would like to understand for what and how CRH will be used and clarify it is not trying to solve the same problem which other proposals are also intending to. This way we could compare and adopt one of the other proposals in future as a SRv6 SID compression solution, regardless of the status of this work.

Thanks,

-- 
Kentaro Ebisawa
List: <[email-masked]>
Biz:  <[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2020 07:02:24 -0300

On 28/5/20 05:53, Miya Kohno wrote:
>    -- There is a simpler, more scalable way to do it, but CRH can delay 
> it, sticking to the existing convention.
>    -- IPv6 should evolve. Otherwise, we have no choice but to give way 
> to the new Non-IP or IPvx proposals.

Huh?

If anything, this is simply one Routing Header. The reason for which we 
have a routing header *type* field is so that multiple routing headers 
can be specified.

What potential would this take away???

Give way to new non-ip and IPvx proposals????

Could you please back your statements? -- Because they seem anything but 
technical.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 28 May 2020 18:56:53 +0800

Hi,

I do not support the adoption of this draft this moment.
There are too many issues required resolved. 
First is that CRH is a mapping table based solution, which means in a
large-scale multi-domain interconnect, like MPLS, the CRH suffers from the
large label stack and protection/ convergence challenges.
Second is that CRH and SRv6 are incompatible, which affects the existed
network deployment. 
Third is the security considerations are really not clear, meanwhile it is
very important for a operator.
The most important one is there are couple of similar solutions that need
discuss together.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Bob Hinden
发送时间: 2020年5月16日 06:14
收件人: IPv6 List
抄送: Bob Hinden
主题: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 28 May 2020 12:06:57 +0000

I fully agree with what Wim has shared below. While this may be new to 6man, it has been previously stated by multiple participants at Spring WG meetings and shared with the proponents of the CRH proposal.

Segment Routing solution for IPv6 have been specified by the IETF to address these use-cases. 

https://tools.ietf.org/html/draft-filsfils-spring-sr-mpls-ipv6-control-plane-02 

I agree that it is better done with a well-known mapping technology (i.e. MPLS) than reinventing the wheel.

Thanks,
Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: 27 May 2020 22:20
To: Ron Bonica <[email-masked]>; Mach Chen <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>; Gunter Van de Velde <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

    Wm, Mach, Gunter,

                                                                      Ron

    -----Original Message-----
    From: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]> 
    Sent: Tuesday, May 26, 2020 11:37 PM
    To: Ron Bonica <[email-masked]>; Mach Chen <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
    Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

        Mach,

        - is equally compressed

                                                                                                          Ron

        -----Original Message-----
        From: ipv6 <[email-masked]> On Behalf Of Mach Chen
        Sent: Tuesday, May 26, 2020 10:25 PM
        To: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
        Subject: RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

        Best regards,
        Mach

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 28 May 2020 21:58:06 +0900

Hello 6man,

After my review on the draft and the discussions through the long thread, I couldn't convince myself on that 6man need to introduce new ID spaces in addition to the 128-bits address space. Moreover there's no specific request from other areas/WGs. Hence my conclusion is that I do not support this adoption.

But I really thank the authors and the proponents all efforts on this work. The precious takeaways will be good input to the on-going work in Spring.

Regards,
--satoru

> 2020/05/16 7:13、Bob Hinden <[email-masked]>のメール:
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Thu, 28 May 2020 14:50:22 +0000

Hello Working Group,

I would like to echo Martin on this, as I observe that we have about the same track record for SR-MPLS into multi-AS - and huge effort to coordinate multi-network domain SRv6 Architecture. I haven't seen, yet, deployment use cases that can only be achieve by CRH - and not by SR-MPLS (w/ IPv6)and SRv6. 
It would be nice, and a good 5 years of effort investment, to finish standardizing SRv6 before adopting a somewhat  "similar but not quite" new proposal. 

So, at this point I do not support working group adoption of CRH.

Regards,
dan

On 2020-05-27, 4:34 PM, "ipv6 on behalf of Martin Horneffer" <[email-masked] on behalf of [email-masked]> wrote:

    Dear working group,

    Best regards, Martin

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    ------------------------------------------------------------------------------
    External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Miya Kohno <[email-masked]>
Date: Fri, 29 May 2020 00:56:29 +0900

Hi Fernando,

Thanks. There was a bit of leap.

In support, for example, the argument that CRH is better because there is
no address semantic violation. These discussions are scattered and hard to
reference, but it's summarized here.

p.24-
https://pc.nanog.org/static/published/meetings/NANOG77/2080/20191029_Bonica_Srv6__v1.pdf

Miya

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2020 14:21:31 -0400

Several people, including at least one I-D, have asserted that there is 
some abstract requirement for compatibility with SRvc6's SRH.  There is 
no such requirement.  That is not a criterion the 6man group needs to 
consider.  In my personal opinion, it is not even a constraint on what 
SPRING chooses to do.

Yours,
Joel

On 5/28/2020 3:38 AM, Ran Pang(联通集团联通网络技术研究院本部) wrote:
> Hi WG,
> 
> It seems like CRH is not compatible with SRv6 and SRH. We need to 
> discuss how CRH cooperates with uSID, G-SRv6 or other SRv6 header 
> compression solutions before adoption, or whether CRH will cause 
> difficulties in the deployment of G-SRv6 and other solutions. At 
> present, we tend to choose solutions compatible with SRH.
> 
> 
> Thanks,
> 
> Ran
> 
> 
>     *From:* Bob Hinden <mailto:[email-masked]>
>     *Date:* 2020-05-16 06:13
>     *To:* IPv6 List <mailto:[email-masked]>
>     *CC:* Bob Hinden <mailto:[email-masked]>
>     draft.  As the working group document, the w.g. will decide how the
>     document should change going forward.
>     think it is appropriate to start a working group adoption call.  The
>     authors have been active in resolving issues raised on the list.
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 hqs- 
> [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送 
> 目录中删除。 If you have received this email in error please notify us 
> immediately by e-mail. Please reply to [email-masked] ,you can 
> unsubscribe from this mail. We will immediately remove your information 
> from send catalogue of our.
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 May 2020 11:32:28 -0700

> consider.  In my personal opinion, it is not even a constraint on what

Joel,

It's not even clear what compatibility with SRH means. The format of SRH is
very specific that SIDs are 128 bits, and the protocol has no sufficient
extensibility mechanism that allows that to change without breaking
backwards compatibility. As far as I can tell, changing or compressing SIDs
requires a new routing type regardless of the compression method or who
specifies it.

Tom

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 May 2020 12:54:37 -0700

Hi Tom,
you've noted that "The format of SRH is very specific that SIDs are 128
bits". True, that is the view, the current view based on the definition of
SRv6 and SRH in  RFCs 8402 and 8754. But both may be updated at some point.
Thus we can avoid the introduction of RH per SID length. Would you agree
that it is a viable option?

Regards,
Greg

On Thu, May 28, 2020 at 11:33 AM Tom Herbert <[email-masked]> wrote:

> It's not even clear what compatibility with SRH means. The format of SRH
> is very specific that SIDs are 128 bits, and the protocol has no sufficient
>> >     *From:* Bob Hinden <mailto:[email-masked]
>> <[email-masked]>>
>> >     *Date:* 2020-05-16 06:13
>> >     draft.  As the working group document, the w.g.. will decide how the

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 28 May 2020 19:56:17 +0000

People have asked about the OMNI and AERO drafts, and these are now updated

to show the application of Segment Routing in general and CRH in particular:

https://datatracker.ietf.org/doc/draft-templin-6man-omni-interface/

https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

The latter draft in particular cites CRH. The entire section on segment routing should

be of general interest, but below is the current section text on CRH:

Thanks - Fred

3.2.9.  Segment Routing Header Compression

   In the Segment Routing use cases discussed above, the segment routing
   headers must be kept to a minimum size since source and target
   Clients may be located behind low-end wireless links (e.g., 1Mbps or
   less).  The Compressed Routing Header (CRH)
   [I-D.bonica-6man-comp-rtg-hdr] provides a compact form that reduces
   the header size by omitting information that can already be derived
   by intermediate Bridges.  The CRH Helper
   option[I-D.bonica-6man-crh-helper-opt] can be used to encode the AERO
   Route Optimization TLV, and the final hop Bridge that performs route
   optimization may remove the CRH and its helper before encapsulating
   and forwarding to the target Client.

   The CRH and its companion helper option are therefore seen as
   critical architectural elements that should be quickly progressed
   through the standards process.  Implementations SHOULD use the CRH
   and its companion helper option instead of other Routing Header types

   whenever possible to conserve bandwidth.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 May 2020 13:14:12 -0700

On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Tom,
> you've noted that "The format of SRH is very specific that SIDs are 128 bits". True, that is the view, the current view based on the definition of SRv6 and SRH in  RFCs 8402 and 8754. But both may be updated at some point. Thus we can avoid the introduction of RH per SID length. Would you agree that it is a viable option?

Greg,

Unfortunately it's not an option. There is no field in SRH that could
robustly be used as a code point to indicate an alternate header
format or different length of SIDs. Neither is there any way to
retroactively add that this since RFC8754 is already out the door and
in deployment. This is analogous to someone wanting to create a
compressed version of the IPv6 header to use 64-bits instead of 128
bit addresses-- there is no way to do that without getting a new IP
version number. The difference in the analogy, is that the IP version
number space is only4 bits, but the routing type space is 8 bits. So
allocating new routing types for compressed SIDs really isn't much
issue since there are plenty of values available (247 routing type
values are unassigned whereas only 5 IP version numbers are
unassigned).

Tom

>> It's not even clear what compatibility with SRH means. The format of SRH is very specific that SIDs are 128 bits, and the protocol has no sufficient extensibility mechanism that allows that to change without breaking backwards compatibility. As far as I can tell, changing or compressing SIDs requires a new routing type regardless of the compression method or who specifies it.
>>
>> Tom
>>
>>>
>>> Yours,
>>> Joel
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 May 2020 13:23:38 -0700

Hi Tom,
I agree that "and ignored on receipt" in the definition of the Flags field
makes the future use of the field more restrictive. But I believe that can
be mitigated, as I've mentioned earlier, via control and/or management
plane extensions. Not that we have not faced a similar situation before and
dealt with the challenge in a reasonable way.

Regards,
Greg

On Thu, May 28, 2020 at 1:14 PM Tom Herbert <[email-masked]> wrote:

> >> It's not even clear what compatibility with SRH means. The format of
> SRH is very specific that SIDs are 128 bits, and the protocol has no
> sufficient extensibility mechanism that allows that to change without
> breaking backwards compatibility. As far as I can tell, changing or
> compressing SIDs requires a new routing type regardless of the compression
> method or who specifies it.
> >>
> >> Tom
> >>
> >>>
> >>> Yours,
> >>> Joel
> >>>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 May 2020 13:47:38 -0700

On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <[email-masked]> wrote:
>
> Hi Tom,
> I agree that "and ignored on receipt" in the definition of the Flags field makes the future use of the field more restrictive. But I believe that can be mitigated, as I've mentioned earlier, via control and/or management plane extensions. Not that we have not faced a similar situation before and dealt with the challenge in a reasonable way.

Or just create a new routing type that is universally unambiguous,
doesn't require external information just to understand the header
format, and carries not risk of breaking backwards compatibility. Like
Joel said, being compatible with SRH routing type for compressed SIDs
isn't a requirement and I can think of any reason why it should be. A
new routing type is also an opportunity to revisit all the fields in
the header, for instance we can reevaluate whether Flags, Tags, and
TLVs are really needed in a routing header.

Tom

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Thu, 28 May 2020 22:49:33 +0000

Hello 6man WG/chairs,
 
I do not support the WG adoption of this document.
 
In addition to numerous technical and other points made by others on the list already, I would like to highlight the tax this proposal puts on ASICs/hardware:
 
1) Additional mapping table and lookup:
Firstly, the CRH SID mapping requires an "additional" table for SID lookup. This incurs additional resources in hardware.
Secondly, in addition to original lookup on packet's DA, another lookup is needed in the above table, which will burn precious NPU cycles and impact performance (pps).

2) VPN Service's DOH header processing:
For CRH based solution, the VPN context is encoded in a Dest Opt header located after the CRH which adds the following challenges:
- At the egress PE, the packet arrives with both CRH and Dest Opt headers. The egress PE first needs to process the CRH to see whether SL = 0 and ignore the rest of it. 
- Then, it needs to process DoH and the options within it. This overall combination will be challenging for many ASICs.

Note that RFC6554 already defines a routing EH to perform compressed IPv6 source routing.
RFC6554 has the same compression/overhead as the CRH, and it does not rely on a mapping mechanism, and hence it does not suffer the challenges described above.
Hence, the authors should also document why their use-cases (which remain bit unclear at this point) cannot be achieved with RFC6554.

Rgds
--
Kamran

On 2020-05-15, 6:13 PM, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Bob and Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 May 2020 21:56:57 -0300

On 28/5/20 19:49, Kamran Raza (skraza) wrote:
[...]
> In addition to numerous technical and other points made by others on the list already, I would like to highlight the tax this proposal puts on ASICs/hardware:

It is interesting, because the PSP behaviour that Spring shipped in 
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15 
is apparently meant to deal with implementations that cannot even ignore 
a RH where SL==0, as required by RFC8200.

If anything, it would seem to me that shorter headers would make life 
easier when it comes to processing the headers.

> - Then, it needs to process DoH and the options within it. This overall combination will be challenging for many ASICs.

Welcome to the IPv6 world. If you can't handle this, you are not 
compliant with RFC8200.

As before, these comments are neither in favor nor against CRH, but 
rather against about bogus arguments.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Fri, 29 May 2020 02:29:34 +0000

I think it is a good idea to create a new routing type for encoding new type of SID in RH.

I also think that, as a result of IPv6 address has 16 bytes length, its space is big enough, lots of bits-string within it is redundant and unnecessary in some scenario. so considering the classic SRv6 scenario, we can only use least significance 64 bits within a fixed /64 prefix block for all SID assigning for limited domain being deployed by SRv6.
That means, only one same  /64 block is enough for all kind of SIDs assigning within limited domain, so only rightmost 64 bits representing all SIDs allocated to all prefix-SID and Adj-SIDs and Service-SIDs should be encoded within SRH with new routing type value. During packets being encapsulated with outer IPv6 and new RH forwarding through SRv6 domain, its left-most 64 bits of DA field keep intact and only right-most 64 bits will be replaced endpoint by endpoint from SRH.SL. 
The benefit:
- get half-reduced SRH length compared to classic SRv6 SRH under same number of SIDs encoded segment list;
- keep same forwarding plane with classic SRH processing; no extra processing for deducing compressed SID or normal SID coding in SRH; keeping the simple of forwarding plane is most important for all solution.
- only one /64 prefix as SID block, the complexity level of security deployment is largely reduced.
- the efforts of control plane protocol extension such as ISIS-srv6 or OSFP-srv6 have being made previously can be reserved. 
- no mapping mechanism at forwarding procedure and control plane.
- the solution is balance between SRH size and complexity of forwarding plane.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: 2020年5月29日 4:48
To: Greg Mirsky <[email-masked]>
Cc: IPv6 List <[email-masked]>; Ran Pang(联通集团联通网络技术研究院本部) <[email-masked]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

> I agree that "and ignored on receipt" in the definition of the Flags field makes the future use of the field more restrictive. But I believe that can be mitigated, as I've mentioned earlier, via co…

Or just create a new routing type that is universally unambiguous, doesn't require external information just to understand the header format, and carries not risk of breaking backwards compatibility. Like Joel said, being compatible with SRH routing type for compressed SIDs isn't a requirement and I can think of any reason why it should be. A new routing type is also an opportunity to revisit all the fields in the header, for instance we can reevaluate whether Flags, Tags, and TLVs are really needed in a routing header.

Tom

>> >>> Several people, including at least one I-D, have asserted that 
>> >>> there is some abstract requirement for compatibility with SRvc6's 
>> >>> SRH.  There is no such requirement.  That is not a criterion the 
>> >>> 6man group needs to consider.  In my personal opinion, it is not 
>> >>> even a constraint on what SPRING chooses to do.
>> >>
>> >>
>> >> Joel,
>> >>
>> >>> > It seems like CRH is not compatible with SRv6 and SRH. We need 
>> >>> > to discuss how CRH cooperates with uSID, G-SRv6 or other SRv6 
>> >>> > header compression solutions before adoption, or whether CRH 
>> >>> > will cause difficulties in the deployment of G-SRv6 and other 
>> >>> > solutions. At present, we tend to choose solutions compatible with SRH.
>> >>> >
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Ran
>> >>> >
>> >>> >
>> >>> > 目录中删除。 If you have received this email in error please notify 
>> >>> > us immediately by e-mail. Please reply to 
>> >>> > [email-masked] ,you can unsubscribe from this mail. We 
>> >>> > will immediately remove your information from send catalogue of our.
>> >>> >
>> >>> > ---------------------------------------------------------------
>> >>> > ----- IETF IPv6 working group mailing list [email-masked] 
>> >>> > Administrative Requests: 
>> >>> > https://www.ietf.org/mailman/listinfo/ipv6
>> >>> -----------------------------------------------------------------
>> >>> --- IETF IPv6 working group mailing list [email-masked] 
>> >>> Administrative Requests: 
>> >>> https://www.ietf.org/mailman/listinfo/ipv6
>> >> ------------------------------------------------------------------
>> >> -- IETF IPv6 working group mailing list [email-masked] 
>> >> Administrative Requests: 
>> >> https://www.ietf.org/mailman/listinfo/ipv6

---

From: "Swadesh Agrawal (swaagraw)" <[email-masked]>
Date: Fri, 29 May 2020 05:19:03 +0000

CRH purpose is to “compress” a segment list of a source-routed policy in IPv6 networks. However, many members of the SPRING working group have multiple solution for the specific purpose of minimizing the MTU overhead and/or supporting very long SID-lists on legacy hardware. As there are competing solutions in Spring, the basis for this work should be discussed in Spring wg, first.

Regards
Swadesh

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 29 May 2020 01:23:22 -0400

I believe a few variants of what you propose have been done with the SRV6
compression drafts.

Gyan

On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <
[email-masked]> wrote:

> I also think that, as a result of IPv6 address has 16 bytes length, its
> space is big enough, lots of bits-string within it is redundant and
> unnecessary in some scenario. so considering the classic SRv6 scenario, we
> can only use least significance 64 bits within a fixed /64 prefix block for
> all SID assigning for limited domain being deployed by SRv6.
> That means, only one same  /64 block is enough for all kind of SIDs
> assigning within limited domain, so only rightmost 64 bits representing all
> SIDs allocated to all prefix-SID and Adj-SIDs and Service-SIDs should be
> encoded within SRH with new routing type value. During packets being
> encapsulated with outer IPv6 and new RH forwarding through SRv6 domain, its
> left-most 64 bits of DA field keep intact and only right-most 64 bits will
> be replaced endpoint by endpoint from SRH.SL.
> The benefit:
> - keep same forwarding plane with classic SRH processing; no extra
> processing for deducing compressed SID or normal SID coding in SRH; keeping
> the simple of forwarding plane is most important for all solution.
> - the efforts of control plane protocol extension such as ISIS-srv6 or
> OSFP-srv6 have being made previously can be reserved.
> > I agree that "and ignored on receipt" in the definition of the Flags
> field makes the future use of the field more restrictive. But I believe
> that can be mitigated, as I've mentioned earlier, via control and/or
> management plane extensions. Not that we have not faced a similar situation
> before and dealt with the challenge in a reasonable way.
>
> Or just create a new routing type that is universally unambiguous, doesn't
> require external information just to understand the header format, and
> carries not risk of breaking backwards compatibility. Like Joel said, being
> compatible with SRH routing type for compressed SIDs isn't a requirement
> and I can think of any reason why it should be. A new routing type is also
> an opportunity to revisit all the fields in the header, for instance we can
> reevaluate whether Flags, Tags, and TLVs are really needed in a routing
> header.
>
> Tom
>
> >
> > Regards,
> > Greg
> >
> >> > you've noted that "The format of SRH is very specific that SIDs are
> 128 bits". True, that is the view, the current view based on the definition
> of SRv6 and SRH in  RFCs 8402 and 8754. But both may be updated at some
> point. Thus we can avoid the introduction of RH per SID length. Would you
> agree that it is a viable option?
> >>
> >> Greg,
> >>
> call.  The
> >> >>> > -----
> >> >>> ---
-- 

*Gyan Mishra*

---

From: 이기훈/책임 <[email-masked]>
Date: Fri, 29 May 2020 14:44:44 +0900 (KST)

I fully agree Gyan and I would like the discussion to be prioritized through SPRRING WG. 

KH

------------------- Original Message -------------------From    :  "Gyan Mishra" ([email-masked])To      :  "Wang, Weibin (NSB - CN/Shanghai)" ([email-masked])Cc      :  "IPv6 List" ([email-masked])
        "Ran Pang(联通集团联通网络技术研究院本部)" ([email-masked])
Date    :  2020/05/29 금요일 오후 2:23:22Subject :  Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I believe a few variants of what you propose have been done with the SRV6 compression drafts.
Gyan
On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <<a href="mailto:[email-masked]">[email-masked] wrote:
I think it is a good idea to create a new routing type for encoding new type of SID in RH.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <<a href="mailto:[email-masked]" target="_blank">[email-masked] On Behalf Of Tom Herbert
Sent: 2020年5月29日 4:48
To: Greg Mirsky <<a href="mailto:[email-masked]" target="_blank">[email-masked]
Cc: IPv6 List <<a href="mailto:[email-masked]" target="_blank">[email-masked]; Ran Pang(联通集团联通网络技术研究院本部) <<a href="mailto:[email-masked]" target="_blank">[email-masked]
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <<a href="mailto:[email-masked]" target="_blank">[email-masked] On Thu, May 28, 2020 at 1:14 PM Tom Herbert <<a href="mailto:[email-masked]" target="_blank">[email-masked] On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <<a href="mailto:[email-masked]" target="_blank">[email-masked] On Thu, May 28, 2020 at 11:33 AM Tom Herbert <<a href="mailto:[email-masked]" target="_blank">[email-masked] On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <<a href="mailto:[email-masked]" target="_blank">[email-masked]     *From:* Bob Hinden <mailto:<a href="mailto:[email-masked]" target="_blank">bob.hinden@gmail..com     *To:* IPv6 List <mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]     *CC:* Bob Hinden <mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr <a href="mailto:spmc@chinaunicom
 .cn" target="_blank">[email-masked] <a href="mailto:[email-masked]" target="_blank">[email-masked] ----- IETF IPv6 working group mailing list <a href="mailto:[email-masked]" target="_blank">[email-masked] https://www.ietf.org/mailman/listinfo/ipv6 --- IETF IPv6 working group mailing list <a href="mailto:[email-masked]" target="_blank">[email-masked] https://www.ietf.org/mailman/listinfo/ipv6 -- IETF IPv6 working group mailing list <a href="mailto:[email-masked]" target="_blank">[email-masked] https://www.ietf.org/mailman/listinfo/ipv6 --

--------------------------------------------------------------------
IETF IPv6 working group mailing list
<a href="mailto:[email-masked]" target="_blank">[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
<a href="mailto:[email-masked]" target="_blank">[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-- 

Gyan MishraNetwork Solutions Architect M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 29 May 2020 06:13:47 +0000

Yes, agree with that. Personally, I think most of the issues will be addressed if we start from SPRING.

Thanks,
Cheng

From: ipv6 [mailto:[email-masked]] On Behalf Of ???/??
Sent: Friday, May 29, 2020 1:45 PM
To: Wang Weibin (NSB - CN/Shanghai) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: IPv6 List <[email-masked]>; Ran Pang(联通集团联通网络技术研究院本部) <[email-masked]>
Subject: Re: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

KH

------------------- Original Message -------------------

From : "Gyan Mishra" (hayabu sagsm@gm ail.com)

To : "Wang, Weibin (NSB - CN/Shanghai)" ([email-masked]<mailto:[email-masked]>)

Cc : "IPv6 List" ([email-masked]<mailto:[email-masked]>)
        "Ran Pang(联通集团联通网络技术研究院本部)" ([email-masked]<mailto:[email-masked]>)

Date : 2020/05/29 금요일 오후 2:23:22

Subject : Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

I believe a few variants of what you propose have been done with the SRV6 compression d rafts.

Gyan

On Thu, May 28, 2020 at 10:30 PM Wang, Weibin (NSB - CN/Shanghai) <[email-masked]<mailto:[email-masked]>> wrote:
I think it is a good idea to create a new routing type for encoding new type of SID in RH.

I also think that, as a result of IPv6 address has 16 bytes length, its space is big enough, lots of bits-string within it is redundant and unnecessary in some scenario. so considering the classic SRv6 scenario, we can only use least significance 64 bits within a fixed /64 prefix block for all SID assigning for limited domain being deployed by SRv6.
That means, only one same  /64 block is enough for all kind of SIDs assigning within limited domain, so only rightmost 64 bits representing all SIDs allocated to all prefix-SID and Adj-SIDs and Service-SIDs should be encoded within SRH with new routing type value. During packets being encapsulated with outer IPv6 and new RH forwarding through SRv6 domain, its left-most 64 bits of DA field keep intact and only right-most 64 bits will be replaced endpoint by endpoint from SRH.SL<http://SRH.SL>.
The benefit:
- get half-reduced SRH length compared to classic SRv6 SRH under same number of SIDs encoded segment list;
- keep same forwarding plane with classic SRH processing; no extra processing for deducing compressed SID or normal SID coding in SRH; keeping the simple of forwarding plane is most important for all solution.
- only one /64 prefix as SID block, the complexity level of security deployment is largely reduced.
- the efforts of control plane protocol extension such as ISIS-srv 6 or OSF P-srv6 have being made previously can be reserved.
- no mapping mechanism at forwarding procedure and control plane.
- the solution is balance between SRH size and complexity of forwarding plane.

Cheers!

Wang Weibin

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Tom Herbert
Sent: 2020年5月29日 4:48
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 List <[email-masked]<mailto:[email-masked]>>; Ran Pang(联通集团联通网络技术研究院本部) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Tom

>
> Regards,
> Greg
>
> On Thu, May 28, 2020 at 1:14 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On Thu, May 28, 2020 at 12:54 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
>> >
>> > Hi Tom,
>> retroactively add that t his sinc e RFC8754 is already out the door and
>> > On Thu, May 28, 2020 at 11:33 AM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>> >>
>> >>
>> >>
>> >> On Thu, May 28, 2020, 11:22 AM Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
>> >>>
>> >> It's not even clear what compatibility with SRH means.. The format of SRH is very specific that SIDs are 128 bits, and the protocol has no sufficient extensibility mechanism that allows that to chang e withou t breaking backwards compatibility. As far as I can tell, changing or compressing SIDs requires a new routing type regardless of the compression method or who specifies it.
>> >>
>> >> Tom
>> >>
>> >>>
>> >>> Yours,
>> >>> Joel
>> >>>
>> >>> > solutions. At present, we tend to choose solutions compati ble with SRH.
>> >>> >
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > Ran
>> >>> >
>> >>> >
>> >>> >     *From:* Bob Hinden <mailto:bob.hinden@gmail..com<mailto:[email-masked]>>
>> >>> >     *Date:* 2020-05-16 06:13
>> >>> >     *To:* IPv6 List <mailto:[email-masked]<mailto:[email-masked]>>
>> >>> >     *CC:* Bob Hinden <mailto:[email-masked]<mailto:[email-masked]>>
>> >>> >     This message starts a two-week 6MAN call on adopting :
> ;> >>> >     Title:          The IPv6 Compact Routing Header (CRH)
>> >>> >     https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr<https://tools.ietf..org/html/draft-bonica-6man-comp-rtg-hdr>
>> >>> >     authors have been active in resolving issues raised on th e list.< br>>> >>> >     Could those who are willing to work on this document, either as
>> >>> > [email-masked]<mailto:[email-masked]>，即可以退订此邮件。我们将立即将您的信息从我们的发送
>> >>> > 目录中删除。 If you have received this email in error please notify >&g t; >>> > us immediately by e-mail. Please reply to
>> >>> > [email-masked]<mailto:[email-masked]> ,you can unsubscribe from this mail. We
>> >>> > ----- IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]>
>> >>> > Administrative Requests:
>> >>> --- IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]>
>> >>> Administrative Requests:
>> >> -- IETF IPv6 working group mailing list [email-masked]<mailto:[email-masked]>
>> >> Administrative Requests:
>> >> ; ------------------------------------------------------------------
>> >> --

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 29 May 2020 09:17:31 +0000

Hi 6man,

Since the first day CRH is proposed, it reminds me that we may need to address the overhead problem of SRv6 when SID list is long, that is great, thanks to Ron and others. 

But personally, I hope the solution should be compatible with SRv6 and SRH, which will simplify the issue and save a lot of works and time. Unfortunately, CRH is not. 
Truly, some people may jump up to say there is no requirement to be compatible with SRv6. I respect them and their POVs, but I also respect my POV. 
I do not hope the IETF to spend a lot of time to build a brand new data plane and control plane, while some compatible solutions are there[1]. But people are free to develop a tech like that if they want.

However, the development roadmap of CRH really shocked me. 
	* At the beginning, SRv6+ was proposed, the data plane is CRH
	* them it became SRm6, the data plane is CRH.
	* SRm6 requested to be adopted in SPRING, and get the answer "too early". 
	* In Feb, 2020, CRH removed the normative reference to SRm6, and stated to be replacement of RH0. In this way, CRH was stated to have no dependency on SRm6, while the data plane of SRm6 is CRH[2]. Amazing! 
                * In May 5th,  CRH asked for WG adoption in 6man, and get "Too early" again.
	* RH0 was removed after discussion in ML, and CRH get another base on general purpose of RH.
	* And several days later, a WG adoption poll is issued. Amazing+! 

Right now, I do not know where the requirements of CRH come from, and how CRH can get here.
At the beginning, the requirements of CRH may be:
      * Challenges from overhead of SRv6 when SID list is long( SID >5 )
      * IPv6 address needs to be ONLY the address of interface.
Regarding SRv6 overhead,
* If CRH aims to solve the SRv6 compression, there are some competing solutions there. They are starting from the requirement[3], architecture, but why CRH can jump to data plane adoption?
* If CRH does not aim to solve the SRv6 overhead, then what? It should be stated clear. And the work should follow the IETF progress of requirements-> use case->architecture->solution. The rules should be respected. 
But I may be wrong, hidden rules may be somewhere that I don't know.

Personally, I don't think the progress of CRH is a good case of progressing a work in IETF for young generation. Other people may follow the same direction to do something else again, and again.
Regarding IPv6 address, we have a lot of discussion on this. Will not repeat.

>From the technology aspects, I do spend a lot of time to read the documents of SRm6, not only CRH, but including the CP extensions, VPN and SFC extensions, etc.
I may be wrong, but I think CRH is not that simple as some people stated.

First of all, the below is my understanding of SRv6 and CRH based SRm6, again, I may be wrong.
* SRv6 uses one ID(128 bits address) to present
	* forwarding ID: 128 bits address
	* routing ID: 128 bits address
	* service ID: 128 bits address
* SRm6 use three IDs to present
	* forwarding ID: 128 bits address
	* routing ID:16/32 bits tag/CRID/?
	* service ID: option TLV in DOH
Then
* When comparing TE Steering, SRv6 END/END.X is really simple, CRH I think it is the similar or the same. I don't see any more simplicities than SRH based SRv6.
* When a service instruction is added, SRv6 introduces a new ID value without introducing any new data plane encapsulation modifications. CRH based SRv6 introduce an option TLV in DOH with new data plane encapsulation modifications. I think adding an ID is simpler than a TLV, and more hardware friendly.
* When supporting SFC, SRv6 introduces some IDs, that is all, without new data plane encapsulation modifications. CRH does not support. CRH based SRm6 may support by using Options TLV in the first DOH[4] or NSH.
	* Option TLV in First DOH: The option in first DOH should apply to all the Segment endpoint. If configure different behavior to a same Option TLV, then the Option ID is like a Service Path ID, and per-flow/per SFC states are introduced back to all the nodes. SRm6 is still a source routing paradigm?
	* NSH:  too complicated to combination, per-flow/per-SFC states need to be maintained on all the nodes along the path.
* When supporting VPN, SRv6 introduces a new ID, without new data plane encapsulation modifications. SRm6 introduces a new TLV in DOH.
* When supporting FRR, I don't see the solution of CRH yet.
* When supporting OAM, do we need solution to support mapping table debugging? No idea.
* No reserved bits in CRH, I do not think the 32 bits are critical for hardware processing, but extensibilities are needed in almost protocol design. Less overhead does not mean best. I think this is a drawback of CRH instead of a advantage. But I may be wrong.
* In SRv6 or SR-MPLS, a SID is allocated by the node and processed by the node. Like an Adj SID in SR-MPLS and SRv6, the Adj Label and END.X SID are the value allocated by a node, and the forwarding ID is also ended at that node. But in CRH, the SID is allocated by the node, while the forwarding ID is allocated by the next segment endpoint, which is the interface address allocated by the next segment endpoint node, it looks very strange to me. But I may be wrong again!
* Flag, Tag, Last Entry provide more programmability to operators to support various services, they are features not overhead. Again, extensibilities is required and very important for a basic solution like a RH. Even for RH3 [5] in IOT. 
* SRH TLV works like the DOH TLVs, so I think this is a alterative solution. But SID is the best option to specify a specific behavior on a specific node, rather than Option TLV with local configurations or container TLV design.
 
Therefore, I really do not see the simplicity brought by CRH when CRH is used for supporting services.
It has the simplicity as SRH in TE. But has more complexities when supporting other services. 
I prefer to comparing solutions in a service solution level instead of a peace of the whole solution, no meaning to me.

Base on the above analysis, personally I don't think right now is the timing to adopt this document, so I do not support the adoption. 

Respect!
Cheng

[1]. https://tools.ietf.org/html/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01
[2]. https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-6
[3]. https://tools.ietf.org/html/draft-cheng-spring-shorter-srv6-sid-requirement-01
[4]. https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-07#section-3
[5]. https://tools.ietf.org/html/rfc6554#section-3

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Saturday, May 16, 2020 6:14 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Regards,
Bob and Ole

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 29 May 2020 13:51:18 -0400

Hi WG, Chairs,

I do not support WG adoption of this document.

I agree with Cheng. Work should first start with SPRING WG with an analysis
of the available options.

Thanks

Rakesh

On Fri, May 29, 2020 at 2:14 AM Chengli (Cheng Li) <[email-masked]> wrote:

> *From:* ipv6 [mailto:[email-masked]] *On Behalf Of *???/??
> *Sent:* Friday, May 29, 2020 1:45 PM
> *To:* Wang Weibin (NSB - CN/Shanghai) <[email-masked]>; Gyan
> Mishra <[email-masked]>
> *Cc:* IPv6 List <[email-masked]>; Ran Pang(联通集团联通网络技术研究院本部) <
> [email-masked]>
> *Subject:* Re: Re: Adoption Call for "The IPv6 Compact Routing Header
> (CRH)"
>
>
>
>
>
> *From : *"Gyan Mishra" (hayabu sagsm@gm ail.com)
>
> *To : *"Wang, Weibin (NSB - CN/Shanghai)" ([email-masked])
>
> *Cc : *"IPv6 List" ([email-masked])
> *Date : *2020/05/29 금요일 오후 2:23:22
>
> *Subject : *Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"
>
>
>
> compression d rafts.
> - the efforts of control plane protocol extension such as ISIS-srv 6 or
> OSF P-srv6 have being made previously can be reserved.
> On Thu, May 28, 2020 at 1:23 PM Greg Mirsky <[email-masked] > wro
> te:
> >
> > Hi Tom,
> >> >> It's not even clear what compatibility with SRH means.. The format
> of SRH is very specific that SIDs are 128 bits, and the protocol has no
> sufficient extensibility mechanism that allows that to chang e withou t
> >> >>> >     *From:* Bob Hinden <mailto:bob.hinden@gmail..com
> <[email-masked]>>
> >> >>> >     *Date:* 2020-05-16 06:13
> <https://tools.ietf..org/html/draft-bonica-6man-comp-rtg-hdr>
> >> >>> >     authors have been active in resolving issues raised on th e
> list.< br>>> >>> >     Could those who are willing to work on this
> document, either as

---

From: 神明達哉 <[email-masked]>
Date: Fri, 29 May 2020 11:27:37 -0700

At Fri, 15 May 2020 15:13:55 -0700,

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

I have no strong opinion on the adoption, while I didn't see any
particular reason not for adopting it in the sense of moving the
editorial ownership from individual authors to the wg: the topic seems
relevant to this wg; it's generally well written and seems to be ready
for further detailed discussion without wasting others' time for,
e.g., just to understand the draft text.  I don't know what else is
needed for adoption, but my understanding of the bar for adoption
isn't that high and this draft seems to clear it.

I've read draft-bonica-6man-comp-rtg-hdr-22 (not 21), mostly out of
curiosity.  I'm not an expert in this technology area or am not
particularly interested in it, but as email messages about the draft
and this adoption call consumed 99% of my inbox this week (most of
which seemed mere noise to me and I simply archived them without
reading) I was curious about what was happening.  Here are some
comments about that version from such a novice observer (please also
forgive me if I'm repeating points already made by someone - as I said
I've lazily ignored most of the messages regarding this call):

- General
  In general, I'd like to understand "why we need this" for any new
  protocol.  The motivation described in Section 1 is somewhat
  understandable, but if one major purpose is to realize source
  routing "within a network domain", it would be natural to ask why
  SRv6 isn't enough (I'd also refer to Section 3.2 of RFC1958).
  Perhaps there's a specific reason for the author not to discuss it
  within the draft (to avoid distraction?), but for someone without
  all background details that would be really useful.  For example, if
  CRH is intended to implement a 'source routing within a network
  domain' while being more compatible with the basic IPv6 protocol (like not
  relying on insertion or deletion of the CRH in intermediate nodes)
  that would make it look more persuading to someone like me, who is
  more concerned about the protocols affected by the new proposal than
  the new protocol itself.  But such points aren't discussed
  explicitly or can't be figured out (to me) from the protocol
  description.

- Section 1

   o  Is designed to operate within a network domain.  (See Section 9).

The term "a network domain" is vague to me.  Can't it be more
specific?

- Section 1

   o  Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely
      reliable, many IPv6 hosts refrain from sending packets larger than
      the IPv6 minimum link MTU (i.e., 1280 bytes).

Is this true?  I thought TCP (over IPv6) applications still largely
use larger packets (implicitly relying on PMTUD) while it's probably
pretty common for UDP applications to limit their packets to the
minimum MTU size.

- Section 5

   o  Submit the packet and optional parameters to the IPv6 module.

I can guess what "IPv6 module" means, but it would be more helpful if
it's defined explicitly earlier in the draft (maybe it could have a
"Terminology" section).

- Section 9

I suspect anyone remembering the type 0 RH fiasco will wonder whether
CRH is safe in that sense.  So I'd suggest discussing that more
explicitly with referring to RFC5095.

--
JINMEI, Tatuya

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Fri, 29 May 2020 18:54:55 +0000

Hi,

I have read the draft and went through the many emails on the mailing list. 

At this stage, it remains unclear to me which problem this draft addresses, and why existing solutions are not suitable. I realize that this point has been raised multiple times already, and I appreciate the efforts made by the authors to describe their use-cases on the list. However, it still seems to me that we can easily address these use-cases using existing technology.

- Mapping-based traffic steering over a plain IPv6 network is what is proposed in RFC 8663
- Steering of control packets without encapsulation can be done using RFC 8754 (see section 3.1)
- IPv6 Segment Routing with small header size can also be done with RFC 8754, by simply using one of the “compression” techniques that have been proposed in SPRING. For example, draft-filsfilscheng-spring-srv6-srh-comp-sl-enc, which leverages RFC 8754 without any new flag or field modification.

I like working on new technologies, but I find it difficult to work on something without a clear view of the problem to be solved.

For this reason, I do not support the adoption of draft-bonica-6man-comp-rtg-hdr at this time.

Regards,
Francois

On 16/05/2020 00:14, "ipv6 on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Regards,
    Bob and Ole

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 May 2020 12:39:47 -0700

> But personally, I hope the solution should be compatible with SRv6 and SRH, which will simplify the issue and save a lot of works and time. Unfortunately, CRH is not.

Cheng,

I don't see how any solution for compressed SIDs can be compatible
with SRH without employing a new routing type . Consider that one
litmus test of compatibility is what happens when a legacy
implementation receives a packet with the new protocol. To be
compatible, the receiver must recognize that the protocol is unknown
to it and not attempt to process it. If the receiver doesn't do that
and processes the protocol anyway, then the results are
non-deterministic and can actaully lead to harmful or insercure
behavior (in other words it's not robust).

So if legacy receiver receives a SRH header that contains compressed
SIDs that are less than 128 bits, it cannot correctly process the
packet. Someone might argue that this could be a configuration option
or SID length could be a negotiated parameter, that doesn't work since
RFC8754 has no provision for negotiating or configuring an alternate
SID length or format. RFC8754 is very clear on SID length and the fact
they are IPv6 addresses. From the draft: "Segment List[0..n]:  128-bit
IPv6 addresses representing the nth segment in the Segment List.". So
128 bit SIDs are an invariant propery of the SRH routing type. The
only way to change the SID length and be compatilble with SRH is to
use a new routing type, which means that CRH _is_ compatible with SRH
(an SRH receiver that receives a CRH RH won't attempt to process it).

Tom

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 May 2020 13:32:42 -0700

This email concludes the adoption call on "The IPv6 Compact Routing Header (CRH)”.

There have been requests to contact the Routing ADs on this topic, this has been started via our Internet ADs.

The chairs and ADs will spend the next few weeks reviewing the responses and make a decision on adoption.

This has been a very heated discussion with several instances of non-constructive behaviour.   Please exercise restraint on future posts.  We note that it doesn’t help to repeat the same thing multiple times or respond to every email.

Bob & Ole

> On May 15, 2020, at 3:13 PM, Bob Hinden <[email-masked]> wrote:
>

---

From: Dirk Steinberg <[email-masked]>
Date: Fri, 29 May 2020 23:42:00 +0300

Hello,

looking at the draft what I see is a new data plane (incompatible with
anything else
that has existed as far) that semantically does the same what MPLS has been
doing for over 20 years: mapping a fixed-length label to some kind of
rewrite information.

While having a different encapsulation format it is semantically equivalent
to MPLS
and it also retains the biggest drawback of MPLS: being based on a mapping
table.
This implies that the mapping table needs to be disseminated (read:
protocol changes
in all protocols) while still not allowing aggregation and also not
providing any advantage
from an architectural point of view over existing solutions.

The fact that this encapsulation is IPv6-based is nothing new at all.
The equivalent semantics can be achieved using MPLS over UDP
that is already described in RFC 8663.

I fail to see any significant innovation that would justify the effort of
introducing a
new encapsulation and introducing changes to all routing protocols.

Therefore I do not support the adoption of draft-bonica-6man-comp-rtg-hdr
at present.

Cheers,
Dirk

On Thu, May 21, 2020 at 4:56 PM Ketan Talaulikar (ketant) <ketant=
[email-masked]> wrote:

> Hello Spring WG,
>
> You might be very interested in this ongoing WG adoption poll for the CRH
> proposal (what was previously introduced in Spring as part of the SRm6
> proposal).
>
> The authors are now claiming that theirs is a new IPv6 source routing
> proposal that is unrelated to work/charter of Spring WG and not Segment
> Routing [1] & [2].
>
> However, following the conversations in 6man, it seems clear to me that
> this is indeed a new IPv6 data-plane proposal that builds on Spring work
> [RFC8402] but avoids attribution to it to give an illusion of it being a
> new standalone IPv6 Source Routing solution.
>
> If you were looking for a document that describes the architecture,
> applicability, use-cases or requirements for this "new solution", well
> there isn't anything other than the CRH draft itself [4] (the new version
> does not talk about SRm6 anymore).
>
> [1]
> https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/
> [2]
> https://mailarchive.ietf.org/arch/msg/ipv6/acyQ6VoObjnUVk6oOz7RoVLNey8/
> [3]
> https://mailarchive.ietf.org/arch/msg/ipv6/BMoJM1NfneU5o0KRKUCkCj96g8c/
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 29 May 2020 20:52:57 +0000

Hi Bob and the WG:

I do not support adoption of CRH as a WG document at this time.
I have raised reasons for objection in my earlier emails, including [1].

[1] https://mailarchive.ietf.org/arch/msg/ipv6/BeVoHakLA50vvHy-Y0E6rnThCp0/

Thanks

Regards … Zafar

Date: Friday, May 15, 2020 at 6:13 PM

Regards,
Bob and Ole

---

From: James Guichard <[email-masked]>
Date: Fri, 29 May 2020 21:31:07 +0000

Hi Tom,

If you look at https://www.ietf.org/id/draft-cl-spring-generalized-srv6-for-cmpr-01.txt section 7 it says:

      *  No control plane modification: Controller can install the SR
         policy with 128-bits G-SID Containers, and the ingress treats
         the G-SID Container as an opaque 128-bits SID without
         understanding the structure of it.  G-SRv6 capable nodes
         understand the COC flavor behaviors, while Compression disable
         SRv6 nodes are unaware of Compression.

Given this then I would say that the assumption is a non-compression capable node should not be selected as a segment within the G-SID container and therefore should never have to process a compressed SID within a received G-SRH. Of course, a non-compression capable node could still be part of the G-SRH as long as the segment it must process is of non-COC behavior. 

Jim 

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
Sent: Friday, May 29, 2020 3:40 PM
To: Chengli (Cheng Li) <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Cheng,

I don't see how any solution for compressed SIDs can be compatible with SRH without employing a new routing type . Consider that one litmus test of compatibility is what happens when a legacy implementation receives a packet with the new protocol. To be compatible, the receiver must recognize that the protocol is unknown to it and not attempt to process it. If the receiver doesn't do that and processes the protocol anyway, then the results are non-deterministic and can actaully lead to harmful or insercure behavior (in other words it's not robust).

So if legacy receiver receives a SRH header that contains compressed SIDs that are less than 128 bits, it cannot correctly process the packet. Someone might argue that this could be a configuration option or SID length could be a negotiated parameter, that doesn't work since
RFC8754 has no provision for negotiating or configuring an alternate SID length or format. RFC8754 is very clear on SID length and the fact they are IPv6 addresses. From the draft: "Segment List[0..n]:  128-bit
IPv6 addresses representing the nth segment in the Segment List.". So
128 bit SIDs are an invariant propery of the SRH routing type. The only way to change the SID length and be compatilble with SRH is to use a new routing type, which means that CRH _is_ compatible with SRH (an SRH receiver that receives a CRH RH won't attempt to process it).

Tom

>         * service ID: option TLV in DOH Then
> [1]. 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01
> &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a5404
> 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372637
> 80261923845&amp;sdata=DA4SX0kvjslMv48d6JBGbWk5rwY%2BGowA64MasmY6RSs%3D
> &amp;reserved=0 [2]. 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-bonica-spring-sr-mapped-six-01%23section-6&a
> mp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a54041c
> 00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780
> 261923845&amp;sdata=9JDUZkDB9Wv8ahQ%2FSXzXnrMBJ33gArtla%2F6WbSYD09M%3D
> &amp;reserved=0 [3]. 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-cheng-spring-shorter-srv6-sid-requirement-01
> &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a5404
> 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372637
> 80261923845&amp;sdata=DErYZazF4CUGR096chaqMHzNNp6Zhk15jSFB%2FOBPoFw%3D
> &amp;reserved=0 [4]. 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-bonica-6man-seg-end-opt-07%23section-3&amp;d
> ata=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a54041c0090
> 8d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6372637802619
> 23845&amp;sdata=lHiNW7wz%2Ffk0%2FWZ2cxs0Ahyp0f1%2BZ9tjjcsKUKz3J5g%3D&a
> mp;reserved=0 [5]. 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Frfc6554%23section-3&amp;data=02%7C01%7Cjames.n.gui
> chard%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff2a3b
> 240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=trRPntkM5
> wNWfkgjNcY9hzwOajlM%2Feu%2F%2FAh3sr8ii0I%3D&amp;reserved=0
>
>
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr&amp;data=02%7C01%7C
> james.n.guichard%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdat
> a=uney8BmhjqknfjS%2FNEu1kpJFIUDM7RFniOO%2BT6n%2Ftvg%3D&amp;reserved=0
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.guicha
> rd%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=UyBGPL0ehGhH
> 8Vr0DmFSo0nVZfHU22WmKxso60KXKRI%3D&amp;reserved=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=UyBGPL0ehGhH8Vr0DmFSo0nVZfHU22WmKxso60KXKRI%3D&amp;reserved=0
--------------------------------------------------------------------

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 May 2020 14:37:31 -0700

Hi Tom,
may I use this thread to continue our discussion on whether a shorter SID
can be used in SRH in a backward-compatible manner?
SRv6 and SRH, by itself, require IGP extensions to advertise such new
capability because an IPv6 node that does not support SRH will not be
selected as SRv6 segment end-point. The LSR WG has adopted two drafts that
define IGP extensions for SRv6 (IS-IS
<https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/> and
OSPFv3
<https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/>).
Both proposals define the SRv6 Capabilities sub-TLV that includes the two
octets-long Flags field. One bit already has been assigned to indicate the
support of O-bit. I can envision that a document defining a shorter SID in
SRH will also define the use of SRv6 Capabilities sub-TLV, perhaps by
allocating a new field in the Flags. Hence, I agree with Cheng Li that a
requirement for a shorter SID solution to use SRH is reasonable and can be
easily conformed to.

On Fri, May 29, 2020 at 12:40 PM Tom Herbert <[email-masked]> wrote:

> > Since the first day CRH is proposed, it reminds me that we may need to
> address the overhead problem of SRv6 when SID list is long, that is great,
> thanks to Ron and others.
> >
> > But personally, I hope the solution should be compatible with SRv6 and
> SRH, which will simplify the issue and save a lot of works and time.
> Unfortunately, CRH is not.
>
> Cheng,
>
> > Truly, some people may jump up to say there is no requirement to be
> compatible with SRv6. I respect them and their POVs, but I also respect my
> POV.
> > I do not hope the IETF to spend a lot of time to build a brand new data
> plane and control plane, while some compatible solutions are there[1]. But
> people are free to develop a tech like that if they want.
> >
> >         * In Feb, 2020, CRH removed the normative reference to SRm6, and
> stated to be replacement of RH0. In this way, CRH was stated to have no
> dependency on SRm6, while the data plane of SRm6 is CRH[2]. Amazing!
> > * If CRH aims to solve the SRv6 compression, there are some competing
> solutions there. They are starting from the requirement[3], architecture,
> but why CRH can jump to data plane adoption?
> > * If CRH does not aim to solve the SRv6 overhead, then what? It should
> be stated clear. And the work should follow the IETF progress of
> requirements-> use case->architecture->solution. The rules should be
> respected.
> > Personally, I don't think the progress of CRH is a good case of
> progressing a work in IETF for young generation. Other people may follow
> the same direction to do something else again, and again.
> > >From the technology aspects, I do spend a lot of time to read the
> documents of SRm6, not only CRH, but including the CP extensions, VPN and
> SFC extensions, etc.
> > * When comparing TE Steering, SRv6 END/END.X is really simple, CRH I
> think it is the similar or the same. I don't see any more simplicities than
> SRH based SRv6.
> > * When a service instruction is added, SRv6 introduces a new ID value
> without introducing any new data plane encapsulation modifications. CRH
> based SRv6 introduce an option TLV in DOH with new data plane encapsulation
> modifications. I think adding an ID is simpler than a TLV, and more
> hardware friendly.
> > * When supporting SFC, SRv6 introduces some IDs, that is all, without
> new data plane encapsulation modifications. CRH does not support. CRH based
> SRm6 may support by using Options TLV in the first DOH[4] or NSH.
> >         * Option TLV in First DOH: The option in first DOH should apply
> to all the Segment endpoint. If configure different behavior to a same
> Option TLV, then the Option ID is like a Service Path ID, and per-flow/per
> SFC states are introduced back to all the nodes. SRm6 is still a source
> routing paradigm?
> >         * NSH:  too complicated to combination, per-flow/per-SFC states
> need to be maintained on all the nodes along the path.
> > * When supporting VPN, SRv6 introduces a new ID, without new data plane
> encapsulation modifications. SRm6 introduces a new TLV in DOH.
> > * No reserved bits in CRH, I do not think the 32 bits are critical for
> hardware processing, but extensibilities are needed in almost protocol
> design. Less overhead does not mean best. I think this is a drawback of CRH
> instead of a advantage. But I may be wrong.
> > * In SRv6 or SR-MPLS, a SID is allocated by the node and processed by
> the node. Like an Adj SID in SR-MPLS and SRv6, the Adj Label and END.X SID
> are the value allocated by a node, and the forwarding ID is also ended at
> that node. But in CRH, the SID is allocated by the node, while the
> forwarding ID is allocated by the next segment endpoint, which is the
> interface address allocated by the next segment endpoint node, it looks
> very strange to me. But I may be wrong again!
> > * Flag, Tag, Last Entry provide more programmability to operators to
> support various services, they are features not overhead. Again,
> extensibilities is required and very important for a basic solution like a
> RH. Even for RH3 [5] in IOT.
> > * SRH TLV works like the DOH TLVs, so I think this is a alterative
> solution. But SID is the best option to specify a specific behavior on a
> specific node, rather than Option TLV with local configurations or
> container TLV design.
> >
> > I prefer to comparing solutions in a service solution level instead of a
> peace of the whole solution, no meaning to me.
> >
> > Base on the above analysis, personally I don't think right now is the
> timing to adopt this document, so I do not support the adoption.
> >
> > Respect!
> > Cheng
> >
> >
> > [1].
> https://tools.ietf.org/html/draft-filsfilscheng-spring-srv6-srh-comp-sl-enc-01
> > [2].
> https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-6
> > [3].
> https://tools.ietf.org/html/draft-cheng-spring-shorter-srv6-sid-requirement-01
> > [4].
> https://tools.ietf.org/html/draft-bonica-6man-seg-end-opt-07#section-3

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 May 2020 14:52:49 -0700

> Given this then I would say that the assumption is a non-compression capable node should not be selected as a segment within the G-SID container and therefore should never have to process a compres…

Jim,

That would have to be more than an assumption, it would need to be a
normative requirement like "a non-compression capable node MUST NOT be
selected as a segment within the G-SID container". But then the
question is how does the sender know which nodes are compression
capable and which are non-compression capable"-- there is no concept
of this distinction in RFC8754, so that information needs to come from
an external source of the protocol definition, ie. configuration or
negotiation. So that would mean that basic correctness of SRH protocol
processing becomes dependent on the control plane.

Tom

---

From: James Guichard <[email-masked]>
Date: Fri, 29 May 2020 22:13:17 +0000

Hi Tom,

I think section 8.2 answers this:

8.2.  Control Plane

   REQ1-11: ISIS/OSPF/BGP-LS/PCEP extensions for advertising the
   capabilities of supporting G-SRv6 for SRv6 compression.

So (1) a node has to indicate through capabilities advertisement that it is G-SRv6 compression capable, and (2) it must advertise a SID with "Continue of Compression (COC) behavior so that if it receives a packet using that SID then it knows to take 32-bits from the G-SID container rather than 128-bits (there is also an index carried as args for the SID so it knows where in the container the next C-SID can be found).

Jim

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, May 29, 2020 5:53 PM
To: James Guichard <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

On Fri, May 29, 2020 at 2:31 PM James Guichard <[email-masked]> wrote:
>
> Hi Tom,
>
> If you look at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-cl-spring-generalized-srv6-for-cmpr-01.txt&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Cc8d0361197f14bd08e8008d8041aa900%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637263859876104225&amp;sdata=1YHDA9nZc9LSAEGR%2FGFyekPXg27DXCww38sSMu1yqNE%3D&amp;reserved=0 section 7 it says:
>

Jim,

That would have to be more than an assumption, it would need to be a normative requirement like "a non-compression capable node MUST NOT be selected as a segment within the G-SID container". But then the question is how does the sender know which nodes are compression capable and which are non-compression capable"-- there is no concept of this distinction in RFC8754, so that information needs to come from an external source of the protocol definition, ie. configuration or negotiation. So that would mean that basic correctness of SRH protocol processing becomes dependent on the control plane.

Tom

> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests:
> rd%40futurewei.com%7Cc8d0361197f14bd08e8008d8041aa900%7C0fee8ff2a3b240
> 189c753a1d5591fedc%7C1%7C1%7C637263859876104225&amp;sdata=y2AMOPkjzwR8
> gNj9Njp6%2BrMnEH45REr%2F6kX7OmsRPfE%3D&amp;reserved=0

---

From: "Richard Vallee (rvallee)" <[email-masked]>
Date: Fri, 29 May 2020 22:20:30 +0000

This is my first email to 6man. 

I have worked on ATM, MPLS, SR-MPLS for 25+ years. 
Back in 90’s I was involved at the ATM forum. 

I am quite aware of the IETF process. 
I have been involved at IETF through my teams for a long time, and more of myself in the last year. 

I was unsure to send this message because I see newcomers are being discouraged from engaging in 6man. 

However, business reality for IPv6 is changing. 
IPv6 is finding new use use-cases including SRv6. 
This is why, lately, I am interested in this discussion in 6man. 

I am not sure how my input will resonate with the chairs and the WG. 

Some claim my input should be discarded, but for what it worth... 

CRH was first introduced as a compression mechanism for SRv6+ (now named as SRm6). 
There are other SRH based proposals that competes with CRH in Spring. 

I was in Spring session at IETF105 (Montreal) and witnessed Bob saying [1] 
[Bob Hinden] As 6man co-chair, would like to understand whether SPRING is interested in this work. 
A clear message would be useful to ensure that 6man spends time usefully. 

I was in Spring session at IETF106 (Singapore) and noticed Rob and Bruno said the following [2] 
Bruno Decraene: Need to ensure we understand the problem as we are hearing different things, also from the draft authors. 
Rob Shakir: Same comments will be raised if we do a call for adoption, so we need to address those before that. 

The author should follow the chairs direction and the IETF process. 

To respect the process and the fairness, the matter should be discussed first in Spring. 

At this stage, I do not support WG adoption of this draft. 

[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00 
[2] https://datatracker.ietf.org/meeting/106/materials/minutes-106-spring-02 

Thanks 
Richard 

    Regards,
    Bob and Ole

---

From: Tom Herbert <[email-masked]>
Date: Fri, 29 May 2020 16:12:14 -0700

Jim,

Suppose if a node advertises it is compression capable but at some
point the administrator downgrades the software to no longer support
compressed SIDs and reboots. When the node comes back what prevents
other nodes from sending compressed SIDs to the node based on the fact
the node previously advertised them but no longer does?

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 30 May 2020 11:17:06 +0200

Tom,

Routing information and protocol and node capabilities are by design
ephemeral and are maintained only till supplier is still alive.

If such state would be kept in the network upon reboot (modulo GR restart
procedures) we would end up running completely broken networks.

So no other nodes can not keep memory of previously advertised capabilities
before reboot or upgrade and keep using it based on
historical advertisements.

Rgs,
R.

---

From: James Guichard <[email-masked]>
Date: Sat, 30 May 2020 13:47:48 +0000

Hi Tom,

I do not expect this to be an issue as I would expect this type of state to be ephemeral by its very nature; if you reboot the router then it needs to advertise its capabilities - likewise other nodes should remove the previous state when they converge to see that the advertising node went down.

Jim

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Friday, May 29, 2020 7:12 PM
To: James Guichard <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

Suppose if a node advertises it is compression capable but at some point the administrator downgrades the software to no longer support compressed SIDs and reboots. When the node comes back what prevents other nodes from sending compressed SIDs to the node based on the fact the node previously advertised them but no longer does?

Tom

> Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call 
> for "The IPv6 Compact Routing Header (CRH)")
>
> > If you look at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-cl-spring-generalized-srv6-for-cmpr-01.txt&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7Ccd5c396537754210a08008d80425c135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637263907506725035&amp;sdata=wtjVH%2B5uh3O5QzfUK%2FjtyFeL1XbUcXXAeDBnuQS7iNk%3D&amp;reserved=0 section 7 it says:
> >
> > Subject: Compatibility with SRH requirement (was Re: Adoption Call 
> > for "The IPv6 Compact Routing Header (CRH)")
> >
> > packet. Someone might argue that this could be a configuration 
> > option or SID length could be a negotiated parameter, that doesn't 
> > work since
> > SID length or format. RFC8754 is very clear on SID length and the 
> > fact they are IPv6 addresses. From the draft: "Segment List[0..n]:  
> > 128-bit
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Fdraft-filsfilscheng-spring-srv6-srh-comp-sl-en
> > > c-
> > > 01
> > > &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a
> > > 54
> > > 04
> > > 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> > > 26
> > > 37
> > > 80261923845&amp;sdata=DA4SX0kvjslMv48d6JBGbWk5rwY%2BGowA64MasmY6RS
> > > s%
> > > 3D
> > > &amp;reserved=0 [2].
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Fdraft-bonica-spring-sr-mapped-six-01%23section
> > > -6
> > > &a
> > > mp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a54
> > > 04
> > > 1c
> > > 00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63726
> > > 37
> > > 80
> > > 261923845&amp;sdata=9JDUZkDB9Wv8ahQ%2FSXzXnrMBJ33gArtla%2F6WbSYD09
> > > M%
> > > 3D
> > > &amp;reserved=0 [3].
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Fdraft-cheng-spring-shorter-srv6-sid-requiremen
> > > t-
> > > 01
> > > &amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a
> > > 54
> > > 04
> > > 1c00908d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637
> > > 26
> > > 37
> > > 80261923845&amp;sdata=DErYZazF4CUGR096chaqMHzNNp6Zhk15jSFB%2FOBPoF
> > > w%
> > > 3D
> > > &amp;reserved=0 [4].
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Fdraft-bonica-6man-seg-end-opt-07%23section-3&a
> > > mp
> > > ;d
> > > ata=02%7C01%7Cjames.n.guichard%40futurewei.com%7C055dd049e9a54041c
> > > 00
> > > 90
> > > 8d804082129%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780
> > > 26
> > > 19
> > > 23845&amp;sdata=lHiNW7wz%2Ffk0%2FWZ2cxs0Ahyp0f1%2BZ9tjjcsKUKz3J5g%
> > > 3D
> > > &a
> > > mp;reserved=0 [5].
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Frfc6554%23section-3&amp;data=02%7C01%7Cjames.n
> > > .g
> > > ui
> > > chard%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff
> > > 2a
> > > 3b
> > > 240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=trRPn
> > > tk
> > > M5
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > to
> > > ol
> > > s.ietf.org%2Fhtml%2Fdraft-bonica-6man-comp-rtg-hdr&amp;data=02%7C0
> > > 1%
> > > 7C
> > > james.n.guichard%40futurewei.com%7C055dd049e9a54041c00908d80408212
> > > 9%
> > > 7C
> > > 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;
> > > sd
> > > at
> > > a=uney8BmhjqknfjS%2FNEu1kpJFIUDM7RFniOO%2BT6n%2Ftvg%3D&amp;reserve
> > > d=
> > > 0
> > >
> > > Administrative
> > > ietf.org%2Fmailman%2Flistinfo%2Fipv6&amp;data=02%7C01%7Cjames.n.gu
> > > ic
> > > ha
> > > rd%40futurewei.com%7C055dd049e9a54041c00908d804082129%7C0fee8ff2a3
> > > b2
> > > 40
> > > 189c753a1d5591fedc%7C1%7C0%7C637263780261923845&amp;sdata=UyBGPL0e
> > > hG
> > > hH

---

From: Tom Herbert <[email-masked]>
Date: Sat, 30 May 2020 09:57:43 -0700

Jim,

Router advertisements are not instantaneous, there is a window of time
that a legacy receiver will receive a packet with the new protocol
because other nodes haven't gotten the information. How can the legacy
receiver correctly process the RH in this case?

This scenario isn't the only case that needs to be considered, there
are also going to be other nodes that attempt to parse routing headers
for various purposes that don't necessarily participate in the routing
protocol-- like firewalls, packet sniffers for debug, etc. How do you
ensure backwards compatibility with these?

The easiest answer to these questions is to just use a new routing
type for compressed SIDs. This eliminates _any_ possibility of
misinterpreting the header format. Either a node understands the new
routing type or it doesn't, there's no ambiguity about that and it's
little cost since there are plenty of routing type numbers available..

Tom

---

From: James Guichard <[email-masked]>
Date: Sat, 30 May 2020 19:46:34 +0000

Hi Tom,

Inline ..

-----Original Message-----
From: Tom Herbert <[email-masked]> 
Sent: Saturday, May 30, 2020 12:58 PM
To: James Guichard <[email-masked]>
Cc: Chengli (Cheng Li) <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

Router advertisements are not instantaneous, there is a window of time that a legacy receiver will receive a packet with the new protocol because other nodes haven't gotten the information. How can the legacy receiver correctly process the RH in this case?

Jim> yes of course it is called convergence but .. if for some odd reason an operator does what you say and downgrades a node to remove G-SRH capability (not sure why they would do that but who knows) then they should also remove any policy that previously used the downgraded node as part of a source routed path. If you are going to remove a node regardless of whether it is G-SRH, SRH, CRH, then it stands to reason that you would have to remove and/or update any policy that included that node in a particular path, or have a backup path available. Further, in normal operation of any source routed solution you will need to make sure that packets end up at the right nodes as nasty things might happen if you don’t - this is actually especially bad with CRH as far as I can tell as if you send a packet to the wrong node and it happens to have a local identifier the same as the incoming packet its going to use that local CRH-FIB entry and send the packet to some IPv6 destination that was not the intended recipient.

This scenario isn't the only case that needs to be considered, there are also going to be other nodes that attempt to parse routing headers for various purposes that don't necessarily participate in the routing
protocol-- like firewalls, packet sniffers for debug, etc. How do you ensure backwards compatibility with these?

Jim> you don't need to as (1) they don’t support compression anyway or advertise capabilities in the IGP so will not be selected as part of a policy where compression is needed, and (2) if you have a mixed policy that includes non-compression capable nodes such as these then you address them as 128-bits (normal SID) and not 32-bit C-SID; note that one of the features of G-SRH is that you can carry different types of SIDs - normal 128-bit SIDs, C-SIDs, uSIDs, etc. 

The easiest answer to these questions is to just use a new routing type for compressed SIDs. This eliminates _any_ possibility of misinterpreting the header format. Either a node understands the new routing type or it doesn't, there's no ambiguity about that and it's little cost since there are plenty of routing type numbers available..

Tom

> > Subject: Re: Compatibility with SRH requirement (was Re: Adoption 
> > Call for "The IPv6 Compact Routing Header (CRH)")
> >
> > > If you look at https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-cl-spring-generalized-srv6-for-cmpr-01.txt&amp;data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C565aa8197602409588ba08d804ba9459%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637264546716781903&amp;sdata=SmJyyh4elyj7rVqm9XoQeB%2Byvtg768oIMRq%2Fk3ELi9U%3D&amp;reserved=0 section 7 it says:
> > >
> > > So if legacy receiver receives a SRH header that contains 
> > > compressed SIDs that are less than 128 bits, it cannot correctly 
> > > process the packet. Someone might argue that this could be a 
> > > configuration option or SID length could be a negotiated 
> > > parameter, that doesn't work since
> > > RFC8754 has no provision for negotiating or configuring an 
> > > alternate SID length or format. RFC8754 is very clear on SID 
> > > length and the fact they are IPv6 addresses. From the draft: "Segment List[0..n]:
> > > 128-bit
> > > rd%40futurewei.com%7Cc8d0361197f14bd08e8008d8041aa900%7C0fee8ff2a3
> > > b2
> > > 40
> > > 189c753a1d5591fedc%7C1%7C1%7C637263859876104225&amp;sdata=y2AMOPkj
> > > zw
> > > R8

---

From: John Scudder <[email-masked]>
Date: Sat, 30 May 2020 20:29:17 +0000

Jim,

On May 30, 2020, at 3:46 PM, James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Further, in normal operation of any source routed solution you will need to make sure that packets end up at the right nodes as nasty things might happen if you don’t - this is actually especially bad with CRH as far as I can tell as if you send a packet to the wrong node and it happens to have a local identifier the same as the incoming packet its going to use that local CRH-FIB entry and send the packet to some IPv6 destination that was not the intended recipient.

I think you’re mistaken, or at least the situation you describe is far more pathological than the one Tom described and you’re dismissing. Consider that in order for what you say to happen, the incoming packet would have to have, as its destination address, an address of the “wrong node”. You can’t just send the packet out the wrong interface and have its CRH identifier misconstrued by any old router that touches it, the DA has to identify the node that receives it.

So now, by definition, you’re saying that two different nodes in the same network have the same (non link-local, also by definition) address. That’s a broken network, of course it’s doing broken things. Alternately, you didn’t mean to say that, and are mistaken about CRH processing.

—John

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 30 May 2020 21:45:34 +0100

John Scudder wrote on 30/05/2020 21:29:
> So now, by definition, you’re saying that two different nodes in the 
> same network have the same (non link-local, also by definition) address. 
> That’s a broken network, of course it’s doing broken things. 

just to put this in context, configuring different nodes with the same 
identifier (e.g. loopback address) on a plain old ipv4 or mpls network 
can cause truly hilarious levels of breakage.  This is not a protocol bug.

Nick

---

From: James Guichard <[email-masked]>
Date: Sat, 30 May 2020 22:05:10 +0000

Hi John,

Let me try to make what I said clearer as you are right, I was not saying two nodes have the same address.

I was trying to point out that with any source routed solution you quite obviously need to make sure that you send the packets to the right nodes along the path specified by your policy and those nodes must support the functionality that you require for that path. Why? Because if you send a CRH packet to the *wrong* node and that node happens to have an identifier matching the one on the packet received, then it will do a lookup on that identifier and forward to the IP address resolved from the identifier -> IPv6 address mapping and that destination might not be the one you meant to send it to next on the path. Likewise, if you send a packet to the *wrong* node with G-SRH and that node does not support compression then this would be bad as well. Moral of the story I was trying to tell is don’t do that and in fact in practice it will not happen if the policy reflects the intent which in the case Tom was talking about would mean that the original node should no longer be in the policy as the policy should have been updated when the node was lost from the topology.

Jim

From: John Scudder <[email-masked]>
Sent: Saturday, May 30, 2020 4:29 PM
To: James Guichard <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

—John

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 30 May 2020 23:37:28 +0100

Hi Jim,

Isn’t this the MPLS argument? If you put the wrong label on a packet (at any point in its path) or if you forward it to the wrong next hop, then all bets are off. (Well, actually, there is a pretty good bet – the packet will be misdelivered.)

You are correctly saying that placing an incorrect ‘next hop’ address on a packet will result in it being delivered to the wrong next hop, and the next lookup will give undesired results because the context for the lookup is broken.

This is, of course, a problem with overlays and private address spaces. Just imagine if the wrong VRF identifier was used (in any form of VPN), or if the packet was tunnelled to the wrong PE. But does that stop us from using VPNs? No, it makes us be more careful with how we write the code.

Best,

Adrian

From: ipv6 <[email-masked]> On Behalf Of James Guichard
Sent: 30 May 2020 23:05
To: John Scudder <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi John,

Jim

From: John Scudder <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, May 30, 2020 4:29 PM
To: James Guichard <[email-masked] <mailto:[email-masked]> >
Cc: Tom Herbert <[email-masked] <mailto:[email-masked]> >; Bob Hinden <[email-masked] <mailto:[email-masked]> >; IPv6 List <[email-masked] <mailto:[email-masked]> >
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

On May 30, 2020, at 3:46 PM, James Guichard <[email-masked] <mailto:[email-masked]> > wrote:

—John

---

From: James Guichard <[email-masked]>
Date: Sat, 30 May 2020 23:07:42 +0000

Hi Adrian,

Yes, it is the same argument. In the case that Tom described I was trying to show that of course undesirable things will happen if you send a G-SRH to a node that does not support compression but this should not happen if the policy is updated correctly to remove the downgraded node as it can no longer support the policy requirements. It is true that there is a timing window if you rely solely on the routing convergence. I suppose theoretically it is possible to downgrade the node and reboot it before everyone has had time to converge and remove the nodes compression capability state,  but you would have to be pretty darn nimble to beat the convergence time 8^); besides I would expect that like any maintenance task you would first want to take the node out of any existing policy *before* you downgraded it to not support compression.

Jim

From: Adrian Farrel <[email-masked]>
Sent: Saturday, May 30, 2020 6:37 PM
To: James Guichard <[email-masked]>; 'John Scudder' <[email-masked]>
Cc: 'Bob Hinden' <[email-masked]>; 'IPv6 List' <[email-masked]>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi Jim,

Best,
Adrian

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of James Guichard
Sent: 30 May 2020 23:05
To: John Scudder <[email-masked]<mailto:[email-masked]>>
Cc: Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: RE: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Hi John,

Jim

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, May 30, 2020 4:29 PM
To: James Guichard <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>
Subject: Re: Compatibility with SRH requirement (was Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)")

Jim,

—John

---

From: Tom Herbert <[email-masked]>
Date: Sat, 30 May 2020 18:18:48 -0700

> Isn’t this the MPLS argument? If you put the wrong label on a packet (at any point in its path) or if you forward it to the wrong next hop, then all bets are off. (Well, actually, there is a pretty…

Adrian,

It's not the same thing. For MPLS the equivalent would be more like
sending 16 bit labels instead of 32 bits. As long as all possible
receivers understand that labels or 16 bits it will work. Conceptually
the technique could be applied to any protocol field in any protocol.
For instance, IPv6 addresses in the IPv6 header could be compressed to
64 bits in some limited domain as long as _all_ the devices agree that
IPv6 addresses are 64 bits within the domain. The problem is that all
really means _all_, if even one node misses the news that addresses
have a different size then the node cannot correctly process packets--
this isn't just bad rouitng, it's fundamental and systematic
misinterpretation of a standard protocol and hence the protocol is not
robust and not backwards compatible.

Tom

> To: James Guichard <james.n.guichard@futurewei..com>
> On May 30, 2020, at 3:46 PM, James Guichard <james.n.guichard@futurewei..com> wrote:
>
>
>