Re: Header Insertion and TI-FA

Mark Smith <markzzzsmith@gmail.com> Tue, 12 May 2020 21:52 UTC

Return-Path: <markzzzsmith@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 3819E3A0C28 for <ipv6@ietfa.amsl.com>; Tue, 12 May 2020 14:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IA5dwGsyM28r for <ipv6@ietfa.amsl.com>; Tue, 12 May 2020 14:52:57 -0700 (PDT)
Received: from mail-oo1-xc2f.google.com (mail-oo1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 1FA633A0C26 for <6man@ietf.org>; Tue, 12 May 2020 14:52:57 -0700 (PDT)
Received: by mail-oo1-xc2f.google.com with SMTP id t3so3041498oou.8 for <6man@ietf.org>; Tue, 12 May 2020 14:52:57 -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:content-transfer-encoding; bh=NMyxfl9eH+5crLoXs/0zN6MArE26fKJi/IXs9HlD3xY=; b=MnqofoIPEWU/8hpxTMJB7I3LK696h8C4Nk9aYl/icToaMEd7PZ/RDOck7/gvoqKhUi ZW6N7lAvRrhubSPmPHut4Q1wvrsm2D0F+/jsQt2Dgq3m0Szz2wJuYuKrmwasEokQ/BVQ W2ikec9kNQqFFL6ejQzbkRec/tepokpk3yKkCIaQG26WU2gOM/dyvgz4+rjTt3TxXBWg speqnWhe7m8zj11LtWxe5t9OBmTaNvq2TdwJ/eBIny8EPtLzt72bd2yr7ixDjZOk1a1+ JPSRoP3cSzuHrAxh5Vd5qbuVKw1c9Xkq2YaIpejCom+szkoxRRsimDCz/4gzjo66z4XT eoCQ==
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:content-transfer-encoding; bh=NMyxfl9eH+5crLoXs/0zN6MArE26fKJi/IXs9HlD3xY=; b=eLzFX3+ACD0YH1wgbwlmiManP6c7AgFWx0iTyqu3f5josOfLxmVnr1sgwt5TRR/ANW bb2G5HT/yZzZlcWEFVARW56hUETy/p/EAL9pnnlJ+pjLZmID305zB/rt5uAqww2TvYbc bSb1QIu//vupysirJalmD9QuY3bEr54DWFXD5b8Im067ywqwCnmLLie+/z1YlV4oEpdh fIBJHEYpVeWw3x73H9pLkuU2wJpbcGbOdO+1clKziXWqetj/Ev8EinPVs3jC9rJ0vwiB 75QGeHj07w+4ujANkyA6p0I1X7w+vbJegjgFdcTABheN6HHHNh6TfvXca0Kg5SESPvtN 0EuQ==
X-Gm-Message-State: AGi0PuZ+aMJBlT8JJu3Jv5UEv5iz/We0DrEZnix2vvMba+JAPCbCv4/U ZIVlYJZOoRFVTUkJNd+n+XZ/zOEdGnZiOHaNKvs=
X-Google-Smtp-Source: APiQypJfGg2EuUJyIavMiAtVn0kgmLwa9fZro4tHE/lSo05zYgghreH3VcYVRgYJDCTyHDmYwTExuwgCdHdGBxlpDjQ=
X-Received: by 2002:a05:6820:279:: with SMTP id c25mr11873643ooe.93.1589320375764; Tue, 12 May 2020 14:52:55 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR05MB6348FA1FC00258ACE4FDE444AEA10@DM6PR05MB6348.namprd05.prod.outlook.com> <CABNhwV3-dMPg6SAAEz+uWre-rj6j5=1JgyyQyKyz_qn7f7mJwQ@mail.gmail.com> <DM6PR05MB634848D379A428372C166DD4AEA10@DM6PR05MB6348.namprd05.prod.outlook.com> <CAOj+MMEBVA+yK9cFXSe=GVUeH01ipi++nwCRQU_nQCxsKhyvRg@mail.gmail.com> <1B1A2C98-20F0-43F8-A299-C839D14A245C@gmail.com> <CABNhwV3m+2+Wt2CHRRhznEvTZ5KQdounv0e=icfbs4VOcoU0Rw@mail.gmail.com> <MWHPR11MB13740F8547CF700EC38CE4F5C9A10@MWHPR11MB1374.namprd11.prod.outlook.com> <61DBEBF4-ACE7-40D6-B172-EF46B35BC838@liquidtelecom.com> <MWHPR11MB137441AE7513EAA1894EDB9FC9BE0@MWHPR11MB1374.namprd11.prod.outlook.com> <6b4ae543-5359-795b-84a0-49f5be3045a2@gmail.com>
In-Reply-To: <6b4ae543-5359-795b-84a0-49f5be3045a2@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Wed, 13 May 2020 07:52:29 +1000
Message-ID: <CAO42Z2xwPZhkFL6Zqks+cBNFQAoBLjGF_bx7uW6WzaOXbUMjtA@mail.gmail.com>
Subject: Re: Header Insertion and TI-FA
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org>, Andrew Alston <Andrew.Alston@liquidtelecom.com>, "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/w1RyuZAwEc-zoaHPOCNx48B7Nng>
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: Tue, 12 May 2020 21:52:59 -0000

On Wed, 13 May 2020 at 06:40, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
>
> Pablo,
>
> Yes, the IETF is not the Protocol Police. Interpol will not issue Red Notices for us. Any company can sell products that deviate from IETF standards, and any customer can buy them.
>
> However, many customers do not wish to buy products that will not interoperate with other products. As the histories of SNA, DECnet, Netware, Banyan Vines, and Appletalk show, proprietary networking solutions only last as long as the vendor's monopoly.
>

I've worked on a networks that were running a number of those
protocols, which was about the time "open systems" and movement to
non-proprietary protocols was occurring. Getting away from being
locked into a single vendor was the motivation.

All this "we want to be able to do what we like in a limited domain"
seems to me that it might be recreating the opportunity for being
locked into a single vendor who has their own proprietary "limited
domain" version of IPv6. You might get fooled because you think you're
buying IPv6 when you're actually not.

Regards,
Mark.


> We have a mechanism for documenting proprietary protocols, and it is not the IETF Stream of RFCs.
>
> Regards
>    Brian Carpenter
>
> On 13-May-20 03:26, Pablo Camarillo (pcamaril) wrote:
> > Hi Andrew,
> >
> >
> >
> > Cisco has demonstrated TILFA with SRH insertion at EANTC-2019. http://www.eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
> >
> >
> >
> > This feature is available to all customers -supported since XR 6.6.1-.. Please contact your Cisco account team if you want further details on cisco products or need assistance.
> >
> >
> >
> > Thank you,
> >
> > Pablo.
> >
> >
> >
> > *From:*Andrew Alston <Andrew.Alston@liquidtelecom.com>
> > *Sent:* lunes, 11 de mayo de 2020 22:04
> > *To:* Pablo Camarillo (pcamaril) <pcamaril@cisco.com>; Gyan Mishra <hayabusagsm@gmail.com>
> > *Cc:* 6man@ietf.org
> > *Subject:* Re: Header Insertion and TI-FA
> >
> >
> >
> > Hi Pablo,
> >
> >
> >
> > While I fully realize that running code is not mandatory in the IETF – there have been numerous assertions about what is harmful and not harmful etc, and coupled with the deployment draft, I presume there is running code from the perspective of the authors..
> >
> >
> >
> > Would you be prepared to disclose the release of code where SRH and this functionality is actually implemented – since I’d like to run a series of verification tests against it to test the effects on my network and I’m sure others would be interested in doing the same.  I can also then test against the Juniper implementation as tested at the EANTC and run my own inter-op tests and test the real effects this has on the network in a manner that makes sense.
> >
> >
> >
> > Obviously however testing against a single vendor code is not ideal – and since the assertions are being made and in light of the deployment draft – I am figuring that you must actually have running code that is in the field? (I know on all code versions I have tested that are GA I have yet to see any SRH on any packet capture that I have done – hence I have been unable to do any verification testing myself against the claims made)
> >
> >
> >
> > Thanks
> >
> >
> >
> > Andrew
> >
> >
> >
> >
> >
> > *From: *ipv6 <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> on behalf of "Pablo Camarillo (pcamaril)" <pcamaril=40cisco.com@dmarc.ietf.org <mailto:pcamaril=40cisco.com@dmarc.ietf.org>>
> > *Date: *Monday, 11 May 2020 at 20:13
> > *To: *Gyan Mishra <hayabusagsm@gmail.com <mailto:hayabusagsm@gmail.com>>
> > *Cc: *"6man@ietf.org <mailto:6man@ietf.org>" <6man@ietf.org <mailto:6man@ietf.org>>
> > *Subject: *RE: Header Insertion and TI-FA
> >
> >
> >
> > Gyan,
> >
> >
> >
> > SRH insertion is NOT part of draft-ietf-spring-srv6-network-programming-15.
> >
> > (SRH insertion is documented in draft-filsfils-spring-srv6-net-pgm-insertion-02 with a normative reference to draft-voyer-6man-extension-header-insertion-08).
> >
> >
> >
> >> Spring - Please provide section within PGM that has the verbiage of the 6in6 encapsulation
> >
> >
> >
> > This is already in the net-pgm draft (since rev 00). Please see https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-15#section-5 .
> >
> >
> >
> > Thanks,
> >
> > Pablo.
> >
> >
> >
> > *From:*ipv6 <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>> *On Behalf Of *Gyan Mishra
> > *Sent:* lunes, 11 de mayo de 2020 18:02
> > *To:* Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>>
> > *Cc:* Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org <mailto:rbonica=40juniper.net@dmarc.ietf.org>>; 6man <6man@ietf.org <mailto:6man@ietf.org>>
> > *Subject:* Re: Header Insertion and TI-FA
> >
> >
> >
> >
> >
> > Krzysztof
> >
> >
> >
> > So you agree with what I stated as the workaround.
> >
> >
> >
> > Please read through exactly what I stated as the complete workaround.
> >
> >
> >
> > If we are all in agreement with the prepend (6in6) encap) workaround can we have the PGM draft updated to reflect.
> >
> >
> >
> > All
> >
> >
> >
> > With regards to the 6MAN appeal,  the issues were PSP and this issue with TI-LFA from what I recall.
> >
> >
> >
> > Was their any other issue outside of these two mentioned in the appeal that we need to address and come up with a workaround?
> >
> >
> >
> > Thank you
> >
> >
> >
> > Gyan
> >
> >
> >
> > On Mon, May 11, 2020 at 11:09 AM Krzysztof Szarkowicz <kszarkowicz@gmail.com <mailto:kszarkowicz@gmail.com>> wrote:
> >
> >     Hi Robert,
> >
> >     If we have prepend, why bother with insertion at all? Prepend (6in6 encap) is much cleaner, IMHO.
> >
> >     Regards,
> >     Krzysztof
> >
> >     > On 2020 -May-11, at 16:38, Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
> >     >
> >     > Hi Ron,
> >     >
> >     > > normalizing header insertion for the special case where the PLR is a segment endpoint
> >     >
> >     > When an operator is serious about good data plane protection with TI-LFA all nodes in the network will be enabled for SR. The less overhead required for the protection the better. You may just not have a room for adding additional 40 bytes to each packet at each potential PLR without fragmentation.
> >     >
> >     > Regarding all of your other TI-LFA related questions - I am sure Krzysztof will be happy to answer them for you internally :)  After all this is what your public demo was all about ....
> >     >
> >     > Best,
> >     > Robert,
> >     >
> >     > --------------------------------------------------------------------
> >     > IETF IPv6 working group mailing list
> >     > ipv6@ietf.org <mailto:ipv6@ietf.org>
> >     > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     > --------------------------------------------------------------------
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     ipv6@ietf.org <mailto:ipv6@ietf.org>
> >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >     --------------------------------------------------------------------
> >
> > --
> >
> > Gyan  Mishra
> >
> > Network Engineering & Technology
> >
> > Verizon
> >
> > Silver Spring, MD 20904
> >
> > Phone: 301 502-1347
> >
> > Email: gyan.s.mishra@verizon.com <mailto:gyan.s.mishra@verizon.com>
> >
> >
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------