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
