Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89901130E97; Wed, 13 Jun 2018 15:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 MFzuqL1yFV-Z; Wed, 13 Jun 2018 15:05:06 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.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 779D4130E96; Wed, 13 Jun 2018 15:05:06 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 679E8160F58; Thu, 14 Jun 2018 00:05:04 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.63]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 4834C18003F; Thu, 14 Jun 2018 00:05:04 +0200 (CEST) Received: from OPEXCNORMAC.corporate.adroot.infra.ftgroup ([fe80::f9fb:6cba:1c64:7737]) by OPEXCNORM3F.corporate.adroot.infra.ftgroup ([fe80::e857:81f3:3859:a5de%21]) with mapi id 14.03.0399.000; Thu, 14 Jun 2018 00:05:04 +0200 From: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "Ketan Talaulikar (ketant)" , "idr@ietf.org" , "lsr@ietf.org" , "spring@ietf.org" Thread-Topic: Signalling ERLD (ISIS, OSPF and BGP-LS) Thread-Index: AdQCVS4zJNJrYGL7RvyJWFnJWJ9mLgAhqsxQAAPpAwAAAcpz8AAATSsgABuZfdA= Date: Wed, 13 Jun 2018 22:05:03 +0000 Message-ID: <18142_1528927504_5B219510_18142_427_1_9E32478DFA9976438E7A22F69B08FF924B1AF4E8@OPEXCNORMAC.corporate.adroot.infra.ftgroup> References: <741c5584debc4bc7821292de52f8d6c4@XCH-ALN-008.cisco.com> <5c494d4e76cf4fa1adcb695f4ee4b59e@XCH-ALN-008.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US 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: Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS) X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 22:05:10 -0000 Hi, As defined in draft-ietf-mpls-spring-entropy-label, advertising an ERLD mea= ns that the node is defacto ELC (so advertising ELC separately is not neces= sary): " The Entropy Readable Label Depth (ERLD) is defined as the number of labels a router can both: a. Read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack). b. Use in its load-balancing function. The ERLD means that the router will perform load-balancing using the EL label if the EL is placed within the ERLD first labels. " " To advertise an ERLD value, a SPRING router: o MUST be entropy label capable and, as a consequence, MUST apply the dataplane procedures defined in [RFC6790]. o MUST be able to read an ELI/EL which is located within its ERLD value. o MUST take into account this EL in its load-balancing function. " Brgds, -----Original Message----- From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (= Nokia - BE/Antwerp) Sent: Wednesday, June 13, 2018 11:10 To: Ketan Talaulikar (ketant); idr@ietf.org; lsr@ietf.org; spring@ietf.org Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS) It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are = signaled for ISIS, OSPF and BGP-LS.=20 If the WG's can manage to agree upon a decision (option1/2/3 or 4), then ne= xt, have a look into how to encode the TLV so that we have a clean technolo= gical solution space. G/ -----Original Message----- From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]=20 Sent: Wednesday, June 13, 2018 10:45 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; idr@ietf.org; lsr@ietf.org; spring@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, In that case, I concur with you that option (2) is better than the others. = My only difference in opinion is that ERLD not have its own separate TLV bu= t instead get advertised as a new MSD sub-type - it is just a different enc= oding. Thanks, Ketan -----Original Message----- From: Van De Velde, Gunter (Nokia - BE/Antwerp) =20 Sent: 13 June 2018 13:55 To: Ketan Talaulikar (ketant) ; idr@ietf.org; lsr@ietf.or= g; spring@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Indeed, the debate that made BGP-LS to go down the ERLD path is of pragmati= c motivation. The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV = is available, then ELC can be implicitly assumed. No pragmatic reason to si= gnal separately, as it just make things more complex then should be.=20 >From a holistic perspective having something similar, yet different, in bo= th IGP and BGP-LS encoding seems to make little sense and only bring confus= ion (router/controller implementers and network operators).=20 The ways to address this in IGP and BGP-LS going forward: 1) do nothing and leave all as it is (it has potential to create massive co= nfusion) 2) only signal ERLD TLV in IGP and BGP 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signalin= g of ELC TLV compared to option (2)) 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more = complex as option (2)) I believe that option (2) is the best option: * it bring the needed readable label depth value to operators * most simple solution for implementers (routers and controller) * easy to understand with no confusion * is compliant with draft-ietf-mpls-spring-entropy-label-10 G/ -----Original Message----- From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]=20 Sent: Wednesday, June 13, 2018 08:05 To: Van De Velde, Gunter (Nokia - BE/Antwerp) ; idr@ietf.org; lsr@ietf.org; spring@ietf.org Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS) Hi Gunter, The difference in IGP signalling seems to be because the ELC is a capabilit= y which is advertised differently than ERLD which is a limit. Are you sayin= g that ELC does not have value by itself without the ERLD? IMHO it makes sense to retain ELC as capability of the router (as specified= in the IGP specs) and position ERLD as a MSD sub-type for indicating the l= imit. This way we have the flexibility of signalling ERLD both per node and= per ingress link/LC level. Thanks, Ketan -----Original Message----- From: Idr On Behalf Of Van De Velde, Gunter (Nokia -= BE/Antwerp) Sent: 12 June 2018 19:28 To: idr@ietf.org; lsr@ietf.org; spring@ietf.org Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS) In LSR WG the following drafts document the signaling of ELC and RLD: * draft-ietf-ospf-mpls-elc * draft-ietf-isis-mpls-elc When exporting this information using BGP-LS encoding to a controller, ther= e is need for BGP-LS extension by means of new TLVs. BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF i= s signaling individually ELC and RLD I was working upon the IANA section, and discovered some inconsistency that= should be addressed: * Why is IGP signaling individual ELC and RLD? ERLD is what was decided upo= n (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10) * What are the plans to request IANA code points for these drafts? * (E)RLD seems to have meaning only from NODE perspective, (I assume that L= INK ERLD is not of any value at all, is that a correct assumption?) G/ -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Tuesday, June 12, 2018 15:25 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signalling ERLD using BGP-LS Authors : Gunter Van de Velde Wim Henderickx Matthew Bocci Keyur Patel Filename : draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt Pages : 6 Date : 2018-06-12 Abstract: This document defines the attribute encoding to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node to a centralised controller (PCE/SDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing= -rld-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-ls-segment-routing-r= ld-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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.