Hi Eric, ________________________________________ 发件人: Eric C Rosen [[email protected]] 发送时间: 2016年4月7日 4:48 收件人: Xuxiaohu; [email protected] 抄送: [email protected] 主题: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
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. Best regards, Xiaohu would just follow the IGP best path, and all the intermediate nodes would be expected to recognize the label at the top of the stack. If the intermediate nodes are expected to recognize the label, this is not the "remote label distribution peer case". You seem to be positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to transport packets from one to the other. It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't. In BIER, we do accommodate this sort of situation, where some of the nodes in the BIER domain do not support BIER. But I don't know whether that sort of scenario needs to be supported for MPLS-SR. Do you have a particular use case in mind? _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
