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

From: Monika Machado <[email-masked]>
Date: Fri, 15 Jun 2012 16:26:06 +0000

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?

Thanks
Monika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Friday, May 11, 2012 1:56 AM
To: [email-masked]; Ivan Pepelnjak
Cc: [email-masked]; Keshava A K; [email-masked]; [email-masked]
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-masked]]
> 发送时间: 2012年5月9日 19:01
> 收件人: Ivan Pepelnjak
> 抄送: Keshava A K; [email-masked]; Xuxiaohu; [email-masked]; 
> [email-masked]
> 主题: 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

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 18 Jun 2012 01:57:32 +0000

> -----邮件原件-----
> 发件人: Monika Machado [mailto:[email-masked]]
> 发送时间: 2012年6月16日 0:26
> 收件人: Xuxiaohu; [email-masked]; Ivan Pepelnjak
> 抄送: [email-masked]; Keshava A K; [email-masked]; [email-masked]
> 主题: 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-
> 
> 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

> 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
> 
> 
> > -----邮件原件-----
> 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.
>