Hi  Pushpasis,

Wow, it has been two years since you made the presentation.  Thank you for your 
slides. I have read it all.

But I still have some questions. Please find them inline.


发件人: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
发送时间: 2017年8月9日 23:31
收件人: Chengli (Distance) <chengl...@huawei.com>
主题: Re: 答复: [spring] Anycast segments and context-specific label spaces

Hope you have already gone through my presentation presented way back in 2015.. 
If not here is the link to the same.

https://www.ietf.org/proceedings/93/slides/slides-93-spring-1.pdf

On Wed, Aug 9, 2017 at 8:58 PM, Pushpasis Sarkar 
<pushpasis.i...@gmail.com<mailto:pushpasis.i...@gmail.com>> wrote:
Hi Chengli,

Thanks a lot for taking time to read the draft and provide comments. Please 
find answers inline

On Wed, Aug 9, 2017 at 2:04 PM, Chengli (Distance) 
<chengl...@huawei.com<mailto:chengl...@huawei.com>> wrote:
Hi Pushpasis,
I am a new learner of SR. Recently, I read the 
draft<https://tools.ietf.org/html/draft-ietf-spring-mpls-anycast-segments-01>, 
and I haa some questions about it. Some of them are about the algorithm, while 
the others are about the context.

1: If CA-SRGB need to be configured the same among all nodes, which means all 
nodes can understand the label in CA-SRGB. If so, why do we need to set P-Flag 
when the node has a different CA-SRGB range with SRGB. Without the Anycast-SID, 
the node can understand CA-SRGB and process CAPSL as well.  Why do we need to 
keep Anycast label? To indentify the next label is a CPASL?
[Pushpasis] Yes this is needed for the node that originated the CAPSL. In case 
the CA-SRGB is different from regular SRGB the packet must come in with the 
CAPSL at the top of the stack so that it pops and does a recursive label lookup 
with the next label in stack..

[Cheng] If there is an action supporting to look up in V-LFIB, why not use 
CAPSL as the key in Default LFIB directly?  If so, P-Flag can be leaved 0, and 
node will receive a packet with the CAPSL as the top label no matter it’s 
CA-SRGB is the same as SRGB or not. In default LFIB, there should be an entry 
for CAPSL, and it’s action is to look up CAPSL in V-LFIB. I am not sure that 
whether it can work or not.

In this way, configuration will be much easier.

In summary, in my POV, we can pop the previous anycast label so that the node 
can receive the same packet no matter it’s CA-SRGB is the same as SRGB or not. 
But I suppose that  there must be some reasons that you didn’t  propose a 
solution like this. If possible, can you be kind to tell me ?

I think the reason maybe:

Keeping the anycast label can reduce the entries of LFIB.  If we use CAPSL as 
the top label, we need to install entries for all CAPSLs in LFIB and in V-LFIB 
as well. But if we keep Anycast label as the top label,  we only need to 
install one entry for Anycast label, and one entry for each CAPSL in V-LFIB.


2: In section 3.2.2 of your draft, it says that
This document introduces a separate virtual label lookup table
   (hereafter referred to as Virtual LFIB or V-LFIB), that represents a
   label space which is also separate from the actual label space
   represented by the default LFIB.  The label value may be present in
   both the default and Virtual LFIB.

If V-LFIB represents a label space separated from the label space represented 
by LFIB, why label value may be present in both of them?  If this is right, I 
suppose that the reason of keeping anycast label is to identify the next label 
should be looked up in V-LFIB instead of default one.
[Pushpasis] Theoretically all label-spaces can be independent and may have the 
same label programmed in them with different forwarding semantics. However from 
the following text we proposed a separate V-LFIB if and only if CA-SRGB is 
different from SRGB..

[Cheng] I am wondering that what is the label-space? I think it is the range of 
label. But it seems not.


" Such a device MUST add an entry in the Virtual LFIB for each unicast

   and anycast prefix segments learnt from a remote device, if and only

   if the same prefix has not been provisioned on the device.  The

   device SHOULD NOT add an entry for any of the Anycast or Node prefix

   segments that it has advertised itself.  However if the device has

   learnt any anycast prefix segment from a remote device, and the same

   is not provisioned on this device, the device MUST include the same

   in the Virtual LFIB table.
"

[Pushpasis] If the label at the top of the stack belongs to CA-SRGB then it has 
to be for anycast prefix originated remotely and the packet actually hits an 
entry in the default LFIB first.. But because the label is corresponding to an 
anycast prefix we install a recursive lookup with the V-LFIB as the next 
table.. When the lookup for next label in stack in the VLFIB is launched that 
label maybe associated with CA_SRGB or default-SRGB.. The V-LFIB is needed to 
only faclitate lookup of the next label..  In case the CA-SRGB is same as 
default-SRGB I hope your realize that a recursive label is not required. It is 
important to realize that CA-SRGB is invented to actually avoid recursive label 
lookup.. The devices that uses same CA-SRGB as default SRGB need not support 
recursive label lookup in the hardware..

[Cheng] Yes, I can understand the logic of your solution.  What if we pop the 
anycast label ,and let the CAPSL to hit the entry in LFIB, and then execute the 
action of looking up CAPSL in V-LFIB.  Why do we need to keep the anycast label 
? This is my question.



3: I found out some strange statements in the draft:


a)       Page 11

For example, on device A1, the prefix SID 10 (originated by PE3) is

   reachable through its neighbors A3 and A4.  And as per the SRGB

   advertised by A3 and A4, the labels allocated by A3 and A4 are 3030
   and 4030 respectively

I suppose that the prefix SID is 30 instead of 10.
[Pushpasis] Yes you are right. I have already got this comment from one of the 
WG members. I will rectifying this in next version.

b)       Page 14

This is because on node A1(Is it A2?) the domain-wide CA-SRGB is identical to 
the local SRGB provisioned on A2.



c)       Page 14

While forwarding to A2, since A2 would

    have advertised the anycast SID 100 with P-Flag (No-PHP) unset, R1

    shall POP the incoming label 7100 before forwarding it to R1(Is it A2?).
[Pushpasis] Yes you are right. I have already got this comment as well from one 
of the WG members. I will rectifying this in next version.

Thanks a lot for comments and thoughts.

Best regards
-Pushpasis


Thank you for your good job!

Regards,
Cheng


发件人: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 代表 
Pushpasis Sarkar
发送时间: 2017年7月20日 12:35
收件人: Alexander Vainshtein 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>
抄送: m...@ietf.org<mailto:m...@ietf.org>; 
draft-ietf-spring-anycast-segm...@ietf.org<mailto:draft-ietf-spring-anycast-segm...@ietf.org>;
 
draft-mpls-shen-egress-protection-framew...@ietf.org<mailto:draft-mpls-shen-egress-protection-framew...@ietf.org>;
 Shell Nakash <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>; 
Michael Gorokhovsky 
<michael.gorokhov...@ecitele.com<mailto:michael.gorokhov...@ecitele.com>>; 
spring@ietf.org<mailto:spring@ietf.org>; Dmitry Valdman 
<dmitry.vald...@ecitele.com<mailto:dmitry.vald...@ecitele.com>>; Ron Sdayoor 
<ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>>; Rotem Cohen 
<rotem.co...@ecitele.com<mailto:rotem.co...@ecitele.com>>
主题: 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 
<alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@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.vainsht...@ecitele.com<mailto: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<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring



_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to