> -----邮件原件----- > 发件人: Monika Machado [mailto:[email protected]] > 发送时间: 2012年6月16日 0:26 > 收件人: Xuxiaohu; [email protected]; Ivan Pepelnjak > 抄送: [email protected]; Keshava A K; [email protected]; [email protected] > 主题: RE: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic over IP > PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for > draft-xu-mpls-in-udp-00.txt > > Hi Xiaohu- > > This is a very interesting draft. > I haven't seeing a lot of comments on this, do you have any update how it is > progressing? I have a question about VRF, if the tunnel termination would be > bound to a VRF, is there any mechanism to signal what routing table does the > lookup needs to happen? Do we need a set of source/dest pairs per VRF?
Hi Monika, The egress PE router could know which VRF table should be used for route lookup according to the VPN label contained in the received packet. We don't need a set of src/dest pairs per VRF, on the contrary, a given src/dest pair could be shared by many VRF instances. I wonder whether I have understood your questions. Best regards, Xiaohu > Thanks > Monika > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Xuxiaohu > Sent: Friday, May 11, 2012 1:56 AM > To: [email protected]; Ivan Pepelnjak > Cc: [email protected]; Keshava A K; [email protected]; [email protected] > Subject: re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic > over IP > PSN using MPLS-in-UDP encapsulation// fwd: New Version Notification for > draft-xu-mpls-in-udp-00.txt > > > > -----邮件原件----- > > 发件人: Robert Raszuk [mailto:[email protected]] > > 发送时间: 2012年5月9日 19:01 > > 收件人: Ivan Pepelnjak > > 抄送: Keshava A K; [email protected]; Xuxiaohu; [email protected]; > > [email protected] > > 主题: Re: [nvo3] Facilitating the load-balancing of L2VPN/L3VPN traffic > > over IP PSN using MPLS-in-UDP encapsulation// fwd: New Version > > Notification for draft-xu-mpls-in-udp-00.txt > > > > Hi Ivan, > > > > > True, but then you need a mechanism to discover all the available > > > endpoints, whereas with single VTEP per host you can use existing > > > mechanisms (either learning from source IP address or next-hop > > > distribution with BGP-like protocols). > > > > True. > > > > I see few options: > > > > - Signal different next hops in BGP for the application which runs > > across > > > > - Treat next hop in BGP as prefix indicator not as host route. In > > particular next hop resolves in IGP to a prefix which in turn could be > > used as set of GRE destination addresses > > > > - Signal such range explicitly. I think there will be a draft coming > > up on just that soon. > > Hi all, > > The draft that Robert mentioned is now available at > http://tools.ietf.org/html/draft-xu-idr-tunnel-address-prefix-00. Any > comments and suggestions are welcome. > > BTW, thanks Robert for your pre-announcement of this draft ;) > > Best regards, > Xiaohu >
