Thanks for your response. See inline.. On Tue, Nov 28, 2017 at 10:55 PM, Ahmed Bashandy (bashandy) < basha...@cisco.com> wrote:
> Thanks for the feedback > > See inline > > Ahmed > > On 11/28/2017 8:54 AM, Muthu Arul Mozhi Perumal wrote: > > On Tue, Nov 28, 2017 at 5:34 PM, Ahmed Bashandy (bashandy) < > basha...@cisco.com> wrote: > >> Hi, >> >> The behavior described in section 5.3 is clear: >> - The top label of incoming packet to node "S" is either a prefix SID >> owned by node "F" or an adjacency SID for (S,F) >> - If the link from node "S" to node "F" is up, then the normal behavior >> for node "S" is to apply penultimate hop popping (PHP). HEnce node "S" >> *pops* the top label and sends the packet to node "F" >> - But if the link (S,F) is down and "S" is configured to do node >> protection, then node "S" will still pop the top label. This will promote >> the label right underneath the incoming label to become the *top* label. >> Hence there is no need to peek into the label stack >> > > What if the new top label is a BSID assigned from the SRLB of node F or > a BGP-LU or a VPN label assigned by node F? > > #Ahmed: I just replied to Robert. Let me put it here > The node "S" knows the SRGB and the adj-SIDs of the neighboring node "F". > Hence if the new top label is not within these two sets, then the node "S" > will always be able to know that the node that failed is NOT a midpoint. > Define what "policy midpoint" is. Also, the case where the new ToS is a BSID assigned from the SRLB of node F needs consideration.. > > I will add a statement in the document to explain how a node can determine > that a failure is a midpoint failure. I will also add a statement to > indicate that if the node determines that the failure is not a midpoint > failure then it may apply other protection techniques that are beyond the > scope of this document or simply drop the packet and wait for normal > protocol conversion. > > > >> - In a link-state envirnoment, node "S" knows the SRGB of node "F" as >> well as all adjacency SIDs of node "F". Hence it can now compare the new >> top label against the SRGB or the list of adj-SIDs of the node "F" >> > > What does "it" stand for in "it can now compare"? > > "Ahmed: "It" refers to the node "S" > > > For the control plane to be able to compare it also needs to be imposing > the SR policy as I said earlier. > > #Ahmed: There is no control plane comparison. > > > Or is the MPLS data plane expected to do such a comparison on the fly? > > #Ahmed: data plane is expected to do such comparison. > This is not clear from the current draft. Would suggest stating it explicitly.. Muthu > It is not that difficult. Just make sure you have a good forwarding ASIC :) > > > >> - If the new top label is within the SRGB of node "F" or an adj-SID of >> node "F", then node "S" applies the behavior described in section 5.3.1 or >> section 5.3.2, respectively >> >> The bottom line is that there is no need for any peeking into the label >> stack. Just inspect the new top label >> > > How is the MPLS data plane in a transit node expected to be programmed > to make this work? > > #Ahmed: Implementation details that should become big problems for good > forwarding ASICs :) > > > Regards, > Muthu > > > >> Thanks >> >> Ahmed >> >> >> On 11/23/2017 5:04 AM, Muthu Arul Mozhi Perumal wrote: >> >> My understanding is that draft wants to provide a solution for the >> problem where the active segment is a prefix/adjacency segment of the >> neighbor and the neighbor fails. A solution to this is possible only at a >> node that is enforcing the SR policy (consisting of the segment list). For >> a transit node, its data plane would have to peek into the label stack and >> determine the type of the segment/label following the active segment and >> act accordingly, which is not inline with the SR architecture which >> requires SR to work 'as is' on traditional MPLS data plane >> >> Muthu >> >> On Wed, Nov 22, 2017 at 8:22 PM, Alexander Vainshtein < >> vinesa...@yahoo.com> wrote: >> >>> Muthu and all, >>> I do not see how the draft in quesrion us related to "SR Policy". >>> >>> From my POV its scope is a SR LSP comprised of multiple Node SIDs within >>> a single IGP domain, and it provides local fast protection against failure >>> of a node that terminates one of the segments comprising this LSP. >>> Pritection action is performed by the penultimate node. >>> >>> My 2c. >>> >>> Sent from Yahoo Mail on Android >>> <https://overview.mail.yahoo.com/mobile/?.src=Android> >>> >>> On Wed, Nov 22, 2017 at 3:27, Muthu Arul Mozhi Perumal >>> <muthu.a...@gmail.com> wrote: >>> Section 5.3 of draft-bashandy-rtgwg-segment-routing-ti-lfa describes >>> protecting SR policy midpoints against node failure for the case where the >>> active segment is the prefix or adjacency segment of a neighbor. >>> >>> I believe the steps described in the procedure is applicable only for a >>> node steering packets into the SR policy. This could be an ingress PE >>> steering IP packets into a SR-TE tunnel or an intermediate node steering >>> labeled packets received with a BSID into a SR-TE tunnel identified by that >>> BSID. >>> >>> A transit node that has no idea about the SR policy itself is not >>> expected to perform the procedure described in that section. >>> >>> Is my understanding correct? >>> >>> Regards, >>> Muthu >>> _______________________________________________ >>> rtgwg mailing list >>> rtgwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >>> >> >> >> _______________________________________________ >> rtgwg mailing listrtgwg@ietf.orghttps://www.ietf.org/mailman/listinfo/rtgwg >> >> >> > >
_______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
