Subject: [mpls] Anycast segments and context-specific label spaces

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 19 Jul 2017 07:09:50 +0000

Hi all,
I have read the draft<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-01> in question, and, from my POV, it defines, under the name of Virtual LFIB,  a dedicated context-specific label space (see RFC 5331<https://tools.ietf.org/html/rfc5331>)  in the devices that are assigned with one or more anycast segments, and uses the labels such devices allocate for these segments as the context labels identifying this space.

If my understanding is correct:

*         Explicit mapping of the definitions of the draft to already defined and well-understood MPLS architectural mechanisms would greatly improve its readability. It would also greatly help the implementers, especially if they have already implemented (or consider implementation of) context-specific label spaces in their devices

*         Adding the relevant references (including a normative reference to RFC 5331) seems necessary

Using context-specific label spaces and context labels in conjunction with anycast (or anycast-like) functionality  in MPLS is not new. One example (as indicated in Eric Rosen's email<https://www.ietf.org/mail-archive/web/mpls/current/msg12659.html>)  is the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104<https://tools.ietf.org/html/rfc8104>. The analogy looks important to me since anycast groups are commonly considered as a protection mechanism (and not just as a load-balancing one). I also think that relationships between this draft and the egress protection framework<https://datatracker.ietf.org/doc/draft-shen-mpls-egress-protection-framework/?include_text=1> one are worth looking at carefully.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 19 Jul 2017 21:34:37 -0700

Hi Sasha,

Thanks a lot for taking time to read the document and providing the much
appreciated comments. Please find some comments inline.

On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vainshtein <
[email-masked]> wrote:

> Hi all,
>
> I have read the draft
> <https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-01>
> in question, and, from my POV, it defines, under the name of Virtual LFIB,  *a
> dedicated context-specific label space* (see RFC 5331
> <https://tools.ietf.org/html/rfc5331>)  in the devices that are assigned
> with one or more anycast segments, and uses the labels such devices
> allocate for these segments as the *context labels* identifying this
> space.
>
[Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in the
next version.

> ·         Explicit mapping of the definitions of the draft to already
> defined and well-understood MPLS architectural mechanisms would greatly
> improve its readability. It would also greatly help the implementers,
> especially if they have already implemented (or consider implementation of)
> context-specific label spaces in their devices
>
[Pushpasis] At the time of writing this draft, there were already some
implementations of context-specific label space , and so I thought adding
those implementation details will not be useful, especially during the WGLC
last calls. Implementation minute details are not welcome I assume from the
WGLC reviews I have gone through so far. But l can sure add some reference
to RFC5331.

> ·         Adding the relevant references (including a normative reference
> to RFC 5331) seems necessary
>
>
>
> Using context-specific label spaces and context labels in conjunction with
> anycast (or anycast-like) functionality  in MPLS is not new. One example
> (as indicated in Eric Rosen’s email
> <https://www.ietf.org/mail-archive/web/mpls/current/msg12659.html>)  is
> the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104
> <https://tools.ietf.org/html/rfc8104>.
>
[Pushpasis] Yes, use of context-specific label space is not new. And
working in Juniper for sometime I have a good idea of its application. But
using it to provide a means to do anycast segments using MPLS dataplane is
very much new. And to my knowledge till date there is no other way to
achieve this without recursive label lookup and context-specific label
spaces.

> The analogy looks important to me since anycast groups are commonly
> considered as a protection mechanism (and not just as a load-balancing one).
>
[Pushpasis] Actually, about the usecases I have discussed some of the
operators I have discussed with so far on this, almost all them are about
policy-based-routing,  load-balancing and providing disjoint paths.
Offcourse disjoint paths can be used for protection as well as
load-balancing.

> I also think that relationships between this draft and the egress
> protection framework
> <https://datatracker.ietf.org/doc/draft-shen-mpls-egress-protection-framework/?include_text=1>
> one are worth looking at carefully.
>
[Pushpasis] First the egress protection drafts does not seem to have gone
through WG adoption. Next though these two drafts use the same mechanisms,
the exact problem they try to solve are not exactly related.

Nevertheless, I value your comments, suggestions and thoughts a lot, and
thank you very much for providing the insights. I will definitely work on
them and address them in the next draft.

Thanks once again and best regards,
-Pushpasis

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 20 Jul 2017 11:35:46 +0000

Pushpasis hi!
Lots of thanks for a prompt and detailed response.
Your confirmation regarding de-facto usage of context label spaces and context labels in conjunction with anycast segments is very important and encouraging.

At the same time I disagree with your position when you say that “there were already some implementations of context-specific label space , and so I thought adding those implementation details will not be useful”. From my POV context-specific label spaces are an important element of the MPLS data plane architecture, therefore explicitly specifying it as an element of your solution cannot be considered as an “implementation detail”.

I also think that using the context-specific label spaces and their context labels explicitly could improve applicability of the solution by treating each anycast segment configured on the device as a dedicated context with its own context-specific label space and context label.  In your terms, you could use a dedicated CA-SRGB per anycast prefix with the APSL for this segment identifying specific CA-SRGB to be looked up. Of course this would not preclude using the same CA-SRGB for multiple anycast prefixes – but, on the other hand, this would provide for better flexibility as new anycast segments are added with more traffic flows using them.

Hopefully these notes will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Pushpasis Sarkar [mailto:[email-masked]]
Sent: Thursday, July 20, 2017 7:35 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; Dmitry Valdman <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: Re: [spring] Anycast segments and context-specific label spaces

Hi Sasha,

Thanks a lot for taking time to read the document and providing the much appreciated comments. Please find some comments inline.

On Wed, Jul 19, 2017 at 12:09 AM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I have read the draft<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-01> in question, and, from my POV, it defines, under the name of Virtual LFIB,  a dedicated context-specific label space (see RFC 5331<https://tools.ietf.org/html/rfc5331>)  in the devices that are assigned with one or more anycast segments, and uses the labels such devices allocate for these segments as the context labels identifying this space.
[Pushpasis] Yes, that is correct. I will add a reference to RFC 5331 in the next version.

•         Explicit mapping of the definitions of the draft to already defined and well-understood MPLS architectural mechanisms would greatly improve its readability. It would also greatly help the implementers, especially if they have already implemented (or consider implementation of) context-specific label spaces in their devices
[Pushpasis] At the time of writing this draft, there were already some implementations of context-specific label space , and so I thought adding those implementation details will not be useful, especially during the WGLC last calls. Implementation minute details are not welcome I assume from the WGLC reviews I have gone through so far. But l can sure add some reference to RFC5331.

•         Adding the relevant references (including a normative reference to RFC 5331) seems necessary

Using context-specific label spaces and context labels in conjunction with anycast (or anycast-like) functionality  in MPLS is not new. One example (as indicated in Eric Rosen’s email<https://www.ietf.org/mail-archive/web/mpls/current/msg12659.html>)  is the PW Endpoint Fast Failure Protection mechanism defined in RFC 8104<https://tools.ietf.org/html/rfc8104>.
[Pushpasis] Yes, use of context-specific label space is not new. And working in Juniper for sometime I have a good idea of its application. But using it to provide a means to do anycast segments using MPLS dataplane is very much new. And to my knowledge till date there is no other way to achieve this without recursive label lookup and context-specific label spaces.

The analogy looks important to me since anycast groups are commonly considered as a protection mechanism (and not just as a load-balancing one).
[Pushpasis] Actually, about the usecases I have discussed some of the operators I have discussed with so far on this, almost all them are about policy-based-routing,  load-balancing and providing disjoint paths. Offcourse disjoint paths can be used for protection as well as load-balancing.

I also think that relationships between this draft and the egress protection framework<https://datatracker.ietf.org/doc/draft-shen-mpls-egress-protection-framework/?include_text=1> one are worth looking at carefully.
[Pushpasis] First the egress protection drafts does not seem to have gone through WG adoption. Next though these two drafts use the same mechanisms, the exact problem they try to solve are not exactly related.

Nevertheless, I value your comments, suggestions and thoughts a lot, and thank you very much for providing the insights. I will definitely work on them and address them in the next draft.

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]<mailto:[email-masked]>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring