Hi Pushpasis, Thank you for your answer, now I understand the reason of it. Please read detailed reply inline.
发件人: Pushpasis Sarkar [mailto:pushpasis.i...@gmail.com] 发送时间: 2017年8月10日 14:29 收件人: 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, 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. 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 job! Hope your questions are answered now. Thanks -Pushpasis 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 [mailto:pushpasis.i...@gmail.com<mailto:pushpasis.i...@gmail.com>] 发送时间: 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. 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
