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.decra...@orange.com> wrote: > Hi Ketan, > > > > Thanks fort the follow up. > > Clarification inline [Bruno] > > > > *From**:* Ketan Talaulikar (ketant) [mailto:ket...@cisco.com] > *Sent:* Friday, February 28, 2020 11:11 AM > *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers > *Cc:* l...@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-boun...@ietf.org> *On Behalf Of * > bruno.decra...@orange.com > *Sent:* 28 February 2020 14:34 > *To:* Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc.ietf.org>; > Chris Bowers <chrisbowers.i...@gmail.com> > *Cc:* l...@ietf.org; SPRING WG List <spring@ietf.org>; > draft-ietf-spring-srv6-network-programming < > draft-ietf-spring-srv6-network-programm...@ietf.org>; Peter Psenak > (ppsenak) <ppse...@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-boun...@ietf.org <lsr-boun...@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-boun...@ietf.org> *On Behalf Of *Chris Bowers > *Sent:* 27 February 2020 22:46 > *To:* l...@ietf.org; SPRING WG List <spring@ietf.org> > *Cc:* Peter Psenak (ppsenak) <ppse...@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 <ppse...@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 mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
