Subject: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 27 May 2020 19:18:45 +0000

WH> My position remains that RFC8663 is a valid alternative and is available; I am against WG adoption of CRH.

The industry widely supports RFC8663.

Instead of denying the evidence, could the CRH authors and proponents finally understand that people are not opposed to new ideas?

People are reminding a long-standing practice of the IETF process. Before tackling a new piece of work, a working group must perform a due diligence on

  1.  whether this new work is redundant with respect to existing IETF protocols,
  2.  whether this new work would deliver genuine benefits and use-cases.

It is factually and logically clear to the working-group that the currently submitted CRH documents.

  1.  fail to position CRH with respect to existing standard widely supported by the industry (e.g., RFC8663)
  2.  fail to isolate new benefit or use-case [1]

This positive collaborative feedback was already given in SPRING.

The CRH authors may change this analysis. They need to document 1 and 2.

Why did the CRH authors not leverage this guidance in SPRING WG?

This was also the chair's guidance in Montreal [2] and Singapore [3]

All the lengthy discussions and debates on the mailing list could be avoided if only the CRH authors would tackle 1 and 2.

The CRH authors must tackle 1 and 2.

  *   This is the best way to justify a/the work from the IETF community and b/ the hardware and software investment from vendors.
  *   True benefits must be present to justify such a significant engineering investment (new data-pane, new control-plane).

Thanks

Regards … Zafar

[1] https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/

[2] https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true

[3] https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/

---

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

Zafar,

Why all the passion about stopping the CRH? Does it break any existing standard? Does it consume any scarce resource?

You might argue that there is a scarcity of Routing header type numbers. But that would be a very short argument. You might argue that WG resources are scarce, and that it would take too much time to review this fourteen page document. But that argument might take more time than the document review.

In your email, below, you mention "the hardware and software investment from vendors". Is that the scarce resource?

Vendors are not obliged to implement every draft that is adopted as a WG item. Generally, the marketplace drives product roadmaps.

If the only resource we are protecting is vendor investment, the long-standing practice of due diligence should be tempered by operator demand. The IETF should not pretend to understand operator requirements better than the operators themselves.

Why not let the marketplace decide whether it needs a CRH?

                                                                                            Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Wednesday, May 27, 2020 3:19 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Sander Steffann <[email-masked]>
Cc: Mach Chen <[email-masked]>; Ron Bonica <[email-masked]>; Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked]; Zafar Ali (zali) <[email-masked]>
Subject: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

[External Email. Be cautious of content]

Thanks

Regards ... Zafar

[1] https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>

[2] https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>

[3] https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 27 May 2020 20:18:58 +0000

What I find so bizarre is –

You have an multiple operators – who have clearly said – we want this – we see advantage of this.  Yet still the obstructionism and denialism continues.  The “not invented here” syndrome seems to run deep – and email after email is patently ignored from the very people who have to buy the hardware.  Reference is made to Montreal – yet the emails that stated the use cases after it went by with no response.  No technical objections ever show up – other than – we don’t want this and you haven’t given us this mythical architecture document – which was yet another non-technical response that seems so clearly designed to stall any innovation that doesn’t come from one source.

All I see from the operator perspective here is obstructionism and stalling in a desperate attempt to block anything that could be a threat to what was dreamed up by someone else.  It is almost as if there is fear that the market may choose something other than what was designed – and that fear is driving this stance of throw everything we hav against the wall and hope that something sticks – because the technical arguments have failed time and again.

This pitbull approach certainly doesn’t garner any respect for me, does not help to promote srv6 which seems to be what you want and in fact convinces me more every day that CRH is the right move – where I can built on top of it without the obstructionism of a vendor that seems to have zero interest in what mysef and other operators are clearly stating over and over again.

Yet again – I support crh – I’ve deployed CRH – CRH works for us – and we still continue to support it.  And irrespective of if it is adopted – the development of it will continue – and it will exist – the only question is – do we end up with something that the market wants outside of the auspices of the IETF – or do we end up with something that is properly standardized, because this level of obstructionism will not prevent the development.

Can we actually get back to proper technical reasoning?

Thanks

Andrew

From: ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Wednesday, 27 May 2020 at 23:07
To: "Zafar Ali (zali)" <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: 6man <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar,

In your email, below, you mention “the hardware and software investment from vendors”. Is that the scarce resource?

                                                                                            Ron

Thanks

Regards … Zafar

---

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

As I said, I want to use CRH for OMNI and AERO; I don't want the term "MPLS" to appear
either in my documents or in any documents mine cite. The 16-bit CRIDs in CRH are very
handy for coding ULA Subnet Router Anycast addresses such as fd80::/16, fd81::/16,
fd82::/16, etc., and the 32-bit CRIDs are very handy for coding the administrative address
suffixes of fd80::/96. So, CRH gives everything I need (and nothing I don’t need) for
successfully spanning the (potentially) multiple segments of the AERO link.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Andrew Alston
Sent: Wednesday, May 27, 2020 1:19 PM
To: Ron Bonica <rbonica=[email-masked]>; Zafar Ali (zali) <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Sander Steffann <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Date: Wednesday, 27 May 2020 at 23:07
To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar,

                                                                                            Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, May 27, 2020 3:19 PM
To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: Mach Chen <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Regards … Zafar

---

From: Sander Steffann <[email-masked]>
Date: Wed, 27 May 2020 22:59:12 +0200

Hi Andrew,

> You have an multiple operators – who have clearly said – we want this – we see advantage of this.  Yet still the obstructionism and denialism continues.  The “not invented here” syndrome seems to r…

This makes me think back to the days of telcos. You know, the world where telcos defined the protocols and the users just had to accept their choices... The world where TCP/IP flourished because it allowed permissionless innovation (which is the very thing that the IETF says it's all about to their supporters on https://www.ietf.org/about/support/).

And look where we are today. The IETF as the place where innovation is shot down because it might compete with "IETF sanctioned" standards. The IETF has turned IP into ISO's OSI stack of today.

> Yet again – I support crh – I’ve deployed CRH – CRH works for us – and we still continue to support it.  And irrespective of if it is adopted – the development of it will continue – and it will exi…

Yep. That's what happens to those standing in the way of permissionless innovation: at some point the users (operators) have had enough and will fight what they believe in, ignoring the outdated standards bodies that hold them back.

If the IETF can't provide permissionless innovation anymore it has no reason to exist.
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 May 2020 09:06:06 +1200

> The industry widely supports RFC8663.

Can you remind us which major operators rely on RFC8633 today? After all, the RFC is only 5 months old.

>  2. whether this new work would deliver genuine benefits and use-cases. 

I don't know where you get that "must" from since the IETF has no rules to govern the process of draft adoption. (There will be a draft about that shortly, for possible discussion in gendispatch, but today there are no rules).

There is some general guidance about redundancy, in RFC1958:

  "3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

So, in so far as we have guidance on when to accept apparent duplication, it is around two judgments: "there is a good technical reason" and "improvements".
   
>  2. fail to isolate new benefit or use-case [1]

Neither of those things are required in a protocol spec. I'm not saying they are unimportant, or that they should not inform the adoption decision, but they have been discussed on this mailing list and IMHO that is sufficient for the WG decision.

I'm not competent to "position" CRH. That's why I'd like hear from the Routing Area ADs. However, I will comment that it takes about 10 minutes to read and understand the CRH spec. It would take several days to read and understand the SRV6 material to the point of fully understanding RFC8574 (I know because I tried), and RFC8663 also needs a lot of background reading. There are a couple of other items in RFC1958 that seem relevant to this:

  "3.5 Keep it simple. When in doubt during design, choose the simplest
   solution.

   3.6 Modularity is good. If you can keep things separate, do so."

CRH factually and logically wins on those criteria. 

The use case is: some operators want this. That has been enough for the IETF since 1986 (and is of course much more important than vendor preferences).

Regards
    Brian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 27 May 2020 21:20:01 +0000

Fred,

Is there any IETF requirement document for OMNI and AERO (I am sorry I am not aware of the technology but very much interested in learning)?
Do we have some documents describing the scale you would need?
Have the associated WG analyzed existing solutions?
Have they feed the results of the above to 6man WG?

All other routing header types have had requirements and designs from dedicated working groups with expertise in the area.
Why should CRH be an exception, especially when there are multiple competing solutions in 6man and Spring?

Thanks

Regards … Zafar

From: "Templin (US), Fred L" <[email-masked]>
Date: Wednesday, May 27, 2020 at 4:33 PM
To: Andrew Alston <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks - Fred

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Wed, 27 May 2020 21:31:47 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Sander Steffann

> This makes me think back to the days of telcos. You know, the world where telcos defined the protocols and the users just had to accept their choices... The world where TCP/IP flourished because it…

That's also been my reaction to the objections to CRH. Who cares if other ways of doing roughly the same thing exist? Plus, RFC 8663 is worded to read that it's for MPLS segment routing, which will instantly turn off a lot of potential users.

In the Internet way of doing things, an innovation that finds a couple of adopters becomes fact. No need to overcome any other hurdles. Over time, some RFCs are labeled "historic," if they have no current relevance. Pretty simple.

Bert

---

From: Erik Kline <[email-masked]>
Date: Wed, 27 May 2020 14:40:31 -0700

There are actual, meaningful differences to be contemplated; folks
with no operational MPLS in there networks might not want to be forced
to start.

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali)
<zali=[email-masked]> wrote:
> whether this new work is redundant with respect to existing IETF protocols,
> whether this new work would deliver genuine benefits and use-cases.
>
>
>
> fail to position CRH with respect to existing standard widely supported by the industry (e.g., RFC8663)
> fail to isolate new benefit or use-case [1]
>
>
>
> This is the best way to justify a/the work from the IETF community and b/ the hardware and software investment from vendors.
> True benefits must be present to justify such a significant engineering investment (new data-pane, new control-plane).
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

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

Andrew,

I don't think this is about killing innovation. After all no one is saying
you can not use it in your network.

WG acceptance calls are evaluated in terms of WG rough consensu if
significant number of members of WG find a proposal useful and if they are
willing to work on it.

It seems clear that other then one vendor and very few individuals majority
of the WG members do not support the adoption.

I am not against CRH. But what I am against is that CRH/SRm6 authors
already bounced back via SPRING doors so they have chosen to try to enter
via 6man window. That is not proper style for any proposal.

Regards,
R.

On Wed, May 27, 2020 at 10:19 PM Andrew Alston <
[email-masked]> wrote:

> You have an multiple operators – who have clearly said – we want this – we
> see advantage of this.  Yet still the obstructionism and denialism
> continues.  The “not invented here” syndrome seems to run deep – and email
> after email is patently ignored from the very people who have to buy the
> hardware.  Reference is made to Montreal – yet the emails that stated the
> use cases after it went by with no response.  No technical objections ever
> show up – other than – we don’t want this and you haven’t given us this
> mythical architecture document – which was yet another non-technical
> response that seems so clearly designed to stall any innovation that
> doesn’t come from one source.
>
>
>
> All I see from the operator perspective here is obstructionism and
> stalling in a desperate attempt to block anything that could be a threat to
> what was dreamed up by someone else.  It is almost as if there is fear that
> the market may choose something other than what was designed – and that
> fear is driving this stance of throw everything we hav against the wall and
> hope that something sticks – because the technical arguments have failed
> time and again.
>
>
>
> This pitbull approach certainly doesn’t garner any respect for me, does
> not help to promote srv6 which seems to be what you want and in fact
> convinces me more every day that CRH is the right move – where I can built
> on top of it without the obstructionism of a vendor that seems to have zero
> interest in what mysef and other operators are clearly stating over and
> over again.
>
>
>
> Yet again – I support crh – I’ve deployed CRH – CRH works for us – and we
> still continue to support it.  And irrespective of if it is adopted – the
> development of it will continue – and it will exist – the only question is
> – do we end up with something that the market wants outside of the auspices
> of the IETF – or do we end up with something that is properly standardized,
> because this level of obstructionism will not prevent the development.
>
>
>
> *From: *ipv6 <[email-masked]> on behalf of Ron Bonica <rbonica=
> [email-masked]>
> *Date: *Wednesday, 27 May 2020 at 23:07
> *To: *"Zafar Ali (zali)" <[email-masked]>, "Henderickx, Wim (Nokia -
> BE/Antwerp)" <[email-masked]>, Sander Steffann <
> [email-masked]>
> *Cc: *6man <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: Long-standing practice of due-diligence is expected - Re:
> [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
> option?
>
>
>
> Zafar,
>
>
>
> Why all the passion about stopping the CRH? Does it break any existing
> standard? Does it consume any scarce resource?
>
>
>
> You might argue that there is a scarcity of Routing header type numbers.
> But that would be a very short argument. You might argue that WG resources
> are scarce, and that it would take too much time to review this fourteen
> page document. But that argument might take more time than the document
> review.
>
>
>
> In your email, below, you mention “the hardware and software investment
> from vendors”. Is that the scarce resource?
>
>
>
> Vendors are not obliged to implement every draft that is adopted as a WG
> item. Generally, the marketplace drives product roadmaps.
>
>
>
> If the only resource we are protecting is vendor investment, the
> long-standing practice of due diligence should be tempered by operator
> demand. The IETF should not pretend to understand operator requirements
> better than the operators themselves.
>
>
>
> *From:* Zafar Ali (zali) <[email-masked]>
> *Sent:* Wednesday, May 27, 2020 3:19 PM
> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>;
> Sander Steffann <[email-masked]>
> *Cc:* Mach Chen <[email-masked]>; Ron Bonica <[email-masked]>;
> Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>; [email-masked];
> Zafar Ali (zali) <[email-masked]>
> *Subject:* Long-standing practice of due-diligence is expected - Re:
> [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
> option?
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> WH> My position remains that RFC8663 is a valid alternative and is
> available; I am against WG adoption of CRH.
>
>
>
> Instead of denying the evidence, could the CRH authors and proponents
> finally understand that people are not opposed to new ideas?
>
>
>
> People are reminding a long-standing practice of the IETF process. Before
> tackling a new piece of work, a working group must perform a due diligence
> on
>
>    1. fail to position CRH with respect to existing standard widely
>    supported by the industry (e.g., RFC8663)
> All the lengthy discussions and debates on the mailing list could be
> avoided if only the CRH authors would tackle 1 and 2.
>
>
>
>    - This is the best way to justify a/the work from the IETF community
>    and b/ the hardware and software investment from vendors.
>    - True benefits must be present to justify such a significant
>    engineering investment (new data-pane, new control-plane).
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl0PT0CIY$>
>
> [2]
> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true
> <https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVl8aoFdbw$>
>
> [3]
> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/__;!!NEt6yMaO-gk!XHiztGcX_48I-aQukzfQTbbmTVdtDpjH9FqoL2NsOT8vOTnK4f6flXwVlypBDeuG$>
>
>
>
>
>
>

---

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

Hi Zafar,

1) Is there any IETF requirement document for OMNI and AERO (I am sorry I am not aware of the technology but very much interested in learning)?

AERO began life in the IEFT many years ago and was progressed there up to about
three years ago when it was brought into focus in the International Civil Aviation
Organization (ICAO). Since that time, AERO development was largely driven by the
ICAO requirements, while the OMNI spec was entirely born in the ICAO community.
We now have a liaison statement asking the IETF to do work on OMNI, so the work is
now crossing back over from ICAO into the IETF again.

2) Do we have some documents describing the scale you would need?

Working papers in ICAO talk about the use case for developing an Aeronautical
Telecommunications Network with Internet Protocol Services (ATN/IPS) that will
be an IPv6-based network for worldwide air traffic management. Worldwide air
traffic management is a large-scale consideration. We have also begun to discuss
about OMNI and AERO for Intelligent Transportation Systems in the ipwave group.
Worldwide ground transportation is an even larger-scale consideration.

3) Have the associated WG analyzed existing solutions?  Have they feed the results
of the above to 6man WG?

I assume you are referring to existing SRH solutions? The subject of SRH is new
to the aviation circles, but what we need is something that is clean, compact and
pure IPv6-based with no MPLS implications. We like what we see with CRH.

Fred

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Wednesday, May 27, 2020 2:20 PM
To: Templin (US), Fred L <[email-masked]>; Andrew Alston <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Sander Steffann <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Fred,

Thanks

Regards … Zafar

From: "Templin (US), Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 27, 2020 at 4:33 PM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Andrew Alston
Sent: Wednesday, May 27, 2020 1:19 PM
To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 May 2020 21:58:55 +0000

Robert,

If there had never been an SRm6 proposal, would you still object to the CRH?

                                                                               Ron

Juniper Business Use Only
From: Robert Raszuk <[email-masked]>
Sent: Wednesday, May 27, 2020 5:50 PM
To: [email-masked] <[email-masked]>
Cc: Ron Bonica <[email-masked]>; Zafar Ali (zali) <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Sander Steffann <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Andrew,

I don't think this is about killing innovation. After all no one is saying you can not use it in your network.

WG acceptance calls are evaluated in terms of WG rough consensu if significant number of members of WG find a proposal useful and if they are willing to work on it.

It seems clear that other then one vendor and very few individuals majority of the WG members do not support the adoption.

I am not against CRH. But what I am against is that CRH/SRm6 authors already bounced back via SPRING doors so they have chosen to try to enter via 6man window. That is not proper style for any proposal.

Regards,
R.

On Wed, May 27, 2020 at 10:19 PM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
What I find so bizarre is -

You have an multiple operators - who have clearly said - we want this - we see advantage of this.  Yet still the obstructionism and denialism continues.  The "not invented here" syndrome seems to run deep - and email after email is patently ignored from the very people who have to buy the hardware.  Reference is made to Montreal - yet the emails that stated the use cases after it went by with no response.  No technical objections ever show up - other than - we don't want this and you haven't given us this mythical architecture document - which was yet another non-technical response that seems so clearly designed to stall any innovation that doesn't come from one source.

All I see from the operator perspective here is obstructionism and stalling in a desperate attempt to block anything that could be a threat to what was dreamed up by someone else.  It is almost as if there is fear that the market may choose something other than what was designed - and that fear is driving this stance of throw everything we hav against the wall and hope that something sticks - because the technical arguments have failed time and again.

This pitbull approach certainly doesn't garner any respect for me, does not help to promote srv6 which seems to be what you want and in fact convinces me more every day that CRH is the right move - where I can built on top of it without the obstructionism of a vendor that seems to have zero interest in what mysef and other operators are clearly stating over and over again.

Yet again - I support crh - I've deployed CRH - CRH works for us - and we still continue to support it.  And irrespective of if it is adopted - the development of it will continue - and it will exist - the only question is - do we end up with something that the market wants outside of the auspices of the IETF - or do we end up with something that is properly standardized, because this level of obstructionism will not prevent the development.

Thanks

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>

Zafar,

                                                                                            Ron

Thanks

Regards ... Zafar

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 May 2020 00:06:14 +0200

Hi Ron,

If there would never been SRm6 I would welcome that we have a technical
discussion and compare pros and cons between CRH and RbR .. then we proceed
with best option for the industry.

If you are open to such discussion my doors are open.

Best,
Robert

On Wed, May 27, 2020 at 11:59 PM Ron Bonica <[email-masked]> wrote:

> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, May 27, 2020 5:50 PM
> *To:* [email-masked] <[email-masked]
> >
> *Cc:* Ron Bonica <[email-masked]>; Zafar Ali (zali) <[email-masked]>;
> Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]>; Sander
> Steffann <[email-masked]>; [email-masked]; 6man <[email-masked]>
> *Subject:* Re: Long-standing practice of due-diligence is expected - Re:
> It seems clear that other then one vendor and very few individuals
> majority of the WG members do not support the adoption.
>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!WIXBKUmrm0y3g6Tak4T7QExZahofjlB9YL76AQtpLEloLcYX8nyN5RA4KY45RnTt$>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 May 2020 10:08:30 +1200

On 28-May-20 09:50, Robert Raszuk wrote:
> WG acceptance calls 

Adoption is not acceptance. At least half the messages on this topic are written as if we were in the middle of a WG Last Call.

> are evaluated in terms of WG rough consensu if significant number of members of WG find a proposal useful and if they are willing to work on it. 

Indeed. Exactly. Not in the least about consensus that the proposal is ready for approval. Just that it is ready for discussion and, as you say, that there are people willing to work on it.

> It seems clear that other then one vendor and very few individuals majority of the WG members do not support the adoption. 

That's for the WG Chairs to evaluate, and I expect them to evaluate singing in chorus appropriately. Also, and this is not a grammatical quibble, we don't have "members". We have participants, and we don't count votes.

> I am not against CRH. But what I am against is that CRH/SRm6 authors already bounced back via SPRING doors so they have chosen to try to enter via 6man window. That is not proper style for any prop…

I agree that CRH is not in scope of the SPRING charter as it stands today ("the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6)"). But let me say again that we should hear the opinion of the routing ADs.

Regards
    Brian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 27 May 2020 22:15:49 +0000

Hi Brian,

As you said,
>>    I'd like hear from the Routing Area ADs.

And you also mentioned the following in [1]:

“progressing this draft without advice from the Routing Area that it is needed would be a bit foolish IMHO.”

I agree with you.

I also said in my email is that “could the CRH authors and proponents finally understand that people are not opposed to new ideas?”

Please read the history of the draft:

  *   During IETF106. This is what the draft authors agreed on the mailing list [2].

o   “I accept your challenge to produce a document that describes the advantages of SRm6 over SRv6, as well as the differences between SRm6 and SRv6. Expect some operational hoarse-sense as well as some architectural deep-diving.”

·         No such document was produced.

  *   Instead, in Feb. 2020, authors removed normative reference to SRm6.
  *   Authors positioned CRH as a replacement of RH0
  *   RH0 replacement was later removed before the adoption call.
  *   There are other competing solutions that are discussed in Spring (and will come to 6man via the “routing area”).

Why CRH authors are trying to “skip the queue” and “skip the routing area”?

[1] https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/
[2] https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/

Thanks

Regards … Zafar

---

From: Andrew Alston <[email-masked]>
Date: Wed, 27 May 2020 22:26:11 +0000

Zafar,

It amazes me how totally selective you are with your reading.

I won’t even bother dignifying much of the word twisting and gaming and selective reading with a response – but what I will say is this.  Yes, originally, CRH was heavily linked to SRm6.  But – over time, thinking and ideas evolve.  And the realization was pretty clear that CRH served so many purposes outside of SRm6.  CRH is a brick, a building block, the tyre on a car – and yes – the normative reference to SRm6 was removed because – CRH is not normative to SRm6 – SRm6 is normative to CRH.  The realization that CRH had many many applications and could be used outside of the segment routing paradigm was simply an evolution in thinking – and that – is the nature of innovation.  To innovate you have to have a willingness to let your thoughts evolve and not remain wedded to something when you realize that the possibilities of something go beyond the original intention.

If you wish to remain tied to something no matter the findings – and no matter the progression through the process – both in terms of your own thinking and the comments and thoughts of others – you are no longer innovating – you are stuck in the mire.  So yes – the thinking evolved over time and new applications were seen.

And as for the claims it was positioned as a replacement for RH0 – that has been asked and answered – many times.  Yes – there were references to RH0 – it was never a like for like replacement and I dispute that that was ever said – but I guess no matter how many times things are repeated – selective reading still applies.

Andrew

[1] https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/<https://mailarchive.ietf.org/arch/msg/ipv6/fasaPY3vGhMEmPreUFEJ4j7281o/>
[2] https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/<https://mailarchive.ietf.org/arch/msg/spring/Su-5NFpETVGt5beWObmnCP4LoYs/>

Thanks

Regards … Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 27 May 2020 22:32:00 +0000

Hi,

The authors of CRH has already have multiple drafts and more CP/ DP changes will be required. E.g., it will require

  *   ISIS changes (draft-bonica-lsr-crh-isis-extensions)
  *   To carry VPN information (draft-bonica-6man-vpn-dest-opt)
  *   For SFC (draft-bonica-6man-seg-end-opt)
  *   BGP changes (draft-alston-spring-crh-bgp-signalling, draft-ssangli-idr-bgp-vpn-srv6-plus)
  *   PCEP extension (TBA)
  *   OAM for debugging the mapping table
  *   Yang interface
  *   More to come

The scope of CRH is “limited domain” and not the “Internet”.

Given this, where the IETF community discuss how these so-called “building blocks” fits together?

If author’s claim is that the home for the architecture work is not Spring, then the authors should create a BoF in routing area to first defined architecture, use-case and requirements.
This is the hard worked everyone else did before the CRH authors.
Why they are looking for a short cut?

CRH is a “major” change and outside the scope of 6man charter.
It should follow the proper IETF review process.

Thanks

Regards … Zafar

From: ipv6 <[email-masked]> on behalf of Brian E Carpenter <[email-masked]>
Date: Wednesday, May 27, 2020 at 6:09 PM
To: Robert Raszuk <[email-masked]>, Andrew Alston <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

WG acceptance calls

Regards
    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 May 2020 00:39:48 +0200

/*adjusting subject */

> The scope of CRH is “limited domain” and not the “Internet”.

Well that is only what the document under adoption call says.

However we have all seen described use cases over Internet  ... so much of
limited domain. Explanation given is that "limited domain" does not to be
continuous ... very clever indeed !

I am observing this point as my use case is also over Internet.

So if I apply any RH on my application host_1 carry it over Internet to my
server host_2 clearly those two hosts create a "limited domain".

Maybe we should just drop right here this "limited domain"
restriction/scope for any solution being discussed here ?

Thx,
R.

On Thu, May 28, 2020 at 12:32 AM Zafar Ali (zali) <[email-masked]> wrote:

> Hi,
>
>
>
> The authors of CRH has already have multiple drafts and more CP/ DP
> changes will be required. E.g., it will require
>
>    - ISIS changes (draft-bonica-lsr-crh-isis-extensions)
>    - To carry VPN information (draft-bonica-6man-vpn-dest-opt)
>    - For SFC (draft-bonica-6man-seg-end-opt)
>    - BGP changes (draft-alston-spring-crh-bgp-signalling,
>    draft-ssangli-idr-bgp-vpn-srv6-plus)
>    - PCEP extension (TBA)
>    - OAM for debugging the mapping table
>    - Yang interface
>    - More to come
>
>
>
> If author’s claim is that the home for the architecture work is not
> Spring, then the authors should create a BoF in routing area to first
> defined architecture, use-case and requirements.
>

---

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

Zafar,

Many of the drafts that you list below are unrelated to the CRH (e.g., draft-bonica-6man-vpn-dest-opt). Many do not exist and are not required (e.g., OAM for debugging the mapping table).

Try to understand that the CRH is a building block that can be deployed in many scenarios. It is not a grand architecture.

                                                              Ron

Juniper Business Use Only
From: Zafar Ali (zali) <zali=[email-masked]>
Sent: Wednesday, May 27, 2020 6:32 PM
To: Brian E Carpenter <[email-masked]>; Robert Raszuk <[email-masked]>; [email-masked] <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi,

The scope of CRH is "limited domain" and not the "Internet".

Given this, where the IETF community discuss how these so-called "building blocks" fits together?

If author's claim is that the home for the architecture work is not Spring, then the authors should create a BoF in routing area to first defined architecture, use-case and requirements.
This is the hard worked everyone else did before the CRH authors.
Why they are looking for a short cut?

CRH is a "major" change and outside the scope of 6man charter.
It should follow the proper IETF review process.

Why CRH authors are trying to "skip the queue" and "skip the routing area"?

Thanks

Regards ... Zafar

From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 27, 2020 at 6:09 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

WG acceptance calls

Regards
    Brian

--------------------------------------------------------------------
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!X9nnCHwtlMnfPJCt-JAQWt_RZK_9HziPYxC-DEez6J3r6JBFErtYntrfAskH9yNv$>
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 May 2020 09:03:25 +1000

Are you a member of the IESG?

On Thu, 28 May 2020, 08:33 Zafar Ali (zali), <zali=
[email-masked]> wrote:

> *From: *ipv6 <[email-masked]> on behalf of Brian E Carpenter <
> [email-masked]>
> *Date: *Wednesday, May 27, 2020 at 6:09 PM
> *To: *Robert Raszuk <[email-masked]>, Andrew Alston <
> [email-masked]>
> *Cc: *Ron Bonica <rbonica=[email-masked]>, "[email-masked]"
> <[email-masked]>, 6man <[email-masked]>
> *Subject: *Re: Long-standing practice of due-diligence is expected - Re:
> Adoption is not acceptance. At least half the messages on this topic are
> written as if we were in the middle of a WG Last Call.
>
>
>
> are evaluated in terms of WG rough consensu if significant number of
> members of WG find a proposal useful and if they are willing to work on it.
>
>
>
> Indeed. Exactly. Not in the least about consensus that the proposal is
> ready for approval. Just that it is ready for discussion and, as you say,
> that there are people willing to work on it.
>
>
>
> That's for the WG Chairs to evaluate, and I expect them to evaluate
> singing in chorus appropriately. Also, and this is not a grammatical
> quibble, we don't have "members". We have participants, and we don't count
> votes.
>
>
>
> I agree that CRH is not in scope of the SPRING charter as it stands today
> ("the home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6)").
> But let me say again that we should hear the opinion of the routing ADs.
>
>
>
> Regards
>
>     Brian
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2020 19:58:17 -0300

On 27/5/20 18:50, Robert Raszuk wrote:
[...]
> already bounced back via SPRING doors so they have chosen to try to 
> enter via 6man window. That is not proper style for any proposal.

As someone that has experienced how folks have resorted to very twisted 
readings of RFC2460, and how they have undermined appropriate further 
clarifications in what became RFC8200, both in the context of what 
became RFC8754 and the ongoing network-programming draft (subject of an 
appeal), I find this statement kind of amusing.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 May 2020 20:03:42 -0300

On 27/5/20 19:32, Zafar Ali (zali) wrote:
[...]
> CRH is a “major” change and outside the scope of 6man charter.

This is plain wrong. I will remind you that this very same group shipped 
what became RFC8754.

> It should follow the proper IETF review process.

Well, yeah. What's ongoing is a "call for adoption", not a "call for 
publication". Once a document is adopted, it typically goes through 
multiple revisions, is subject to WGLC, IETF LC, and IESG review.

So I'm not sure why you are implying otherwise.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 May 2020 11:10:49 +1200

On 28-May-20 10:39, Robert Raszuk wrote:
...
> Maybe we should just drop right here this "limited domain" restriction/scope for any solution being discussed here ? 

In that case we should definitely never have adopted draft-ietf-6man-segment-routing-header, whose first reference is RFC8402, which is very explicitly a description of a limited doman model:

"Segment Routing domain (SR domain): the set of nodes participating in
 the source-based routing model...   It is expected that all
 nodes in an SR domain are managed by the same administrative entity."

The CRH draft says essentially the same:

"   o  Is designed to operate within a network domain."

    Brian

---

From: Xing Li <[email-masked]>
Date: Thu, 28 May 2020 07:22:09 +0800

> The use case is: some operators want this. That has been enough for the IETF since 1986 (and is of course much more important than vendor preferences).

+1

xing

---

From: Mark Smith <[email-masked]>
Date: Thu, 28 May 2020 09:24:10 +1000

> > The scope of CRH is “limited domain” and not the “Internet”.

The scope of SR-MPLS is also "limited domain", because, quite obviously,
after 20 years, MPLS isn't yet end-to-end across the Internet, never was
designed to be and never will be.

So SPRING need to declare SR-MPLS deprecated first before the "limited
domain" argument can be attempted to be used against CRH.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 May 2020 01:01:34 +0000

Brian,

I'm glad you brought this up, because I certainly have been thinking it. 

                                  Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Wednesday, May 27, 2020 7:11 PM
To: Robert Raszuk <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Cc: [email-masked] <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: Limited domains ...

    Brian

---

From: "徐小虎(义先)" <[email-masked]>
Date: Thu, 28 May 2020 09:12:37 +0800

It makes sense of using source routing across the Internet. For example, using source routing for traffic steering across edge networks just like Akamai's SureRoute which is a limited domain over the Internet indeed. In that case, it's necessary to protect the source route information carried within packets by some means (e.g., indirection), in other words, it'd better not to directly carry the source routes in the form of an IP address list within the source routed packets. BTW, it may be worthwhile to consider the scenario where the source routed packets need to traverse both IPv4 and IPv6 Internet along the path towards their final destinations.

Of course, whether using CRH or RFC8663 is purely a matter of personal preference from my point of view, just like someone prefers to use VXLAN rather than MPLS-over-UDP (http://tools.ietf.org/html/rfc7510) for network virtualization, and someone prefers to use EVPN rather than Virtual Subnet (https://tools.ietf.org/html/rfc7814) which is fully built on the mature MPLS/BGP L3VPN (https://tools.ietf.org/html/rfc4364) for pure Layer3-based overlays. 

Best regards,
Xiaohu

------------------------------------------------------------------
From:Robert Raszuk <[email-masked]>
Send Time:2020年5月28日(星期四) 06:40
To:Zafar Ali (zali) <[email-masked]>
Cc:Ron Bonica <rbonica=[email-masked]>; [email-masked] <[email-masked]>; 6man <[email-masked]>; Brian E Carpenter <[email-masked]>; Andrew Alston <[email-masked]>
Subject:[spring] Limited domains ...

/*adjusting subject */

However we have all seen described use cases over Internet  ... so much of limited domain. Explanation given is that "limited domain" does not to be continuous ... very clever indeed ! 

So if I apply any RH on my application host_1 carry it over Internet to my server host_2 clearly those two hosts create a "limited domain". 

Thx,
R.

The authors of CRH has already have multiple drafts and more CP/ DP changes will be required. E.g., it will require 
ISIS changes (draft-bonica-lsr-crh-isis-extensions)
To carry VPN information (draft-bonica-6man-vpn-dest-opt) 
For SFC (draft-bonica-6man-seg-end-opt)
BGP changes (draft-alston-spring-crh-bgp-signalling, draft-ssangli-idr-bgp-vpn-srv6-plus)
PCEP extension (TBA)
OAM for debugging the mapping table
Yang interface 
More to come  

 

 
Thanks
 
Regards … Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 28 May 2020 04:20:54 +0000

Hi Fred,

MANY thanks for your follow-up – much appreciated.

> to the aviation circles,

The subject of CRH should also be new to the aviation circles.
I would highly encourage you to look into SRv6 alternatives that IETF has been working on for >6 years.
After such discussions on the requirements, if CRH turns out to be a better fit – by all means select CRH.
But please let’s avoid “putting the cart before the horse”.

> but what we need is something that is clean, compact and
> pure IPv6-based with no MPLS implications.

IMO, SRv6 checks all the boxes.
It will be a pleasure to have such discussions (I am also available offline).

Thanks

Regards … Zafar

From: "Templin (US), Fred L" <[email-masked]>
Date: Wednesday, May 27, 2020 at 5:53 PM
To: "Zafar Ali (zali)" <[email-masked]>, Andrew Alston <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Hi Zafar,

Fred

Fred,

Thanks

Regards … Zafar

Thanks - Fred

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Thu, 28 May 2020 04:51:10 +0000

Fred, if the issue is a document to describe RFC 8663 w/o calling our MPLS, this can be done. Would that solve your issue?

Date: Wednesday, 27 May 2020 at 22:33

Thanks - Fred

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 28 May 2020 06:30:09 +0000

Hi Andrew,

Re: “Yes, originally, CRH was heavily linked to SRm6.  But – over time, thinking and ideas evolve.”

I looked at the following diffs https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-comp-rtg-hdr-11.txt (rev. 10 to rev. 11 in Feb. 2020).
All I find is surgical removal of SRm6 and positing of CRH as replacement of RH0.

When the WG played the “hide and seek”, all aspects of SRm6 came back on the table [1] and [I can cite MANY specific references to the ML, if you like].
I am sorry, I fail to see the evolution (except may be the RH0 replacement positioning).

Please realize that there are other competing solutions to CRH in Spring.

It is only fair and in best interest of industry/ IETF that all solutions are discussed and progress together.

I already REQUESTED: “could the CRH authors and proponents finally understand that people are not opposed to new ideas?”

[1] https://mailarchive.ietf.org/arch/msg/ipv6/zRZJe68FZX3X0wla-muo3IkCJv8/

Thanks

Regards … Zafar

From: Andrew Alston <[email-masked]>
Date: Wednesday, May 27, 2020 at 6:26 PM
To: "Zafar Ali (zali)" <[email-masked]>, Brian E Carpenter <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Zafar,

Andrew

Thanks

Regards … Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 28 May 2020 06:57:57 +0000

Hi Andrew,

Re: Reference is made to Montreal – yet the emails that stated the use cases after it went by with no response.

The following use-case text was proposed during the adoption call [1].
“10.0 Use-cases
The CRH can be used to provide traffic steering in:

  *   Data centers
  *   Service provider networks
  *   Enterprise networks
Each of these networks may have a preferred method for populating the basic FIB and the CRH-FIB. For example, a data center may use a controller to populate both FIBs while a service provider may use an IGP to populate both FIBs.”

Robert has already responded: “Is there any reason why you have not listed "Home networks" and "Lab networks" ?” [2]

[1] https://mailarchive.ietf.org/arch/msg/ipv6/1wPX7xpvsgXlq1EMSs25MjwZNPA/
[2] https://mailarchive.ietf.org/arch/msg/ipv6/IXlGxvjBBKvTMTA12UaX8jHqQNw/

Thanks

Regards … Zafar

From: Andrew Alston <[email-masked]>
Date: Wednesday, May 27, 2020 at 4:19 PM
To: Ron Bonica <rbonica=[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>
Cc: 6man <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 28 May 2020 07:05:14 +0000

Hi Erik,

Fully agree.

The idea was not to force ANY solution but to avoid “putting the cart before the horse”.

As I responded to Fred at https://mailarchive.ietf.org/arch/msg/ipv6/gyqvpfSkCt9fEZLdXnbrNjNOWg4/

Thanks

Regards … Zafar

From: Erik Kline <[email-masked]>
Date: Wednesday, May 27, 2020 at 5:40 PM
To: "Zafar Ali (zali)" <[email-masked]>
Cc: "Templin (US), Fred L" <[email-masked]>, Andrew Alston <[email-masked]>, Ron Bonica <[email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander Steffann <[email-masked]>, "[email-masked]" <[email-masked]>, 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali)
<zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

Fred,

Thanks

Regards … Zafar

Thanks - Fred

Thanks

Andrew

Zafar,

                                                                                             Ron

Thanks

Regards … Zafar

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 28 May 2020 13:32:54 +0000

Sometimes a known devil is better than an unknown one.

I think we need to be very careful in considering the introduction of a new label/ID mapping technology into IPv6 Routing and it's ramifications.

https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1

   The maximum 16-bit SID value is 65,535.  Because SIDs 0 through 15
   are reserved for future use, a 16-bit SID offers 65,520 usable
   values.

   The maximum 32-bit SID value is 4,294,967,295.  Because SIDs 0
   through 15 are reserved for future use, a 32-bit SID offers
   4,294,967,280 usable values.

This is the same as https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml

So is this, then in fact, an attempt to reinvent MPLS in a new avatar?

While some are talking about the CRH proposal as a brick, I see it as a tip of an iceberg. It is not just a new RH – it has significant impact across routing and ops areas. I would think one would expect a BoF for something like this? Therefore the request for proper documentation of the applicability, use-cases and architecture and their presentation (that too in the right areas/WGs) for the proper evaluation of this proposal.

Thanks,

Ketan

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) <zali=[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

There are actual, meaningful differences to be contemplated; folks with no operational MPLS in there networks might not want to be forced to start.

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

> To: Andrew Alston <[email-masked]<mailto:[email-masked]>>, Ron Bonica

> <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, "Zafar Ali (zali)"

> <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)"

> <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>

> As I said, I want to use CRH for OMNI and AERO; I don't want the term

> "MPLS" to appear

> either in my documents or in any documents mine cite. The 16-bit CRIDs

> in CRH are very

> handy for coding ULA Subnet Router Anycast addresses such as

> fd80::/16, fd81::/16,

> fd82::/16, etc., and the 32-bit CRIDs are very handy for coding the

> administrative address

> suffixes of fd80::/96. So, CRH gives everything I need (and nothing I

> don’t need) for

> To: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Zafar Ali

> (zali) <[email-masked]<mailto:[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp)

> <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>

> From: ipv6 <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica

> <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>

> To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, "Henderickx, Wim (Nokia -

> BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, Sander Steffann

> <[email-masked]<mailto:[email-masked]>>

> To: Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>;

> Sander Steffann <[email-masked]<mailto:[email-masked]>>

> Cc: Mach Chen <[email-masked]<mailto:[email-masked]>>; Ron Bonica

> <[email-masked]<mailto:[email-masked]>>; Chengli (Cheng Li) <[email-masked]<mailto:[email-masked]>>; 6man

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>

> People are reminding a long-standing practice of the IETF process.

> Before tackling a new piece of work, a working group must perform a

> due diligence on

> whether this new work is redundant with respect to existing IETF

> protocols, whether this new work would deliver genuine benefits and use-cases.

> fail to position CRH with respect to existing standard widely

> supported by the industry (e.g., RFC8663) fail to isolate new benefit

> or use-case [1]

> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8

> /

> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon

> t=true

> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg

> /

---

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

Zafar,

We want this for planes, trains and automobiles – all of them, worldwide. And, I am
not interested in looking at alternatives when I see exactly what I want in CRH. I want
an IPv6-only solution without having to introduce an adjunct service like MPLS.

The reason compressed format is so important is that the source and destination
of IPv6 packets that include a CRH may be behind a low-end wireless link (less than
1Mbps, and shared with many other users) and every bit we can conserve in the
transmission matters. We could define our own RH like was done for RH2 and RH3,
but then it would be a solution-specific code that might not find its way into widely
deployed network equipment and would not be a standard feature of commercial
routers.

So, yes, I support CRH for good reasons.

Fred

Sent: Wednesday, May 27, 2020 9:21 PM

Hi Fred,

Thanks

Regards … Zafar

To: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Andrew Alston <[email-masked]<mailto:[email-masked]>>, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]<mailto:[email-masked]>>, Sander Steffann <[email-masked]<mailto:[email-masked]>>

Hi Zafar,

Fred

From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Wednesday, May 27, 2020 2:20 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; Henderickx, Wim (Nokia - BE/Antwerp) <[email-masked]<mailto:[email-masked]>>; Sander Steffann <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Fred,

Thanks

Regards … Zafar

Thanks - Fred

Thanks

Andrew

Zafar,

                                                                                            Ron

Thanks

Regards … Zafar

---

From: Andrew Alston <[email-masked]>
Date: Thu, 28 May 2020 13:48:04 +0000

Let me quote Brian on this – because I think he said it better and more succinctly than I could in my own words.

Thanks

Andrew

From: spring <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Thursday, 28 May 2020 16:33
To: Erik Kline <[email-masked]>; Zafar Ali (zali) <zali=[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1<https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1>

This is the same as https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml>

Thanks,

Ketan

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8<https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8>

> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon<https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon>

> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg<https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg>

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 May 2020 16:13:19 +0200

Fred and others,

I think there is some confusion here among many people.

SR-MPLS is not LDP MPLS ... even though both can be used for transport.

Nearly 25 years after introduction of tag switching people are highly
confused what MPLS is. Most do not even understand that service MPLS and
transport MPLS can be decoupled. Yes over the years meaning of MPLS label
got severely overloaded.

So let me attempt to at least for those who what to understand explain the
case here under discussion.

SR-MPLS is no using MPLS service. In SR-MPLS node "labels" are domian wide
unique and all they carry is a 20 bit string where you map the string value
to a rewrite function.

This is functionally *exactly* the same as FID, MID, CRID, CRUD .... CRH
SID does as well. It is just with one difference - it is completely
incompatible with anything which was defined before.

There can be a lot of acronymous or names invented but under the hood it
16, 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped
to a rewrite string. No more no less. And rfc8663 precisely automated such
rewrite to UDP encapsulation.

Cheers,
R,

On Thu, May 28, 2020 at 3:47 PM Templin (US), Fred L <
[email-masked]> wrote:

> *From:* Zafar Ali (zali) [mailto:[email-masked]]
> *Sent:* Wednesday, May 27, 2020 9:21 PM
> *To:* Templin (US), Fred L <[email-masked]>; Andrew Alston <
> [email-masked]>; Ron Bonica <rbonica=
> [email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <
> [email-masked]>; Sander Steffann <[email-masked]>
> *Cc:* [email-masked]; 6man <[email-masked]>; Zafar Ali (zali) <
> [email-masked]>
> *From: *"Templin (US), Fred L" <[email-masked]>
> *Date: *Wednesday, May 27, 2020 at 5:53 PM
> *To: *"Zafar Ali (zali)" <[email-masked]>, Andrew Alston <
> [email-masked]>, Ron Bonica <
> rbonica=[email-masked]>, "Henderickx, Wim (Nokia -
> *Cc: *"[email-masked]" <[email-masked]>, 6man <[email-masked]>
> 1) Is there any IETF requirement document for OMNI and AERO (I am sorry I
> am not aware of the technology but very much interested in learning)?
>
>
>
> *From:* Zafar Ali (zali) [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, May 27, 2020 2:20 PM
> *To:* Templin (US), Fred L <[email-masked]>; Andrew Alston <
> [email-masked]>; Ron Bonica <
> rbonica=[email-masked]>; Henderickx, Wim (Nokia -
> BE/Antwerp) <[email-masked]>; Sander Steffann <
> [email-masked]>
> *Cc:* [email-masked]; 6man <[email-masked]>; Zafar Ali (zali) <
> [email-masked]>
> Is there any IETF requirement document for OMNI and AERO (I am sorry I am
> not aware of the technology but very much interested in learning)?
>
> All other routing header types have had requirements and designs from
> dedicated working groups with expertise in the area.
>
> *From: *"Templin (US), Fred L" <[email-masked]>
> *Date: *Wednesday, May 27, 2020 at 4:33 PM
> *To: *Andrew Alston <[email-masked]>, Ron Bonica <
> rbonica=[email-masked]>, "Zafar Ali (zali)" <[email-masked]>,
> "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>, Sander
> Steffann <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 6man <[email-masked]>
> *From:* ipv6 [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Andrew Alston
> *Sent:* Wednesday, May 27, 2020 1:19 PM
> *To:* Ron Bonica <rbonica=[email-masked]>; Zafar Ali (zali)
> <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <
> [email-masked]>; Sander Steffann <[email-masked]>
> *Cc:* [email-masked]; 6man <[email-masked]>
> *From: *ipv6 <[email-masked]> on behalf of Ron Bonica <
> rbonica=[email-masked]>

---

From: Sander Steffann <[email-masked]>
Date: Thu, 28 May 2020 16:58:16 +0200

Hi Robert,

> There can be a lot of acronymous or names invented but under the hood it 16, 32 or 20 bit opaque bit string in both CRH and SR-MPLS which is mapped to a rewrite string. No more no less.

So far so good

> And rfc8663 precisely automated such rewrite to UDP encapsulation.

And this is an important difference: some of us don't want encapsulation/tunneling, we want something that can be part of a non-encapsulated packet. There are use-cases where CRH used with encapsulating is the best solution, and there are cases where the packet itself can be steered without encapsulation. CRH allows both, and therefore covers more possible use-cases than RFC8663. This makes CRH a building block that some of us desire.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Thu, 28 May 2020 17:02:48 +0200

> And this is an important difference: some of us don't want encapsulation/tunneling, we want something that can be part of a non-encapsulated packet. There are use-cases where CRH used with encapsul…

PS: any IPv6 extension header can be replaced with one or more encapsulations. Even SRv6 can be implemented by encapsulating the packet separately for every segment, like the TOR network does. I don't buy the "you can already do this with encapsulation" argument. If that would become a valid argument then IPv6 innovation is dead.

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 28 May 2020 17:11:04 +0200

Hi,

All fine and your use case is valid. I never said it is not.

* But first it makes all those claims that solutions under discussion are
not to be used in Internet moot.

* Second you can use subset of SRH just fitted to your need end to end
without any encapsulation

* Last if I were you I would just use RbR idea I proposed and move on :)
Honestly since it uses plain old IPv6 FIB with just a little cli you could
find it actually may work fine on shipping hardware already. Is there
anything better then to meet your functionality without rolling in new
features and software ? Moreover make it work across any vendor and across
Internet ? Beats me why you guys keep arguing for pushing CRH.

Many thx,
Robert.

On Thu, May 28, 2020 at 4:58 PM Sander Steffann <[email-masked]> wrote:

> to a rewrite string. No more no less.
>
> So far so good
>
> And this is an important difference: some of us don't want
> encapsulation/tunneling, we want something that can be part of a
> non-encapsulated packet. There are use-cases where CRH used with
> encapsulating is the best solution, and there are cases where the packet
> itself can be steered without encapsulation. CRH allows both, and therefore
> covers more possible use-cases than RFC8663. This makes CRH a building
> block that some of us desire.
>
> Cheers,
> Sander
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 28 May 2020 15:13:25 +0000

Ketan,

Please take a look at the version of the draft that we are reviewing. Values 0-15 are no longer reserved.

                                         Ron

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant=[email-masked]>
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; 6man <[email-masked]>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-5.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-5.1__;Iw!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BMV7uEIv$>

This is the same as https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml<https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BOmRmTOF$>

While some are talking about the CRH proposal as a brick, I see it as a tip of an iceberg. It is not just a new RH - it has significant impact across routing and ops areas. I would think one would expect a BoF for something like this? Therefore the request for proper documentation of the applicability, use-cases and architecture and their presentation (that too in the right areas/WGs) for the proper evaluation of this proposal.

Thanks,

Ketan

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

> don't need) for

> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BCkxCAZs$>

> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BE3cPbDF$>

> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BNCmxwgB$>

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BBhsPHWV$>

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BBhsPHWV$>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 May 2020 12:27:33 -0400

Robert

SR-MPLS is not using MPLS “LDPv4” but is still using the MPLS data plane
“layer 2 1/2” 4 byte shim now a much larger label stack subject to MSD
(Maximum SID Depth) issues with long static lsp SR-TE paths.   SR-MPLS
still has the concept of FEC label binding but now just uses a different
range of 2 byte labels 16k-24k so is not overlapping with MPLS LDP default
label range.  With SR-MPLS since the data plan is “MPLS” you can run LDPv4
and SR-MPLS in parallel with SR-MPLS as an “overlay” so to speak which is
the beauty and power behind SR-MPLS for brown field deployments it’s a cake
walk to migrate from MPLS LDPv4 to SR-MPLS.

So SR variant “SR-MPLS” was given the name with “-MPLS” extension in SR
architecture RFC 8402 for that very reason.

To that end with SR-MPLS to support MVPN mLDP as is multipoint LDP is an
extension of LDP, you actually have to keep the LDPv4 intact but is not
preferred for unicast but is used for multicast.  As an aside their are
advantages of using for p-tree MVPN tunnel encapsulation instantiation
using mLDP as it uses inband pim c-signaling over p-ptree per tree state is
single PMSI-UI/MI inclusive tree.   In this scenario which is common for
brown field SR-MPLS deployments is that unicast used SR-MPLS and is
stateless, however multicast requires the stateful MPLS ldp mldp extension
mLDP.

Once BIER comes about or BESS BGP based trees is adopted and developed then
customers can eliminate  MPLS ldp.

Kind Regards

Gyan

On Thu, May 28, 2020 at 10:13 AM Robert Raszuk <[email-masked]> wrote:

>> *To:* Templin (US), Fred L <[email-masked]
>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>> *Cc:* spring@ietf..org <[email-masked]>; 6man <[email-masked]>; Zafar
>> Ali (zali) <[email-masked]>
>> rbonica=[email-masked]
>> <rbonica=[email-masked]>>, "Henderickx, Wim (Nokia -
>> BE/Antwerp)" <[email-masked] <[email-masked]>>,
> now crossing back over from ICAO into the IETF again..
>>
>
>>
>> *To:* Templin (US), Fred L <[email-masked]
>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>> *Cc:* spring@ietf..org <[email-masked]>; 6man <[email-masked]>; Zafar
>> Ali (zali) <[email-masked]>
>> "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]
>> <[email-masked]>>, Sander Steffann <[email-masked]>
>> *To:* Ron Bonica <rbonica=[email-masked]>; Zafar Ali
>> (zali) <[email-masked]>; Henderickx, Wim (Nokia - BE/Antwerp) <
>> *Cc:* spring@ietf..org <[email-masked]>; 6man <[email-masked]>
>> You have an multiple operators – who have clearly said – we want this –
>> we see advantage of this.  Yet still the obstructionism and denialism
>> Chengli (Cheng Li) <[email-masked]>; 6man <[email-masked]>;
>> [email-masked]; Zafar Ali (zali) <[email-masked]>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 28 May 2020 12:30:44 -0400

Sorry Typo 20 bit label not 2 byte label.

SR-MPLS still has the concept of FEC label binding but now just uses a
different range of 20 bit labels 16k-24k so is not overlapping with MPLS
LDP default label range.

Kind Regards

Gyan

On Thu, May 28, 2020 at 12:27 PM Gyan Mishra <[email-masked]> wrote:

> Once BIER comes about or BESS BGP based trees is adopted and developed
> then customers can eliminate  MPLS ldp.
>
>
> Kind Regards
>
> Gyan
>
>> So let me attempt to at least for those who what to understand explain
>> the case here under discussion.
>>
>> SR-MPLS is no using MPLS service. In SR-MPLS node "labels" are domian
>> wide unique and all they carry is a 20 bit string where you map the string
>> value to a rewrite function.
>>
>>> *Subject:* Re: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> Hi Fred,
>>>
>>>
>>>
>>> *Subject: *RE: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> Hi Zafar,
>>>
>>>
>>>
>>> 1) Is there any IETF requirement document for OMNI and AERO (I am sorry
>>> I am not aware of the technology but very much interested in learning)?
>>>
>>>
>>>
>>> *Subject:* Re: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> Fred,
>>>
>>>
>>>
>>> Is there any IETF requirement document for OMNI and AERO (I am sorry I
>>> rbonica=[email-masked]>, "Zafar Ali (zali)" <
>>> [email-masked]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <
>>> [email-masked] <[email-masked]>>, Sander Steffann <
>>> [email-masked]>
>>> *Subject: *RE: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> *Subject:* Re: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> Yet again – I support crh – I’ve deployed CRH – CRH works for us – and
>>> we still continue to support it.  And irrespective of if it is adopted –
>>> the development of it will continue – and it will exist – the only question
>>> is – do we end up with something that the market wants outside of the
>>> auspices of the IETF – or do we end up with something that is properly
>>> standardized, because this level of obstructionism will not prevent the
>>> development.
>>>
>>>
>>>
>>> *Subject: *RE: Long-standing practice of due-diligence is expected -
>>> Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint
>>> option?
>>>
>>>
>>>
>>> Zafar,
>>>
>>>
>>>
>>> Before tackling a new piece of work, a working group must perform a due
>>> diligence on
>>>

*Gyan Mishra*

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 29 May 2020 04:44:35 +0000

Sander, can you describe your use case. So far the only thing that people has asked CRH to do is steering and as mentioned we have solutions for those. If there are others, please share them..

On 28/05/2020, 16:58, "Sander Steffann" <[email-masked]> wrote:

    Hi Robert,

    So far so good

    Cheers,
    Sander

---

From: "qinfengwei" <[email-masked]>
Date: Fri, 29 May 2020 18:15:52 +0800

Hi,

         I really agree with Zafar. 

Thanks,

Fengwei Qin

发件人: spring [mailto:[email-masked]] 代表 Zafar Ali (zali)
发送时间: 2020年5月28日 03:19
收件人: Henderickx, Wim (Nokia - BE/Antwerp); Sander Steffann
抄送: [email-masked]; Mach Chen; Ron Bonica; 6man; Chengli (Cheng Li); Zafar Ali (zali)
主题: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks

Regards … Zafar 

[1]  <https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/> https://mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8/

[2]  <https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true> https://etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFont=true

[3]  <https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/> https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/

---

From: Sander Steffann <[email-masked]>
Date: Fri, 29 May 2020 15:15:20 +0200

Hi Wim,

> Sander, can you describe your use case. So far the only thing that people has asked CRH to do is steering and as mentioned we have solutions for those. If there are others, please share them..

Well, a routing header is obviously for steering, but not only encapsulated payloads need steering. A use case would be to steer control plane packets along a path. And because CRH works well together with existing headers it would be possible to provide a DO header for the named nodes along the path.

I can imagine using it for debugging as well, and I'm sure you can come up with more examples yourself.

Cheers,
Sander

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 29 May 2020 17:04:26 +0000

Hi Ron,

The problem that I see is that the draft that we are reviewing for adoption does not explain properly how CRH based IPv6 Source Routing works it's evaluation for WG adoption.

I do find some of those details in the SRm6 draft which uses CRH but based on your response, we should not be referring to it since it might be wrong or not updated? Also, that SRm6 solution is different and meant for Spring WG evaluation?

I would again request to please document the applicability, use-cases and explain how the mechanism works along with the CRH header specification. After all, we are considering a document for adoption and it is difficult to put together all the bits and pieces spread over hundreds of emails.

Thanks,
Ketan

From: Ron Bonica <rbonica=[email-masked]>
Sent: 28 May 2020 20:43
To: Ketan Talaulikar (ketant) <[email-masked]>; Erik Kline <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Cc: [email-masked]; 6man <[email-masked]>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Ketan,

                                         Ron

Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:ketant=[email-masked]>>
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Thanks,

Ketan

-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: Re: Long-standing practice of due-diligence is expected - Re: [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

On Wed, May 27, 2020 at 2:20 PM Zafar Ali (zali) <zali=[email-masked]<mailto:zali=[email-masked]>> wrote:

> https://etherpad.ietf..org:9009/p/notes-ietf-105-spring?useMonospaceFon<https://urldefense.com/v3/__https:/etherpad.ietf.org:9009/p/notes-ietf-105-spring?useMonospaceFon__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BE3cPbDF$>