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) <[email protected]>
Sent: Thursday, May 28, 2020 9:33 AM
To: Erik Kline <[email protected]>; Zafar Ali (zali) <[email protected]>
Cc: Ron Bonica <[email protected]>; [email protected]; 6man <[email protected]>
Subject: RE: 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]
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<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$>
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<https://urldefense.com/v3/__https:/www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BOmRmTOF$>
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 protected]<mailto:[email protected]>> On Behalf Of
Erik Kline
Sent: 28 May 2020 03:11
To: Zafar Ali (zali)
<[email protected]<mailto:[email protected]>>
Cc: Ron Bonica
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>; 6man
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> wrote:
>
> 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 protected]<mailto:[email protected]>>
> Date: Wednesday, May 27, 2020 at 4:33 PM
> To: Andrew Alston
> <[email protected]<mailto:[email protected]>>,
> Ron Bonica
> <[email protected]<mailto:[email protected]>>,
> "Zafar Ali (zali)"
> <[email protected]<mailto:[email protected]>>, "Henderickx, Wim (Nokia -
> BE/Antwerp)"
> <[email protected]<mailto:[email protected]>>, Sander Steffann
> <[email protected]<mailto:[email protected]>>
> Cc: "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>, 6man
> <[email protected]<mailto:[email protected]>>
> Subject: RE: Long-standing practice of due-diligence is expected - Re:
> [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
>
>
>
> 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 protected]] On Behalf Of Andrew Alston
> Sent: Wednesday, May 27, 2020 1:19 PM
> To: Ron Bonica
> <[email protected]<mailto:[email protected]>>;
> Zafar Ali
> (zali) <[email protected]<mailto:[email protected]>>; Henderickx, Wim (Nokia -
> BE/Antwerp)
> <[email protected]<mailto:[email protected]>>; Sander Steffann
> <[email protected]<mailto:[email protected]>>
> Cc: [email protected]<mailto:[email protected]>; 6man
> <[email protected]<mailto:[email protected]>>
> Subject: Re: Long-standing practice of due-diligence is expected - Re:
> [spring] CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
>
>
>
> 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 protected]<mailto:[email protected]>> on behalf of
> Ron Bonica
> <[email protected]<mailto:[email protected]>>
> Date: Wednesday, 27 May 2020 at 23:07
> To: "Zafar Ali (zali)" <[email protected]<mailto:[email protected]>>, "Henderickx,
> Wim (Nokia -
> BE/Antwerp)" <[email protected]<mailto:[email protected]>>,
> Sander Steffann
> <[email protected]<mailto:[email protected]>>
> Cc: 6man <[email protected]<mailto:[email protected]>>,
> "[email protected]<mailto:[email protected]>"
> <[email protected]<mailto:[email protected]>>
> 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.
>
>
>
> Why not let the marketplace decide whether it needs a CRH?
>
>
>
>
> Ron
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> From: Zafar Ali (zali) <[email protected]<mailto:[email protected]>>
> Sent: Wednesday, May 27, 2020 3:19 PM
> To: Henderickx, Wim (Nokia - BE/Antwerp)
> <[email protected]<mailto:[email protected]>>;
> Sander Steffann <[email protected]<mailto:[email protected]>>
> Cc: Mach Chen <[email protected]<mailto:[email protected]>>; Ron Bonica
> <[email protected]<mailto:[email protected]>>; Chengli (Cheng Li)
> <[email protected]<mailto:[email protected]>>; 6man
> <[email protected]<mailto:[email protected]>>;
> [email protected]<mailto:[email protected]>; Zafar Ali (zali)
> <[email protected]<mailto:[email protected]>>
> 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.
>
>
>
> 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
>
> whether this new work is redundant with respect to existing IETF
> protocols, 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.
>
> 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 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<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/W3gO-dni2tB4nG9e13QsJnjFgG8__;!!NEt6yMaO-gk!X7eh30RNBO_HHbLJLnDCFEUXyFBonh9051QycX-RgHzfzK8ogRMff7X5BCkxCAZs$>
> /
>
> [2]
> 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$>
> t=true
>
> [3]
> 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$>
> /
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]<mailto:[email protected]>
> 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$>
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]<mailto:[email protected]>
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$>
--------------------------------------------------------------------
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
