Re: [mpls] [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 <
Alexander.Vainshtein@ecitele.com> 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: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> ____________________________________________________________
> _______________
>
> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>