Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
Chris Bowers <chrisbowers.ietf@gmail.com> Mon, 02 March 2020 18:12 UTC
Return-Path: <chrisbowers.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB03A0E4D; Mon, 2 Mar 2020 10:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 z-Jy7lQaOa5d; Mon, 2 Mar 2020 10:12:19 -0800 (PST)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 22DA13A0E3E; Mon, 2 Mar 2020 10:12:19 -0800 (PST)
Received: by mail-qt1-x82f.google.com with SMTP id r6so656153qtt.9; Mon, 02 Mar 2020 10:12:19 -0800 (PST)
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=CepfS0UX28jaPHCSGHddP8yO3OhCY6bcJKF13DPK9Pg=; b=AuP/4hxI2qzK+gXFUnjJNqzI75yA248E+04a1BGjulI0cTVpU+GZtYrTrv0wXbpAeM TdZKXZ0g9piZKCrf6PmkYAvuKQg3Y0Dwsoy4fIimw5BApoxkk6Z3zR2JGuy/IG2uRSxs ORRq0Hb98vlJsI5r0ZV1Ef9jpt0BKIMc1Uhph4fjGEDgV/4Ob6y43F6w9P3/u6pOEoZ2 5xNeGIJv60RvilpVIC4EzRyxfmDMSpnzzqwAe+SnTEi7F9Jk4jd6m3bcIpspQh0jFx3Z ouJPNA1DLGN/np8CPj3gvsSQ7+49Sdq2Bvu+FEN+VDoR3TwWPNeRcDeOlQ+lPBEA6w76 ytXQ==
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=CepfS0UX28jaPHCSGHddP8yO3OhCY6bcJKF13DPK9Pg=; b=qHW+NA/S6T2ceKnopQtTSiKxwclcMOv1Xgrl2JfNrjD/7u28eecxV8nsx8U0nO0rYY tlF2wshGyITg1bI3v4IgxptnPfTaSm70JUiko0Tn0Q71FvuNbbh8pdNI8o8J4IkkCgs6 bDnxQx339rXsJpKbIjrc3QFV5MDt02+coHWBFVrZH45OD9wTZpou9DPFPVlJ+ZH6Gt0V HyR22Olz3A6HgtIerjD84Cb4zLxf96hk/OTx0UQ02SrVzNMOeFuP2D2co0rjkoy0dyY+ wQLSnE1NhYyTVqQ9YfYiESsADWRWmisXGHB4PxT21C5v/iItMinZ5GLbzf/Ns5LsjaRQ HD1Q==
X-Gm-Message-State: ANhLgQ0bfKIdXJob8FXyAT7s8sabQaOcVU67T78dacnD3TOGSxAAWQNr q7GE22L1iCgeN2HbkL2JOf3U1jd06ly0hzEyuPE=
X-Google-Smtp-Source: ADFU+vs9qWJKhPZM8/oKAtD2M/VQEamcvp1o4aUqid/kQqvPAJ8c/wduzKuuySVMznJXbLK7y+KO2ZN6I2TXA9GBFGY=
X-Received: by 2002:ac8:7952:: with SMTP id r18mr928767qtt.29.1583172738107; Mon, 02 Mar 2020 10:12:18 -0800 (PST)
MIME-Version: 1.0
References: <CAHzoHbtmJGB8QY==A5EMzzSwh+8bQjhbVgPBjA3kHJGxpCD_zA@mail.gmail.com> <c8828557-85a4-d002-cc8f-a8cd8da0aeaa@cisco.com> <CAHzoHbsU-+fUDdr5knmUE87DudCswwF2qGi11SVSSypT2UXKaQ@mail.gmail.com> <MW3PR11MB45703130D6A8527ED0C4C9CDC1E80@MW3PR11MB4570.namprd11.prod.outlook.com> <12659_1582880639_5E58D77F_12659_66_1_53C29892C857584299CBF5D05346208A48DCA80D@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB4570EDAE9E6AF17C9CCC9899C1E80@MW3PR11MB4570.namprd11.prod.outlook.com> <7453_1582899837_5E59227C_7453_80_1_53C29892C857584299CBF5D05346208A48DD14BA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <7453_1582899837_5E59227C_7453_80_1_53C29892C857584299CBF5D05346208A48DD14BA@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
From: Chris Bowers <chrisbowers.ietf@gmail.com>
Date: Mon, 02 Mar 2020 12:09:29 -0600
Message-ID: <CAHzoHbu4k15xJ2mnwp=9Xa400gQBtBY=OaSh6sh3_8E_t30sdA@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, SPRING WG List <spring@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Bruno Decraene <bruno.decraene@orange.com>
Content-Type: multipart/alternative; boundary="000000000000ac4d17059fe3203d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ZhS7-Gi2N3ERebtWODy_F8i-8Bo>
Subject: Re: [spring] [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 18:12:22 -0000
Ketan, Based on current documents, allocating all SRv6 locators used in a domain from a single block is optional. However, assuming for the moment that a network operator has chosen to allocate all SRv6 locators used in a domain from a single block, so that there is a well-defined value of B and N across a domain, what is the use of having a router advertise its own understanding of these two values? And what is a receiver supposed to do with this information? Thanks, Chris On Fri, Feb 28, 2020 at 8:23 AM <bruno.decraene@orange.com> wrote: > Hi Ketan, > > > > Thanks fort the follow up. > > Clarification inline [Bruno] > > > > *From**:* Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] > *Sent:* Friday, February 28, 2020 11:11 AM > *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers > *Cc:* lsr@ietf.org; SPRING WG List; > draft-ietf-spring-srv6-network-programming; Peter Psenak (ppsenak) > *Subject:* RE: [Lsr] clarification of locator block and locator node in > draft-ietf-spring-srv6-network-programming and > draft-ietf-lsr-isis-srv6-extensions > > > > Hi Bruno, > > > > I believe the description and usage of Locator is very well described and > covered in the net-pgm draft as also the corresponding IGP extensions. Is > the question is more about the “block” part of it (what is not in the block > part is in the node part as per the text in the net-pgm draft)? > > > > The “block” is again not a new thing. Please check the following: > > Under > https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-5 > … look for “block” > > https://tools.ietf.org/html/rfc8402#section-2 … look under SRGB for SRv6 > > > > [Bruno] > > To clarify, my question was not specific to “block” but related to the > usage, by the receiver, of the following piece of information: > > > > LB Length: SRv6 SID Locator Block length > > LN Length: SRv6 SID Locator Node length > > Fun. Length: SRv6 SID Function length > > Arg. Length: SRv6 SID Arguments length > > > > > > So perhaps I don’t get Chris’s point and would wait for him to clarify. > > [Bruno] I’ll leave this to Chris. > > > > Thanks, > > Ketan > > > > *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of * > bruno.decraene@orange.com > *Sent:* 28 February 2020 14:34 > *To:* Ketan Talaulikar (ketant) <ketant=40cisco.com@dmarc.ietf.org>; > Chris Bowers <chrisbowers.ietf@gmail.com> > *Cc:* lsr@ietf.org; SPRING WG List <spring@ietf.org>; > draft-ietf-spring-srv6-network-programming < > draft-ietf-spring-srv6-network-programming@ietf.org>; Peter Psenak > (ppsenak) <ppsenak@cisco.com> > *Subject:* Re: [Lsr] clarification of locator block and locator node in > draft-ietf-spring-srv6-network-programming and > draft-ietf-lsr-isis-srv6-extensions > > > > Hi Ketan, > > > > > > > > *From:* Lsr [mailto:lsr-bounces@ietf.org <lsr-bounces@ietf.org>] *On > Behalf Of *Ketan Talaulikar (ketant) > *Sent:* Friday, February 28, 2020 6:30 AM > > > > Hi Chris, > > > > I agree with Peter and I would suggest to drop LSR since this is not a > protocol specific thing. > > > > I believe the text in draft-ietf-spring-srv6-network-programming clears > says what locator block and locator node are. What more details do you > think are required? > > > > [Bruno] Speaking as an individual, the draft could possibly clarify the > usage of these information/fields by the receiver. Possibly using the same > name/term (e.g. SRv6 SID Locator Block length) to ease the references > between both drafts. > > > > Thanks, > > --Bruno > > > > Thanks, > > Ketan > > > > *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of *Chris Bowers > *Sent:* 27 February 2020 22:46 > *To:* lsr@ietf.org; SPRING WG List <spring@ietf.org> > *Cc:* Peter Psenak (ppsenak) <ppsenak@cisco.com> > *Subject:* [Lsr] clarification of locator block and locator node in > draft-ietf-spring-srv6-network-programming and > draft-ietf-lsr-isis-srv6-extensions > > > > SPRING and LSR WGs, > > > > I think that we need a much more detailed description of the locator block > and locator node in either draft-ietf-spring-srv6-network-programming or > draft-ietf-lsr-isis-srv6-extensions. See original email below. > > > > Thanks, > > Chris > > > > On Thu, Feb 27, 2020 at 11:08 AM Peter Psenak <ppsenak@cisco.com> wrote: > > Hi Chris, > > On 27/02/2020 17:54, Chris Bowers wrote: > > LSR WG, > > > > Section 9 of draft-ietf-lsr-isis-srv6-extensions-05 defines the SRv6 > > SID Structure Sub-Sub-TLV. In particular, it defines encoding for the > > locator block length and the locator node length. The text refers to > > [I-D.ietf-spring-srv6-network-programming] for the definition of these > > concepts. > > > > As far as I can tell, the only reference to locator block and locator > > node in draft-ietf-spring-srv6-network-programming-10 is section 3.1 > > which has the following text: > > > > A locator may be represented as B:N where B is the SRv6 SID block > > (IPv6 subnet allocated for SRv6 SIDs by the operator) and N is the > > identifier of the parent node instantiating the SID.. > > > > I think that we need a much more detailed description of the locator > > block and locator node. > > sure, but that would be in the > draft-ietf-spring-srv6-network-programming-10, not in > draft-ietf-lsr-isis-srv6-extensions, as these are not a protocol > specific constructs. > > thanks, > Peter > > > > > Thanks, > > > > Chris > > > > _________________________________________________________________________________________________________________________ > > > > 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. > >
- [spring] clarification of locator block and locat… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… bruno.decraene
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… bruno.decraene
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Christian Hopps
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Ketan Talaulikar (ketant)
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Chris Bowers
- Re: [spring] [Lsr] clarification of locator block… Peter Psenak
- Re: [spring] [Lsr] clarification of locator block… Gengxuesong (Geng Xuesong)
- Re: [spring] [Lsr] clarification of locator block… Derek Yeung
- Re: [spring] [Lsr] clarification of locator block… Weiqiang Cheng
- Re: [spring] [Lsr] clarification of locator block… Acee Lindem (acee)