> On Apr 7, 2016, at 6:39 PM, Xuxiaohu <[email protected]> wrote: > > On 4/6/2016 11:37 AM, Xuxiaohu wrote: >> The situation in MPLS-SR is a little bit complex since the outgoing label >> for a given /32 or /128 prefix FEC could be learnt either from the IGP >> next-hop of that FEC or the originator of that FEC due to the IGP flooding >> property. In the former case, the IGP next-hop for a given FEC is taken as >> the next-hop of the received MPLS packet belonging to that FEC; in the >> latter case, the originator of that FEC is taken as the next-hop of the MPLS >> packet belonging to that FEC ... the latter case belongs to the "remote >> label distribution peer" case as defined in RFC3031 > > I don't believe this is correct. In SR, the fact that label L was > advertised by node N does not imply that a packet with L at the top of > the stack needs to be tunneled to N. In the typical case, the packet > > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of > node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR > receiving the above MPLS packet with top label of L is desired to forward > that MPLS packet towards node N via an IP-based tunnel. In this case, the > node N is the remote peer for that FEC. >
Is this really a “remote label distribution peer”? Or a local one by way of the forwarding adjacency of an IP Tunnel as a logical MPLS-enabled interface (towards N or bypassing the old router)? Thanks, — Carlos. > Best regards, > Xiaohu
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
