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 protected]> 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: [email protected] > > > > ____________________________________________________________ > _______________ > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
