> -----邮件原件-----
> 发件人: Tom Herbert [mailto:[email protected]]
> 发送时间: 2017年10月19日 4:50
> 收件人: Xuxiaohu
> 抄送: [email protected]
> 主题: Re: [Int-area] FWD: New Version Notification for
> draft-xu-intarea-ip-in-udp-05.txt
> 
> On Tue, Oct 17, 2017 at 6:42 PM, Xuxiaohu <[email protected]> wrote:
> > 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%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

> Tom
> 
> > Best regards,
> > Xiaohu
> >
> >> -----邮件原件-----
> >> 发件人: [email protected] [mailto:[email protected]]
> >> 发送时间: 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
> >
> > _______________________________________________
> > Int-area mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to