Re: [Lsr] clarification of locator block and locator node in draft-ietf-spring-srv6-network-programming and draft-ietf-lsr-isis-srv6-extensions

[Chris Bowers <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Ketan,
>
>
>
> Thanks fort the follow up.
>
> Clarification inline [Bruno]
>
>
>
> *From**:* Ketan Talaulikar (ketant) [mailto:[e-mail]]
> *Sent:* Friday, February 28, 2020 11:11 AM
> *To:* DECRAENE Bruno TGI/OLN; Ketan Talaulikar (ketant); Chris Bowers
> *Cc:* [e-mail]; 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 <[e-mail]> *On Behalf Of *
> [e-mail]
> *Sent:* 28 February 2020 14:34
> *To:* Ketan Talaulikar (ketant) <ketant=[e-mail]>;
> Chris Bowers <[e-mail]>
> *Cc:* [e-mail]; SPRING WG List <[e-mail]>;
> draft-ietf-spring-srv6-network-programming <
> [e-mail]>; Peter Psenak
> (ppsenak) <[e-mail]>
> *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:[e-mail] <[e-mail]>] *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 <[e-mail]> *On Behalf Of *Chris Bowers
> *Sent:* 27 February 2020 22:46
> *To:* [e-mail]; SPRING WG List <[e-mail]>
> *Cc:* Peter Psenak (ppsenak) <[e-mail]>
> *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 <[e-mail]> 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.
>
>