Subject: [mpls] Technical Review of draft-xu-mpls-in-udp-03

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 3 Dec 2012 02:10:40 +0000

Hi,

Please find a set of observations, comments and suggestions regarding draft-xu-mpls-in-udp-03, from reading and reviewing the document. I do find the document very well written, and while the requirements are well articulated, there are some apparent leaps as described below.

More substantive:

1. Introduction

   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.

The Introduction in this document makes some fairly strong statements supporting its conclusion. For example, "Since the encapsulation is neither TCP nor UDP, core routers could only perform a hash on IP header fields". I am not sure of the intended meaning of the "could" in that sentence -- however from a technical perspective, it's incomplete. Certainly, core routers "could" perform a hash calculation for load-balancing from other fields. For MPLS-in-IP, and in particular for the case of MPLS-in-IPv6, the IPv6 Flow Label "could" be used [RFC 6438]. For GRE, the GRC Key can be used [RFC 5640].

   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.

Consequently, "lack of entropy information" is not a reason. The fields and entropy exist already.

Further, the case made in this document is based on two requirements: i. MPLS-in-some_form_of-IP, and ii., IP load-balancing based on UDP/TCP transport ports. It would be useful to have citations that would qualify, quantify, and better substantiate these requirements. Pointers?

Additionally, this document proposes the creation of a new MPLS-in-IP encapsulation. This new encapsulation requires not only specification but also development. However, the requirements that drive the document, by implication, seem to be under the premise that core loadbalancing of other entropy fields is not a solution as it is not developed. It would be interesting to understand a comparative analysis of hashing on other transports and adding to the LB paths, versus creating a new encapsulation.

3. Encapsulation in UDP

...
            Source Port of UDP

                To ensure that the source
                port number is always in the range 49152 to 65535 which
                may be required in some cases, instead of calculating a
                16-bit hash, the ingress PE router could calculate a 14-
                bit hash and use those 14 bits as the least significant
                bits of the source port field while the most significant
                two bits would be set to binary 11. That still conveys
                14 bits of entropy information which would be enough as
                well in practice.

Is there an implication of 14 bits of entropy versus 32 bits of Key, 20 bits of Flow Label/MPLS Label, etc?

            UDP Checksum

                The usage of this field is in accordance with the
                current UDP specification. To simplify the operation on
                egress PE router, this field is recommended to be set to
                zero.

And for MPLS-over-UDP-over-IPv6? draft-ietf-6man-udpzero-07 and draft-ietf-6man-udpchecksums-04?

4. Signaling for Encapsulation in UDP

I agree with Eric Osborne's observations on this section. Additionally, this section really pollutes an "encapsulation" draft.

8. IANA Considerations

   Two distinct UDP destination port numbers indicating MPLS and MPLS
   with upstream-assigned label respectively need to be assigned by
   IANA.

It is not evident (or explicit) in the document why two ports, when other MPLS-in-IP encaps do not have separate ones.

More editorial:

   [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.

Since this document describes various MPLS-in-IP encapsulations and their capabilities for LB, should probably also include and cite [RFC 4817]

5. Processing Functions

   P routers, upon receiving these UDP encapsulated packets, could
   balance these packets based on the hash of the five-tuple of UDP
   packets.

Is this setting a new requirement for "P routers", making a statement of existing ubiquitous support (citation), or describing an applicability statement for the encapsulation?

   Upon receiving these UDP encapsulated packets, egress PE routers
   would decapsulate them by removing the UDP headers and then process
   them accordingly.

The document should also discuss packet size issues, PMTUD, MTU, etc.

Thanks,

-- Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 3 Dec 2012 06:52:49 +0000

Hi Carlos,

Thanks a lot for your comments. Please see my response in line.

发件人: [email-masked] [mailto:[email-masked]] 代表 Carlos Pignataro (cpignata)
发送时间: 2012年12月3日 10:11
收件人: [email-masked]
抄送: [email-masked]
主题: [mpls] Technical Review of draft-xu-mpls-in-udp-03

Hi,

More substantive:

1. Introduction

   As

   entropy information.

[Xiaohu] The above statement is about the MPLS-in-GRE encap without using the Key field as a “load-balancing” field. As for the load-balancing approach for MPLS-in-GRE using Key field as a “load-balancing” field, it is discussed in the subsequent paragraph. BTW, these statements have been reorganized for readability in the -04 version. Please see whether it’s OK.

[Xiaohu] Gap analysis of existing technologies and the motivation for MPLS-in-UDP have been explained more clearly in the -04 version, please see whether it’s OK.

3. Encapsulation in UDP

...

            Source Port of UDP

                well in practice.

[Xiaohu] Will add a description of this implication in the next revision.

            UDP Checksum

                zero.

[Xiaohu] Will add references to the above two drafts in the next revision.

[Xiaohu]  This section has been simplified greatly in the 04 version. If the WG consensus is that this section should be removed completely, we can do that in the next revision.

8. IANA Considerations

   IANA.

[Xiaohu] MPLS-in-GRE also needs two prototype codes to represent MPLS and MPLS with a upstream-assigned label respectively. Please see section 4 of RFC4023, it said “The protocol type field in the GRE header  MUST be set to the Ethertype value for MPLS Unicast (0x8847) or  Multicast (0x8848).”

More editorial:

   tunnel header.

[Xiaohu] The reference to [RFC 4817] has been added in the -04 version according to your previous suggestion.

5. Processing Functions

   packets.

[Xiaohu] No new requirement for P routers. It just describes an applicability statement.

   them accordingly.

[Xiaohu] Your observation is correct. This has been addressed in the -04 version according to Eric Osborne's comment.

Thanks again for your valuable comments.

Best regards,
Xiaohu

Thanks,

-- Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 5 Dec 2012 18:36:00 +0000

Hi Xiaohu,

Thanks, please see inline.

On Dec 3, 2012, at 1:52 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表 Carlos Pignataro (cpignata)
发送时间: 2012年12月3日 10:11
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: [mpls] Technical Review of draft-xu-mpls-in-udp-03

Hi,

More substantive:

1. Introduction

   As

   entropy information.

This is much more readable -- but I think it still has sentences that are overreaching. For example, the following two sentences relate to "With existing IP-based encapsulation methods for MPLS applications":

   Since the
   encapsulated traffic is neither TCP nor UDP traffic, core routers
   could only perform hash calculation on fields in the IP headers of
   those tunnels (i.e., source IP address, destination IP address).

and

   As
   a result, core routers could not achieve a fine-grained load
   balancing of these traffic flows across the network core due to the
   lack of adequate entropy information.

and as indicated these are overgeneralized since you are talking of "existing IP-based encapsulation methods".

It is better explained, yes. Thanks.

3. Encapsulation in UDP

...

            Source Port of UDP

                well in practice.

Thanks.

            UDP Checksum

                zero.

Thanks.

Is the section needed at all?

8. IANA Considerations

   IANA.

More editorial:

   tunnel header.

5. Processing Functions

   packets.

   them accordingly.

I am not sure I see any discussion on packet size.

Thanks to you for a most quick turnaround and responding and addressing all comments!

-- Carlos.

Best regards,
Xiaohu

Thanks,

-- Carlos.