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 protected]> 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 <[email protected]> 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 < >> [email protected]> 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:[email protected]] >>> *Sent:* Wednesday, May 27, 2020 9:21 PM >>> *To:* Templin (US), Fred L <[email protected] >>> <[email protected]>>; Andrew Alston < >>> [email protected]>; Ron Bonica <rbonica= >>> [email protected]>; Henderickx, Wim (Nokia - BE/Antwerp) < >>> [email protected]>; Sander Steffann <[email protected]> >>> *Cc:* [email protected] <[email protected]>; 6man <[email protected]>; Zafar >>> Ali (zali) <[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? >>> >>> >>> >>> 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" <[email protected]> >>> *Date: *Wednesday, May 27, 2020 at 5:53 PM >>> *To: *"Zafar Ali (zali)" <[email protected]>, Andrew Alston < >>> [email protected]>, Ron Bonica < >>> [email protected] >>> <[email protected]>>, "Henderickx, Wim (Nokia - >>> BE/Antwerp)" <[email protected] <[email protected]>>, >>> Sander Steffann <[email protected]> >>> *Cc: *"[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? >>> >>> >>> >>> 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 protected] <[email protected]>] >>> *Sent:* Wednesday, May 27, 2020 2:20 PM >>> *To:* Templin (US), Fred L <[email protected] >>> <[email protected]>>; Andrew Alston < >>> [email protected]>; Ron Bonica < >>> [email protected]>; Henderickx, Wim (Nokia - >>> BE/Antwerp) <[email protected]>; Sander Steffann < >>> [email protected]> >>> *Cc:* [email protected] <[email protected]>; 6man <[email protected]>; Zafar >>> Ali (zali) <[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? >>> >>> >>> >>> 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]> >>> *Date: *Wednesday, May 27, 2020 at 4:33 PM >>> *To: *Andrew Alston <[email protected]>, Ron Bonica < >>> [email protected]>, "Zafar Ali (zali)" < >>> [email protected]>, "Henderickx, Wim (Nokia - BE/Antwerp)" < >>> [email protected] <[email protected]>>, Sander Steffann < >>> [email protected]> >>> *Cc: *"[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? >>> >>> >>> >>> 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] <[email protected]>] *On >>> Behalf Of *Andrew Alston >>> *Sent:* Wednesday, May 27, 2020 1:19 PM >>> *To:* Ron Bonica <[email protected]>; Zafar Ali >>> (zali) <[email protected]>; Henderickx, Wim (Nokia - BE/Antwerp) < >>> [email protected]>; Sander Steffann <[email protected]> >>> *Cc:* [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? >>> >>> >>> >>> 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]> on behalf of Ron Bonica < >>> [email protected]> >>> *Date: *Wednesday, 27 May 2020 at 23:07 >>> *To: *"Zafar Ali (zali)" <[email protected]>, "Henderickx, Wim (Nokia - >>> BE/Antwerp)" <[email protected]>, Sander Steffann < >>> [email protected]> >>> *Cc: *6man <[email protected]>, "[email protected]" <[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]> >>> *Sent:* Wednesday, May 27, 2020 3:19 PM >>> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <[email protected]>; >>> Sander Steffann <[email protected]> >>> *Cc:* Mach Chen <[email protected]>; Ron Bonica <[email protected]>; >>> Chengli (Cheng Li) <[email protected]>; 6man <[email protected]>; >>> [email protected]; Zafar Ali (zali) <[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 >>> >>> 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 >>> [email protected] >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> _______________________________________________ >> spring mailing list >> [email protected] >> 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
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
