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:   alexander.vainsht...@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

Reply via email to