On Tue, Nov 28, 2017 at 5:34 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 > 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? > - 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"? For the control plane to be able to compare it also needs to be imposing the SR policy as I said earlier. Or is the MPLS data plane expected to do such a comparison on the fly? > - 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? 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 <[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
