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 <hayabusagsm@gmail.com> Thu, 28 May 2020 16:31 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FBD3A0EC7; Thu, 28 May 2020 09:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZIAXWLe8LHl; Thu, 28 May 2020 09:30:56 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FDA3A0EC8; Thu, 28 May 2020 09:30:56 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id y18so10245899iow.3; Thu, 28 May 2020 09:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XOmVV06RclEJy2iO6L7vQBYJUqXCbWz6/z6xYC8BJ6Y=; b=BT1Nq+7IFIXuooN8uqme1kDXLkmnLiVU40F0rsqqVjcTWqbWjoabD6F7A97/4d0oS7 fqbspdGcRzjNJv5FIV3K5CrS9DRYN3PLKpxWG9fwVawrG653B3J5kvj2O1/C1i/3J7dO 9mav2gR/BYblIE7btgseYqUzCjnVWmH4ImC66pRcqNeFkKsHGzaNnRzJd++Fa5iaTYCQ GEpohHjN5k6/ips0T+tvezL1rOY2EZkf8JBkjsHaLm1upxSy12QCO8GupTM3K2HEYZ1h psp3bO9+oLILmS/Eh8ZRMgBXnxnye7CsbyL9yuCFkNlXEvbWFoSZKjz2RwEuS6DYXA5T /xPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XOmVV06RclEJy2iO6L7vQBYJUqXCbWz6/z6xYC8BJ6Y=; b=c56hTNticVpgvOH9I6dwjIry8SV28084+2TwXe5vF0lrWKWPsHaE/KUheKgkWSgdub twuJTjfYSxjbKeACDF5IjcmxPL9f8sPCSEpA23uZdchKIQTzllCbXAoceU85PdoWulqp CqXYXRlXbljIcGBdtzsuu3yJnBaThu5BLLVP/TyRUzzcpAq4sjhzTQ/iyES2u5t8A5+/ VnYgWreR0FHvxsO2zM3VDhmyYsh4cciyYn/6T45T5f2b0APIqq6OJ7ohIGiwPhnsYkqA sy5tAAc8djm2X/NZEnH2BkaUlC8cEZxWGqqfEPZqXIiY6KqeMCqwgJXMAdhNB3agLEHk m9oA==
X-Gm-Message-State: AOAM533xK4KBGtdAV7OIxNJDmd29l86iqucVeJbkPxEDbZovyi9J9x8l ZK01fGgP3L2f/CbkHeu/8GKs1sU3jNMQKp+ndaY=
X-Google-Smtp-Source: ABdhPJw8raBwQKaEc4BqXlidEQyCLrHjQ3241E4MwtCxbXaO1q8c2cQe7YVMIAzKEd8ZY0Gm/NaNX+bnbney1oSnkHE=
X-Received: by 2002:a6b:e60e:: with SMTP id g14mr3028554ioh.141.1590683454935; Thu, 28 May 2020 09:30:54 -0700 (PDT)
MIME-Version: 1.0
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <64e6b98b01c64ec8b699c065bc7ee9e0@boeing.com> <94DF5577-4DCC-4491-A12B-21EAC214172F@cisco.com> <aa7edfd5c56b4e2883e2e91649fc6061@boeing.com> <7A3F2E3E-687F-4C53-B1F9-1BF593356384@cisco.com> <45de95803b734d73a0288a09332c445f@boeing.com> <CAOj+MMH-1RbicwqHVueeokRq-FNm2QWkyCQXuyZdR2xFvdh13g@mail.gmail.com> <CABNhwV3=P77-UMXPh7==3Ubs+WvXr2Kge_cKy9uSxHjrnGPUQw@mail.gmail.com>
In-Reply-To: <CABNhwV3=P77-UMXPh7==3Ubs+WvXr2Kge_cKy9uSxHjrnGPUQw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 28 May 2020 12:30:44 -0400
Message-ID: <CABNhwV1Qb9WusuV_6qnNy2p9KLiEvm+YUX5NTn8vcnU9HXh1DA@mail.gmail.com>
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
To: Robert Raszuk <robert@raszuk.net>
Cc: 6man <6man@ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Sander Steffann <sander@steffann.nl>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "Zafar Ali (zali)" <zali@cisco.com>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004817f805a6b7da99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/-BjFTlQAsMh7wdSQSrjOG4AKqF4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 16:31:01 -0000

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 <hayabusagsm@gmail.com> 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 <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>gt;; Ron Bonica <rbonica=
>>> 40juniper.net@dmarc.ietf.org>gt;; Henderickx, Wim (Nokia - BE/Antwerp) <
>>> wim.henderickx@nokia.com>gt;; Sander Steffann <sander@steffann.nl>
>>> *Cc:* spring@ietf..org <spring@ietf.org>rg>; 6man <6man@ietf.org>rg>; 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>om>, Andrew Alston <
>>> Andrew.Alston@liquidtelecom.com>gt;, Ron Bonica <
>>> rbonica=40juniper.net@dmarc.ietf.org
>>> <rbonica=40juniper..net@dmarc.ietf.org>>g>>, "Henderickx, Wim (Nokia -
>>> BE/Antwerp)" <wim.henderickx@nokia.com <wim..henderickx@nokia.com>>m>>,
>>> Sander Steffann <sander@steffann.nl>
>>> *Cc: *"spring@ietf.org" <spring@ietf.org>rg>, 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>gt;; Ron Bonica <
>>> rbonica=40juniper.net@dmarc.ietf.org>gt;; Henderickx, Wim (Nokia -
>>> BE/Antwerp) <wim.henderickx@nokia.com>om>; Sander Steffann <
>>> sander@steffann.nl>
>>> *Cc:* spring@ietf..org <spring@ietf.org>rg>; 6man <6man@ietf.org>rg>; 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>om>, Ron Bonica <
>>> rbonica=40juniper.net@dmarc.ietf.org>gt;, "Zafar Ali (zali)" <
>>> zali@cisco.com>gt;, "Henderickx, Wim (Nokia - BE/Antwerp)" <
>>> wim.henderickx@nokia.com <wim..henderickx@nokia.com>>m>>, Sander Steffann <
>>> sander@steffann.nl>
>>> *Cc: *"spring@ietf.org" <spring@ietf.org>rg>, 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>rg>; Zafar Ali
>>> (zali) <zali@cisco.com>om>; Henderickx, Wim (Nokia - BE/Antwerp) <
>>> wim.henderickx@nokia.com>gt;; Sander Steffann <sander@steffann.nl>
>>> *Cc:* spring@ietf..org <spring@ietf.org>rg>; 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>om>, "Henderickx, Wim (Nokia -
>>> BE/Antwerp)" <wim.henderickx@nokia.com>om>, Sander Steffann <
>>> sander@steffann.nl>
>>> *Cc: *6man <6man@ietf.org>rg>, "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>om>;
>>> Sander Steffann <sander@steffann.nl>
>>> *Cc:* Mach Chen <mach.chen@huawei.com>om>; Ron Bonica <rbonica@juniper.net>et>;
>>> Chengli (Cheng Li) <c.l@huawei.com>om>; 6man <6man@ietf.org>rg>;
>>> 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
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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