That's good addition to the draft. My comment is addressed.
Thx, R. On Tue, Nov 28, 2017 at 5:58 PM, Ahmed Bashandy (bashandy) < [email protected]> wrote: > Thanks for the the feedback > > 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 but > rather an egress point failure > > 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. > > Ahmed > > > On 11/28/2017 6:38 AM, Robert Raszuk wrote: > > Hi Ahmed, > > > - In a link-state envirnoment, node "S" knows the SRGB of node "F" as > well as all adjacency SIDs of node "F" > > What you say is all true, but the way I read the question of this thread > seems to be what happens in the cases where node S has no clue of the new > top label. Say it was controller imposed EPE label or worse it is a VPN > label. > > > In the former EPE case the packet could still be "rescued" by picking into > IP header. After all EPE is just an optimization. > > However in the latter case where we are carrying L2 or L3 VPNs packet > header after the label stack may not help or may be even a security issue > if node S would start to make routing decision in global RIB based on > customer's space. > > So I think the point to document is what is the expected behavior of S > node in case of new top label is unknown. It is ok to say drop it, but I > think it needs to be clearly stated. > > Best, > Robert > > > On Tue, Nov 28, 2017 at 1:04 PM, Ahmed Bashandy (bashandy) < > [email protected]> 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 >> - 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" >> - 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 >> >> 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 < >> [email protected]> 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 >>> <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/rtgwg >>> >>> >> >> >> _______________________________________________ >> rtgwg mailing [email protected]https://www.ietf.org/mailman/listinfo/rtgwg >> >> >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
