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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> wrote:

>
> 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 <[e-mail]> wrote:
>
>> 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 <
>> [e-mail]> wrote:
>>
>>> 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
>>>
>>>
>>>
>> *From:* Zafar Ali (zali) [mailto:[e-mail]]
>>> *Sent:* Wednesday, May 27, 2020 9:21 PM
>>> *To:* Templin (US), Fred L <[e-mail]
>>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>>> [e-mail]>; Ron Bonica <rbonica=
>>> [e-mail]>; Henderickx, Wim (Nokia - BE/Antwerp) <
>>> [e-mail]>; Sander Steffann <[e-mail]>
>>> *Cc:* spring@ietf..org <[e-mail]>; 6man <[e-mail]>; Zafar
>>> Ali (zali) <[e-mail]>
>>> *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,
>>>
>>>
>>>
>>> MANY thanks for your follow-up – much appreciated.
>>>
>>>
>>>
>>> >  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,
>>>
>>>
>>>
>>> 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" <[e-mail]>
>>> *Date: *Wednesday, May 27, 2020 at 5:53 PM
>>> *To: *"Zafar Ali (zali)" <[e-mail]>, Andrew Alston <
>>> [e-mail]>, Ron Bonica <
>>> rbonica=[e-mail]
>>> <rbonica=[e-mail]>>, "Henderickx, Wim (Nokia -
>>> BE/Antwerp)" <[e-mail] <[e-mail]>>,
>>> Sander Steffann <[e-mail]>
>>> *Cc: *"[e-mail]" <[e-mail]>, 6man <[e-mail]>
>>> *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)?
>>>
>>>
>>>
>>> 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:[e-mail] <[e-mail]>]
>>> *Sent:* Wednesday, May 27, 2020 2:20 PM
>>> *To:* Templin (US), Fred L <[e-mail]
>>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>>> [e-mail]>; Ron Bonica <
>>> rbonica=[e-mail]>; Henderickx, Wim (Nokia -
>>> BE/Antwerp) <[e-mail]>; Sander Steffann <
>>> [e-mail]>
>>> *Cc:* spring@ietf..org <[e-mail]>; 6man <[e-mail]>; Zafar
>>> Ali (zali) <[e-mail]>
>>> *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
>>> 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" <[e-mail]>
>>> *Date: *Wednesday, May 27, 2020 at 4:33 PM
>>> *To: *Andrew Alston <[e-mail]>, Ron Bonica <
>>> rbonica=[e-mail]>, "Zafar Ali (zali)" <
>>> [e-mail]>, "Henderickx, Wim (Nokia - BE/Antwerp)" <
>>> [e-mail] <[e-mail]>>, Sander Steffann <
>>> [e-mail]>
>>> *Cc: *"[e-mail]" <[e-mail]>, 6man <[e-mail]>
>>> *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:[e-mail] <[e-mail]>] *On
>>> Behalf Of *Andrew Alston
>>> *Sent:* Wednesday, May 27, 2020 1:19 PM
>>> *To:* Ron Bonica <rbonica=[e-mail]>; Zafar Ali
>>> (zali) <[e-mail]>; Henderickx, Wim (Nokia - BE/Antwerp) <
>>> [e-mail]>; Sander Steffann <[e-mail]>
>>> *Cc:* spring@ietf..org <[e-mail]>; 6man <[e-mail]>
>>> *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 <[e-mail]> on behalf of Ron Bonica <
>>> rbonica=[e-mail]>
>>> *Date: *Wednesday, 27 May 2020 at 23:07
>>> *To: *"Zafar Ali (zali)" <[e-mail]>, "Henderickx, Wim (Nokia -
>>> BE/Antwerp)" <[e-mail]>, Sander Steffann <
>>> [e-mail]>
>>> *Cc: *6man <[e-mail]>, "[e-mail]" <[e-mail]>
>>> *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) <[e-mail]>
>>> *Sent:* Wednesday, May 27, 2020 3:19 PM
>>> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <[e-mail]>;
>>> Sander Steffann <[e-mail]>
>>> *Cc:* Mach Chen <[e-mail]>; Ron Bonica <[e-mail]>;
>>> Chengli (Cheng Li) <[e-mail]>; 6man <[e-mail]>;
>>> [e-mail]; Zafar Ali (zali) <[e-mail]>
>>> *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
>>>
>>>    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/
>>> <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$>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> --------------------------------------------------------------------
>>
>>
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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