Re: [Idr] draft-ietf-idr-tunnel-encaps

<bruno.decraene@orange.com> Tue, 26 November 2019 16:30 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51E4120997; Tue, 26 Nov 2019 08:30:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level:
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 hiYmQEHdxXrw; Tue, 26 Nov 2019 08:30:19 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1BC120989; Tue, 26 Nov 2019 08:30:19 -0800 (PST)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 47MqBd5NxRz8sd2; Tue, 26 Nov 2019 17:30:17 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 47MqBd41L8zCqkR; Tue, 26 Nov 2019 17:30:17 +0100 (CET)
Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Tue, 26 Nov 2019 17:30:17 +0100
From: <bruno.decraene@orange.com>
To: John Scudder <jgs@juniper.net>
CC: "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, idr wg <idr@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>
Thread-Topic: draft-ietf-idr-tunnel-encaps
Thread-Index: AdWkbffsrLIMj4YkS+S+IQcrwqTqKQABocCAAAAtQ7A=
Date: Tue, 26 Nov 2019 16:30:16 +0000
Message-ID: <21491_1574785817_5DDD5319_21491_226_1_53C29892C857584299CBF5D05346208A48D0C02C@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <16327_1574782681_5DDD46D9_16327_358_1_53C29892C857584299CBF5D05346208A48D0BCB7@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <70DDBF22-5DB4-4718-A411-BBD3B3D0BA02@juniper.net>
In-Reply-To: <70DDBF22-5DB4-4718-A411-BBD3B3D0BA02@juniper.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48D0C02COPEXCAUBM43corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/WR2NRpDrrcCpZV0_WQFikyzKT50>
Subject: Re: [Idr] draft-ietf-idr-tunnel-encaps
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Nov 2019 16:30:22 -0000

I was trying to suggest a smaller change, more specifically the following change:



OLD : each TLV is either a "Label-
   Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
   SRGB (Source Routing Global Block)" TLV.


NEW: each TLV is either a "Label-
   Index" TLV, or an "Originator
   SRGB (Source Routing Global Block)" TLV.


I could not find other reference to SRv6 SID or dependency on SRv6 so that simple change looks a priori safe.

However I have not re-read the whole draft, so I’m just raising the issue for the authors to fix.

Thanks,
--Bruno

From: John Scudder [mailto:jgs@juniper.net]
Sent: Tuesday, November 26, 2019 5:14 PM
To: DECRAENE Bruno TGI/OLN
Cc: draft-ietf-idr-tunnel-encaps@ietf.org; idr wg; Alvaro Retana
Subject: Re: draft-ietf-idr-tunnel-encaps

So we would remove Section 3.7 plus the few references to it elsewhere in the document? That seems fine, thanks for catching this. We also get to eliminate a normative reference dependency. :-)

IDR WG, if anyone has an objection, please raise it — but it seems like an open-and-shut case.

Thanks,

—John


On Nov 26, 2019, at 10:38 AM, bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> wrote:

Hi authors,
Cc’ing John and Alvaro as the document has left IDR WG.

TL;DR: I think that you should remove “an "IPv6 SID (Segment Identifier)" TLV,”

https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-14#section-3.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-14*section-3.7__;Iw!8WoA6RjC81c!VsJ456XB1LS-76ORABaTDwi2kEMtkvSglVu1GBspWDKTjkG7UKKk9Dn1oAQ_sg$> says:

   [I-D.ietf-idr-bgp-prefix-sid] defines a BGP Path attribute known as
   the "Prefix-SID Attribute".  This attribute is defined to contain a
   sequence of one or more TLVs, where each TLV is either a "Label-
   Index" TLV, an "IPv6 SID (Segment Identifier)" TLV, or an "Originator
   SRGB (Source Routing Global Block)" TLV.


Actually latest version of [I-D.ietf-idr-bgp-prefix-sid] has removed the support for "IPv6 SID (Segment Identifier)" TLV


The value 2 previously corresponded to the IPv6 SID TLV which was

   specified in previous versions of this document.  It was removed and

   usage of the BGP Prefix-SID for Segment Routing over the IPv6

   dataplane [I-D.ietf-spring-segment-routing<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-27*ref-I-D.ietf-spring-segment-routing__;Iw!8WoA6RjC81c!VsJ456XB1LS-76ORABaTDwi2kEMtkvSglVu1GBspWDKTjkG7UKKk9DkVu8hmCg$>] has been deferred to

   future specifications.
https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-27#section-7<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-27*section-7__;Iw!8WoA6RjC81c!VsJ456XB1LS-76ORABaTDwi2kEMtkvSglVu1GBspWDKTjkG7UKKk9DlPf85KuQ$>


Best regards,
--Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.