Subject: [Int-area] FWD: New Version Notification for draft-xu-intarea-ip-in-udp-05.txt

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Oct 2017 01:42:24 +0000

Hi all,

I just submitted a revision (https://www.ietf.org/rfcdiff?url2=draft-xu-intarea-ip-in-udp-05). Any further comments and suggestions are welcome.

BTW, it said in Google's Espresso paper (http://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwib0cntgfnWAhVHso8KHWF2BmQQFghAMAM&url=http%3A%2F%2Fwww.cs.princeton.edu%2Fcourses%2Farchive%2Ffall17%2Fcos561%2Fpapers%2Fespresso17.pdf&usg=AOvVaw2SgiqQ-ahnvRnEN_QYlxrZ) that "...We use a range of addresses for the encap IP header for sufficient hashing entropy as switches in the aggregation layer cannot look beyond the outer IP header for hashing..." Note that IP-in-GRE and MPLS-in-GRE encapsulations are currently used for incoming and outgoing traffic in Google's Espresso respectively according to the above paper. I believe that IP-in-UDP (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-05) and MPLS-in-UDP [RFC7510] should be better choices than IP-in-GRE and MPLS-in-GRE respectively once the former could be supported by major chip and network vendors. Fortunately, MPLS-in-UDP has already been supported by major chip and network vendors since its corresponding IETF standard was published. I believe the same thing would happen on IP-in-UDP :)

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2017年10月18日 9:06
> 收件人: Hamid Assarpour; Yiu Lee; Xuxiaohu; Fan Yongbing; Yiu Lee; Yongbing
> Fan; Shaowen Ma
> 主题: New Version Notification for draft-xu-intarea-ip-in-udp-05.txt
> 
> 
> A new version of I-D, draft-xu-intarea-ip-in-udp-05.txt has been successfully
> submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-intarea-ip-in-udp
> Revision:	05
> Title:		Encapsulating IP in UDP
> Document date:	2017-10-17
> Group:		Individual Submission
> Pages:		11
> URL:
> https://www.ietf.org/internet-drafts/draft-xu-intarea-ip-in-udp-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/
> Htmlized:       https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-05
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-xu-intarea-ip-in-udp-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-xu-intarea-ip-in-udp-05
> 
> Abstract:
>    Existing IP-in-IP encapsulation technologies are not adequate for
>    efficient load balancing of IP-in-IP traffic across IP networks.
>    This document specifies additional IP-in-IP encapsulation technology,
>    referred to as IP-in-UDP (User Datagram Protocol), which can
>    facilitate the load balancing of IP-in-IP traffic across IP networks.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Oct 2017 13:39:54 -0700

Xiaohu,

This document should refer to the new versions of the IPv6 and IPv6 PMTU RFCs specifications (RFC8200 and RFC8201). Please check if you need to change any text in your draft to be consistent with these.

Thanks,
Bob

> On Oct 17, 2017, at 6:42 PM, Xuxiaohu <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Oct 2017 13:50:18 -0700

> BTW, it said in Google's Espresso paper (http://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwib0cntgfnWAhVHso8KHWF2BmQQFghAMAM&url=http%3A%2F%2Fwww.cs.prince…
There is also GRE-in-UDP RFC8086. However, the best choice is to hash
over three tuple (src addr, dst addr, flow label) for IPv6-- no
encapsulation overhead, works with any transport layer protocol, no
need for DPI. IMO that's the support that chip and network vendors
should be targeting.

Tom

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Oct 2017 23:40:57 +0000

> -----邮件原件-----
> 发件人: Tom Herbert [mailto:[email-masked]]
> 发送时间: 2017年10月19日 4:50
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> 主题: Re: [Int-area] FWD: New Version Notification for
> draft-xu-intarea-ip-in-udp-05.txt
> 
> > I just submitted a revision
> (https://www.ietf.org/rfcdiff?url2=draft-xu-intarea-ip-in-udp-05). Any further
> comments and suggestions are welcome.
> >
> > BTW, it said in Google's Espresso paper
> >
> (http://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad
> >
> =rja&uact=8&ved=0ahUKEwib0cntgfnWAhVHso8KHWF2BmQQFghAMAM&url=
> http%3A%2
> >
> F%2Fwww.cs.princeton.edu%2Fcourses%2Farchive%2Ffall17%2Fcos561%2Fpap
> er
> > s%2Fespresso17.pdf&usg=AOvVaw2SgiqQ-ahnvRnEN_QYlxrZ) that "...We use a
> > range of addresses for the encap IP header for sufficient hashing
> > entropy as switches in the aggregation layer cannot look beyond the
> > outer IP header for hashing..." Note that IP-in-GRE and MPLS-in-GRE
> > encapsulations are currently used for incoming and outgoing traffic in
> > Google's Espresso respectively according to the above paper. I believe
> > that IP-in-UDP
> > (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-05) and
> > MPLS-in-UDP [RFC7510] should be better choices than IP-in-GRE and
> > MPLS-in-GRE respectively once the former could be supported by major
> > chip and network vendors. Fortunately, MPLS-in-UDP has already been
> > supported by major chip and network vendors since its corresponding
> > IETF standard was published. I believe the same thing would happen on
> > IP-in-UDP :)
> >
> There is also GRE-in-UDP RFC8086. However, the best choice is to hash over
> three tuple (src addr, dst addr, flow label) for IPv6-- no encapsulation overhead,
> works with any transport layer protocol, no need for DPI. IMO that's the support
> that chip and network vendors should be targeting.

GRE-in-UDP is more suitable for those scenarios where the GRE header is a must for whatever reasons (e.g., NVGRE in which the NVI is stored in the GRE header), IMHO. Otherwise, I don't see the value of adding the GRE header in between since the UDP destination port is enough to indicate the payload type of the UDP tunnel. 

For the IPv6 case, I agree that FL-based LB should be pursued in the long run. However, since it requires all intermediate routers along the forwarding path to be upgraded to support such a LB mechanism, it seems worthwhile to consider how to leverage the existing five-tuple-based LB mechanism in the transition period of time. For more details about the reason why the use of load balancing using the transport header fields would continue until any widespread deployment [of the FL-based LB mechanism] is finally achieved, see section 1.3.5 of [RFC6936].

Best regards,
Xiaohu

> >> 收件人: Hamid Assarpour; Yiu Lee; Xuxiaohu; Fan Yongbing; Yiu Lee;
> >> Yongbing Fan; Shaowen Ma
> >> A new version of I-D, draft-xu-intarea-ip-in-udp-05.txt has been
> >> successfully submitted by Xiaohu Xu and posted to the IETF repository.
> >>
> >> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-xu-intarea-ip-in-udp-05
> >>
> >> Abstract:
> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 18 Oct 2017 23:45:50 +0000

Hi Bob,

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

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Bob Hinden [mailto:[email-masked]]
> 发送时间: 2017年10月19日 4:40
> 收件人: Xuxiaohu
> 抄送: Bob Hinden; [email-masked]
> 主题: Re: [Int-area] New Version Notification for
> This document should refer to the new versions of the IPv6 and IPv6 PMTU RFCs
> specifications (RFC8200 and RFC8201). Please check if you need to change any
> text in your draft to be consistent with these.
> 
> Thanks,
> Bob
> 
> 
>