Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols

<bruno.decraene@orange.com> Tue, 10 October 2017 07:08 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2996C13488E; Tue, 10 Oct 2017 00:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EzQ-qr-y6oV7; Tue, 10 Oct 2017 00:08:15 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD7213495F; Tue, 10 Oct 2017 00:03:20 -0700 (PDT)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 6E131604A9; Tue, 10 Oct 2017 09:03:18 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4A8891801BD; Tue, 10 Oct 2017 09:03:18 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0361.001; Tue, 10 Oct 2017 09:03:17 +0200
From: <bruno.decraene@orange.com>
To: Chris Bowers <cbowers@juniper.net>, "draft-hegde-isis-advertising-te-protocols@ietf.org" <draft-hegde-isis-advertising-te-protocols@ietf.org>
CC: "isis-chairs@ietf.org" <isis-chairs@ietf.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>
Thread-Topic: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
Thread-Index: AQHTPxYBi65FR5sgtkeDLmCrCiW0xqLblqcAgAAZv7CAAPzFkA==
Date: Tue, 10 Oct 2017 07:03:17 +0000
Message-ID: <11287_1507618998_59DC70B6_11287_100_1_53C29892C857584299CBF5D05346208A478A880F@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <87infr1xw0.fsf@chopps.org> <6080_1507559111_59DB86C7_6080_225_1_53C29892C857584299CBF5D05346208A478A6A3B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <MWHPR05MB2829CADBB801D2A708A72759A9740@MWHPR05MB2829.namprd05.prod.outlook.com>
In-Reply-To: <MWHPR05MB2829CADBB801D2A708A72759A9740@MWHPR05MB2829.namprd05.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/L9lVvyXC8xG9IS57-4yZap14zrM>
Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2017 07:08:18 -0000

Thanks Chris,

Looks good to me.

Regards,
--Bruno

> From: Chris Bowers [mailto:cbowers@juniper.net]
> Sent: Monday, October 09, 2017 10:55 PM
> 
 > Bruno,
 > 
 > Thanks for expressing support for WG adoption, and for the comments.
 > 
 > The comments are addressed in-line with [CB].
 > 
 > Chris
 > 
 > -----Original Message-----
 > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
 > Sent: Monday, October 9, 2017 9:25 AM
 > To: Christian Hopps <chopps@chopps.org>rg>; draft-hegde-isis-advertising-te-protocols@ietf.org
 > Cc: isis-chairs@ietf.org; isis-ads@ietf.org; isis-wg@ietf.org
 > Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
 > 
 > Hi Chris, authors, all,
 > 
 > 
 > I support WG adoption of this document.
 > 
 > This document provides explicit signaling for the support of RSVP-TE over a link and hence
 > avoids implicit assumptions which may not be interoperable.
 > 
 > 
 > Please find below some comments:
 > 
 > 1) Traffic-engineering protocol sub-TLV
 > 
 > I feel that a Flags field attached to links may be useful for multiple applications and usages. I
 > would not limit the usage to TE, hence I would propose to use a more generic name. At least to
 > avoid comment such as "you cannot use this field to advertise xx as xx is not TE"
 > 
 > =======
 > [CB] That makes sense. A better name might be "Protocol Enablement sub-TLV", but I am
 > interested in other naming suggestions as well.
 > =======
 > 
 > 2) Segment Routing flag
 > 
 > Thanks for adding section 3.2 which is definitely needed.
 > Although I can live with it, I'm still not convinced that we need such a SR flag.
 > 
 > "The Segment Routing flag is set to zero to indicate that Segment Routing is not enabled on a
 > link."
 > What does "SR enabled on a link" means?
 > - If the goal is to signal Network Operator policy, probably the use of link color (aka administrative
 > groups) is the right tool.  (while for RSVP-TE, this is a technical capability that a router may
 > advertise by itself without network operator configuration)
 > - If the goal is to signal that MPLS is not enabled on the link (layer) then may be it should
 > renamed as MPLS flag, and could possibly be used more broadly.
 > - Are there other cases? (a priori SR seems a node property rather than a link property)
 > 
 > - Do you make a distinction between MPLS SR and SRv6? (SRv6 capability may be line card
 > hence link dependent)
 > 
 > ==========
 > [CB]  These are good points. At this point, the authors have identified the one use case described
 > in section 3.2.  It would be useful to understand if there are other use cases from the rest of the
 > working group.  I am certainly open to refinements or modifications of the SR flag as the working
 > group sees fit.    With respect to MPLS SR and SRv6, the current intention of the text is MPLS SR
 > when referring to the SR flag.  However, we will make this clearer in the next revision of the text.
 > ==========
 > 
 > 3) uses of TE info for non-RSVP-TE usages.
 > 
 > " However, these traffic engineering link attributes
 >    have also been used by other applications, such as IP/LDP fast-
 >    reroute using loop-free alternates as described in [RFC7916].  In the
 >    future, it is likely that traffic engineering applications based on
 >    Segment Routing [I-D.ietf-spring-segment-routing] will also use these
 >    link attributes."
 > 
 > Could this document make it crystal clear, using normative language, that existing and future TE
 > link attributes may be used by non RSVP-TE applications?
 > Otherwise, this document lose its motivation (as the presence of TE sub-TLV may be used to
 > signal the presence of RSVP-TE)
 > 
 > ===========
 > [CB]  Below is proposed text to make this point crystal clear.
 > 
 >    "When traffic engineering extensions were first defined, the primary
 >    consumers of link attributes were RSVP-based applications that use
 >    the link information to compute paths which were subsequently
 >    signaled using RSVP-TE.  Over time, these link attributes have been
 >    used by non RSVP-TE applications, such as IP/LDP fast-reroute using
 >    loop-free alternates as described in [RFC7916].  More recently,
 >    applications based on Segment Routing
 >    [I-D.ietf-spring-segment-routing] have started to make use of these
 >    link attributes.
 > 
 >    In order to remove any ambiguity about the status of non RSVP-TE uses
 >    of TE link attributes, the current document makes the following
 >    normative statement.  Existing and future traffic engineering link
 >    attributes MAY be used by non RSVP-TE applications."
 > ============
 > 
 > 
 > Thanks,
 > Regards,
 > --Bruno
 > 
 >  > -----Original Message-----
 >  > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Christian Hopps  > Sent:
 > Saturday, October 07, 2017 4:43 AM  > To: isis-wg@ietf.org  > Cc: isis-chairs@ietf.org; isis-
 > ads@ietf.org; draft-hegde-isis-advertising-te-protocols@ietf.org
 >  > Subject: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols
 >  >
 >  > Hi Folks,
 >  >
 >  > The authors have requested the IS-IS WG adopt  >
 >  >     https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-
 > 2Dhegde-2Disis-2Dadvertising-2Dte-
 > 2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
 > ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=S0MISL1Ph
 > JdVSGSOkWSRY-
 > tyTlkaOS4u6Zs82okra40&s=baaIDeBkWxThZOMBrijUmD9F1EocY9lBoGkN9xlS5RY&e=
 >  >
 >  > as a working group document. Please indicate your support or no-support  > for taking on this
 > work.
 >  >
 >  > Authors: Please indicate your knowledge of any IPR related to this work  > to the list as well.
 >  >
 >  > Thanks,
 >  > Chris & Hannes.
 > 
 > _____________________________________________________________________________
 > ____________________________________________
 > 
 > 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.


_________________________________________________________________________________________________________________________

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.