Hi Pushpasis,

Thank you very much! This is what I want.  The internal use cases may reserve 
the range so that it can not be used by external use cases.
Definitely,  we can use any label range in the ‘next’ LFIB.

Thank you again!

Best regards,

发件人: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com]
发送时间: 2017年8月10日 16:58
收件人: Chengli (Distance) <chengl...@huawei.com>
抄送: draft-ietf-spring-anycast-segm...@ietf.org; spring@ietf.org
主题: Re: 答复: 答复: 答复: [spring] Anycast segments and context-specific label spaces

Hi Chengli,

Once again please see answer inline

On Thu, Aug 10, 2017 at 12:58 PM, Chengli (Distance) 
<chengl...@huawei.com<mailto:chengl...@huawei.com>> wrote:
Hi Pushpasis,

Thank you for your answer, now I understand the reason of it. Please read 
detailed reply inline.

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

Hi Chengli,

Please refer to Figure 4 in the draft. In this example CA-SRGB is 2000-3000. 
But let's say A1 for some hardware specific reason cannot support label range 
2000-3000. So it uses a regular SRGB range of 1000-2000. If A1 would not have 
advertised the anycast prefix segment 100 with P-Flag 1, the topmost label in 
the incoming packet will be pf the next segment as 2030. As you may know 
already the first label lookup for any packet is always in the default-LFIB, 
and 2030 cannot be programmed in default-LFIB of A1. Then the packet shall have 
to be dropped.

[Cheng]So this is the main reason of why we need to keep anycast label. Because 
 the CAPSL can not be programmed in default-LFIB, if the node can not support 
the label range. It really makes sense. Keeping the APSL as the top label is a 
good way to solve this problem! Awesome!

But I have another question: In this case, range 2000-3000 can not be supported 
by A1, so why it can be used in V-LFIB?    Actually, I am curious about the 
hardware specific reason, and why this reason does not affect V-LFIB.
[Pushpasis] In this case 2000-3000 could not be supported for default-LFIB coz 
some internal usecase may have already reserved it from the default-LFIB.. so 
labels from cannot be used for switching external traffic in the regular LFIB 
table.. But if the lookup is directed to another LFIB we can use whatever label 
range required.. Now the first label of packet always end up in a lookup under 
default-LFIB.. But the next one can always be directed to another LFIB table 
(provided the hardware supports switching LFIBs).. This method is not new and 
there has been few drafts (e.g. egress-protection) that prescribes using a 
different LFIB.. We just used it for solving the any cast problem..

Thanks and regards,

Instead we force the penultimate hop to not POP the topmost label but swap it 
with 1100. When the packet comes with 1100 as the topmost label it hits the 
corresponding entry in default-LFIB which pops it and launches a lookup for 
2030 in a separate V-LFIB.
[Cheng] Yes.

The purpose of CA-SRGB is for the source of the traffic to derive the label to 
be used for the next segment following a anycast segment. The label to be used 
for the first anycast segment is always derived from the regular SRGB of the 
next hop node(s).
[Cheng] Yes, this is a really amazing idea!

Now question is why cannot we use CASRGB to be same as SRGB everywhere? But If 
that would have been possible there would have been no reason for this draft to 
be written in the first place. The reason that cannot be possible is different 
vendors support different label-ranges in their hardware. And the biggest 
reason all vendors cannot support the same range is because of 
platform-specific legacy limitations in their hardwares. For example the device 
used for the node A1 already reserves the label range 2000-3000 for some 
internal switching and cannot be made available for the regular MPLS switching 
and forwarding. Also as per MPLS architecture labels are of local significance 
and there should be no solution based on global label ranges.

[Cheng]No, I understand the reason totally. Your work is really useful. Good 

Hope your questions are answered now.


On Thu, Aug 10, 2017 at 9:22 AM, Chengli (Distance) 
<chengl...@huawei.com<mailto:chengl...@huawei.com>> wrote:
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 
发送时间: 2017年8月9日 23:31
收件人: Chengli (Distance) <chengl...@huawei.com<mailto: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.


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

Thank you for your good job!


发件人: spring [mailto:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] 代表 
Pushpasis Sarkar
发送时间: 2017年7月20日 12:35
收件人: Alexander Vainshtein 
抄送: m...@ietf.org<mailto:m...@ietf.org>; 
 Shell Nakash <shell.nak...@ecitele.com<mailto:shell.nak...@ecitele.com>>; 
Michael Gorokhovsky 
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 
主题: 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 
Hi all,
I have read the 
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 

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

My 2c,

Office: +972-39266302
Cell:      +972-549266302


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 
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 mailing list

Reply via email to