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

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Pushpasis Sarkar [mailto:[e-mail]]
Sent: Thursday, July 20, 2017 7:35 AM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; Shell Nakash <[e-mail]>; Michael Gorokhovsky <[e-mail]>; Dmitry Valdman <[e-mail]>; Ron Sdayoor <[e-mail]>; Rotem Cohen <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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.


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
[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


My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

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.
___________________________________________________________________________

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


___________________________________________________________________________

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.
___________________________________________________________________________