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

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 <robert@raszuk.net> 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 <
> Fred.L.Templin@boeing.com> 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:zali@cisco.com]
>> *Sent:* Wednesday, May 27, 2020 9:21 PM
>> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com
>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>> Andrew.Alston@liquidtelecom.com>; Ron Bonica <rbonica=
>> 40juniper.net@dmarc.ietf.org>; Henderickx, Wim (Nokia - BE/Antwerp) <
>> wim.henderickx@nokia.com>; Sander Steffann <sander@steffann.nl>
>> *Cc:* spring@ietf..org <spring@ietf.org>; 6man <6man@ietf.org>; Zafar
>> Ali (zali) <zali@cisco.com>
>> *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" <Fred.L.Templin@boeing.com>
>> *Date: *Wednesday, May 27, 2020 at 5:53 PM
>> *To: *"Zafar Ali (zali)" <zali@cisco.com>, Andrew Alston <
>> Andrew.Alston@liquidtelecom.com>, Ron Bonica <
>> rbonica=40juniper.net@dmarc.ietf.org
>> <rbonica=40juniper..net@dmarc.ietf.org>>, "Henderickx, Wim (Nokia -
>> BE/Antwerp)" <wim.henderickx@nokia.com <wim..henderickx@nokia.com>>,
>> Sander Steffann <sander@steffann.nl>
>> *Cc: *"spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
>> *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:zali@cisco.com <zali@cisco.com>]
>> *Sent:* Wednesday, May 27, 2020 2:20 PM
>> *To:* Templin (US), Fred L <Fred.L.Templin@boeing.com
>> <Fred.L.Templin@boeing..com>>; Andrew Alston <
>> Andrew.Alston@liquidtelecom.com>; Ron Bonica <
>> rbonica=40juniper.net@dmarc.ietf.org>; Henderickx, Wim (Nokia -
>> BE/Antwerp) <wim.henderickx@nokia.com>; Sander Steffann <
>> sander@steffann.nl>
>> *Cc:* spring@ietf..org <spring@ietf.org>; 6man <6man@ietf.org>; Zafar
>> Ali (zali) <zali@cisco.com>
>> *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" <Fred.L.Templin@boeing.com>
>> *Date: *Wednesday, May 27, 2020 at 4:33 PM
>> *To: *Andrew Alston <Andrew.Alston@liquidtelecom.com>, Ron Bonica <
>> rbonica=40juniper.net@dmarc.ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>,
>> "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com
>> <wim..henderickx@nokia.com>>, Sander Steffann <sander@steffann.nl>
>> *Cc: *"spring@ietf.org" <spring@ietf.org>, 6man <6man@ietf.org>
>> *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:ipv6-bounces@ietf.org <ipv6-bounces@ietf.org>] *On
>> Behalf Of *Andrew Alston
>> *Sent:* Wednesday, May 27, 2020 1:19 PM
>> *To:* Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; Zafar Ali
>> (zali) <zali@cisco.com>; Henderickx, Wim (Nokia - BE/Antwerp) <
>> wim.henderickx@nokia.com>; Sander Steffann <sander@steffann.nl>
>> *Cc:* spring@ietf..org <spring@ietf.org>; 6man <6man@ietf.org>
>> *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 <ipv6-bounces@ietf.org> on behalf of Ron Bonica <
>> rbonica=40juniper.net@dmarc.ietf.org>
>> *Date: *Wednesday, 27 May 2020 at 23:07
>> *To: *"Zafar Ali (zali)" <zali@cisco.com>, "Henderickx, Wim (Nokia -
>> BE/Antwerp)" <wim.henderickx@nokia.com>, Sander Steffann <
>> sander@steffann.nl>
>> *Cc: *6man <6man@ietf.org>, "spring@ietf.org" <spring@ietf.org>
>> *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) <zali@cisco.com>
>> *Sent:* Wednesday, May 27, 2020 3:19 PM
>> *To:* Henderickx, Wim (Nokia - BE/Antwerp) <wim.henderickx@nokia.com>;
>> Sander Steffann <sander@steffann.nl>
>> *Cc:* Mach Chen <mach.chen@huawei.com>; Ron Bonica <rbonica@juniper.net>;
>> Chengli (Cheng Li) <c.l@huawei.com>; 6man <6man@ietf.org>;
>> spring@ietf.org; Zafar Ali (zali) <zali@cisco.com>
>> *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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> 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