Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-02.txt

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Jul 2012 09:30:10 +0000

Hi all,

Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are widely used in the core of IP-enabled Packet Switch Networks (PSN) for load-balancing purposes. Most core routers (i.e., P routers) in the IP-enabled PSN are capable of load-balancing IP traffic flows across ECMP paths and/or LAG based on the hash of the five-tuple of UDP/TCP packets (i.e., source IP address, destination IP address, source port, destination port, and protocol) or some fields in the IP header of non-UDP/TCP packets (e.g., source IP address, destination IP address). However, with existing IP-based encapsulation methods as defined in [RFC4023] (e.g., MPLS-in-IP and MPLS-in-GRE), distinct customer traffic flows of various MPLS applications (e.g., MPLS-based L2VPN or L3VPN) between a given PE pair would be encapsulated with the same IP or GRE tunnel header prior to traversing the IP core. Since the encapsulating traffic is neither TCP nor UDP traffic, core routers could only perform hash calculation on the fields in the IP header of IP or GRE tunnels. As a result, core routers could not achieve an effective load-balancing for these traffic flows in the network due to the lack of adequate entropy information.

[RFC5640] describes a method for improving the load-balancing in Softwire mesh networks [RFC5565]. However, this method requires core routers to be able to perform hash calculation on the fields including the "load-balancing" field contained in the L2TPv3 or GRE tunnel header. [Entropy-Label] proposes to use the “entropy labels” for achieving a better load-balancing for MPLS traffic flows in the core of MPLS-enabled PSN. Although the entropy label could be inserted in the “Key” field of the GRE header by ingress PE routers in the case where the PSN is IP enabled rather than MPLS enabled, it still requires core routers to be capable of performing hash calculation on the “entropy label” contained in the GRE tunnel header. Any of the above load-balancing methods requires a change to the date plane of core routers. 

This document describes a new IP-based encapsulation method for MPLS packets referred to as MPLS-in-UDP, which is intended to facilitate load-balancing the traffic of various MPLS applications such as MPLS-based L2VPN and L3VPN in the core of IP-enabled packet switch networks where the core routers could not be upgraded due to some reason.

Any comments are welcome.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2012年7月13日 17:18
> 收件人: Xuxiaohu
> 抄送: [email-masked]; [email-masked]; Lucy yong;
> [email-masked]; Lizhenbin
> 主题: New Version Notification for draft-xu-mpls-in-udp-02.txt
> 
> 
> A new version of I-D, draft-xu-mpls-in-udp-02.txt
> has been successfully submitted by Xiaohu Xu and posted to the
> IETF repository.
> 
> Filename:	 draft-xu-mpls-in-udp
> Revision:	 02
> Title:		 Encapsulating MPLS in UDP
> Creation date:	 2012-07-13
> WG ID:		 Individual Submission
> Number of pages: 8
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-mpls-in-udp-02.txt
> Status:          http://datatracker.ietf.org/doc/draft-xu-mpls-in-udp
> Htmlized:        http://tools.ietf.org/html/draft-xu-mpls-in-udp-02
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-xu-mpls-in-udp-02
> 
> Abstract:
>    This document specifies one additional IP-based encapsulation
>    technology for MPLS packets referred to as MPLS-in-UDP, which is
>    intended to facilitate load-balancing the traffic of various MPLS
>    applications such as MPLS-based L2VPN and L3VPN in the core of IP-
>    enabled packet switch networks.
> 
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 13 Jul 2012 11:55:07 +0000

It looks like this draft is trying to bring the entropy label concept to GRE.  Two comments, perhaps opposing one another:

1) This really isn't an MPLS thing, it's a GRE thing.  If you really have a GRE problem to solve, do it regardless of payload.

2) I do not think this is a good idea for MPLS.  Every time we try to solve the same problem more than one way we always end up fragmented.  If you want to do MPLS, do MPLS; if you don't or can't, then don't.  

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Xuxiaohu
> Sent: Friday, July 13, 2012 5:30 AM
> To: [email-masked]
> Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-
> 02.txt
> 
> Hi all,
> 
> Equal Cost Multi-Path (ECMP) and Link Aggregation Group (LAG) are widely
> used in the core of IP-enabled Packet Switch Networks (PSN) for load-
> balancing purposes. Most core routers (i.e., P routers) in the IP-enabled PSN
> are capable of load-balancing IP traffic flows across ECMP paths and/or LAG
> based on the hash of the five-tuple of UDP/TCP packets (i.e., source IP
> address, destination IP address, source port, destination port, and protocol)
> or some fields in the IP header of non-UDP/TCP packets (e.g., source IP
> address, destination IP address). However, with existing IP-based
> encapsulation methods as defined in [RFC4023] (e.g., MPLS-in-IP and MPLS-
> in-GRE), distinct customer traffic flows of various MPLS applications (e.g.,
> MPLS-based L2VPN or L3VPN) between a given PE pair would be
> encapsulated with the same IP or GRE tunnel header prior to traversing the
> IP core. Since the encapsulating traffic is neither TCP nor UDP traffic, core
> routers could only perform hash calculation on the fields in the IP header of
> IP or GRE tunnels. As a result, core routers could not achieve an effective
> load-balancing for these traffic flows in the network due to the lack of
> adequate entropy information.
> 
> [RFC5640] describes a method for improving the load-balancing in Softwire
> mesh networks [RFC5565]. However, this method requires core routers to be
> able to perform hash calculation on the fields including the "load-balancing"
> field contained in the L2TPv3 or GRE tunnel header. [Entropy-Label] proposes
> to use the “entropy labels” for achieving a better load-balancing for MPLS
> traffic flows in the core of MPLS-enabled PSN. Although the entropy label
> could be inserted in the “Key” field of the GRE header by ingress PE routers
> in the case where the PSN is IP enabled rather than MPLS enabled, it still
> requires core routers to be capable of performing hash calculation on the
> “entropy label” contained in the GRE tunnel header. Any of the above load-
> balancing methods requires a change to the date plane of core routers.
> 
> This document describes a new IP-based encapsulation method for MPLS
> packets referred to as MPLS-in-UDP, which is intended to facilitate load-
> balancing the traffic of various MPLS applications such as MPLS-based L2VPN
> and L3VPN in the core of IP-enabled packet switch networks where the core
> routers could not be upgraded due to some reason.
> 
> > A new version of I-D, draft-xu-mpls-in-udp-02.txt has been
> > successfully submitted by Xiaohu Xu and posted to the IETF repository.
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 13 Jul 2012 09:27:46 -0400

Just to add to Eric's second point, in 2012, are there ANY core
routers that cannot forward MPLS packets natively?

Cheers,
Andy

---

From: Nischal Sheth <[email-masked]>
Date: Fri, 13 Jul 2012 18:06:41 -0700

> routers that cannot forward MPLS packets natively?

Hi Andy,

The applicability of MPLS-in-UDP is the same as that for MPLS-in-GRE,
with the difference that you would get better load balancing behavior
in the IP network if using UDP based encapsulation.

Consider the case of a cell site router that needs to back haul an
ethernet port to a hub/concentrator using a LDP-based PW. When the
intervening aggregation network does not support MPLS natively, one
could use MPLS-in-UDP.

This encapsulation would also be useful in data center deployments,
where the switching infrastructure is IP-only in many cases. Please
see http://tools.ietf.org/html/draft-marques-l3vpn-end-system for
one possible use case.

-Nischal

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 14 Jul 2012 09:28:31 -0400

Nischal,

Thanks, I'm aware of draft-marques, but draft-xu is explicitly focused
on core applications (or so it says, many times), so I didn't see data
center as a use case. I suggest that draft-xu be updated if it is also
intended for non-core applications, such as data center, mobile
backhaul, and/or aggregation networks. A sentence will do.

Cheers,
Andy

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Jul 2012 01:26:08 +0000

Hi Andy,

Thanks a lot for your suggestion. We will incorporate your suggestion in the next revision.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Andrew G. Malis
> 发送时间: 2012年7月14日 21:29
> 收件人: Nischal Sheth
> 抄送: [email-masked]
> 主题: Re: [mpls] New Version Notification for draft-xu-mpls-in-udp-02.txt
> 
> Nischal,
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Jul 2012 08:28:05 +0000

Hi Eric,

> -----邮件原件-----
> 发件人: Eric Osborne (eosborne) [mailto:[email-masked]]
> 发送时间: 2012年7月13日 19:55
> 收件人: Xuxiaohu; [email-masked]
> 主题: RE: New Version Notification for draft-xu-mpls-in-udp-02.txt
> 
> It looks like this draft is trying to bring the entropy label concept to GRE.  Two

On the contrary, the draft is actually trying to avoid bringing the entropy label concept to GRE.

> comments, perhaps opposing one another:
> 
> 
> 1) This really isn't an MPLS thing, it's a GRE thing.  If you really have a GRE
> problem to solve, do it regardless of payload.

This draft proposes to use UDP tunnels, rather than IP/GRE tunnels to convey MPLS traffic in case operators want to achieve a better load-balancing of MPLS traffic over the core of IP PSN.

> 2) I do not think this is a good idea for MPLS.  Every time we try to solve the
> same problem more than one way we always end up fragmented.  If you want
> to do MPLS, do MPLS; if you don't or can't, then don't.

As Nischal has pointed out in an email of the same thread, there are some MPLS L2 or L3 VPN scenarios (e.g., data center networks) where the transport network is IP-enabled, rather than MPLS-enabled due to some reasons. 

Best regards,
Xiaohu

---

From: Nischal Sheth <[email-masked]>
Date: Mon, 16 Jul 2012 10:10:56 -0700

Hi Andy,

Thanks, that's a fair comment - we will update the draft accordingly.

-Nischal