-- As GRE/UDP draft shepherd > > Do equivalent arguments apply also to > > <https://datatracker.ietf.org/doc/draft- > ietf-tsvwg-gre-in-udp-encap/>?
Not exactly ;-). The motivating GRE in UDP encap use cases involves operator use of GRE for traffic management, as summarized in the draft introduction (Section 1 - the word "transit" is crucial): ... the source port field in the UDP header may be used to provide additional entropy that may be used for load balancing GRE traffic in transit networks using existing Equal-Cost Multi-Path (ECMP) mechanism. An interesting consequence is that the GRE in UDP encap draft specifies that the GRE and UDP tunnels MUST share endpoints - the GRE and UDP headers are applied at the same network node and are removed at the same network node. So, yes, we did pay attention to use cases over in TSVWG ... -- As an individual Like, Brian, I don't understand the softwire motivation for IP-in-UDP tunnels, and hence oppose intarea WG adoption of this draft. Xiaohu's response to Brian is unhelpful (IMHO): > I don't understand what you meant. You don't know what the Softwire > service traffic is? If so, please refer to RFC5565. That suggests to me that the draft is missing a brief overview of Softwires, and probably also lacks an applicability statement limiting the scope of this draft to Softwires. Section 8 of RFC 5565 on "Selecting a Tunneling Technology" is not helpful in explaining why IP-in-IP tunnels are wanted (which would then set up the discussion in this draft about why IP-in-UDP-in-IP tunnels are wanted courtesy of deployed equipment ECMP limitations on IP-in-IP tunnels). Thanks, --David > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Brian E > Carpenter > Sent: Friday, May 20, 2016 12:46 AM > To: Carlos Pignataro (cpignata) > Cc: [email protected] > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > On 20/05/2016 15:39, Carlos Pignataro (cpignata) wrote: > > Do equivalent arguments apply also to > > <https://datatracker.ietf.org/doc/draft- > ietf-tsvwg-gre-in-udp-encap/>? > > I don't know. I've never found GRE a very interesting topic so I've never > looked at > that draft. > > > Was this one reviewed by Int-area? > > Not as far as I know, but it's still technically in TSVWG last call if you > have > comments. > > Brian > > > > > Thumb typed by Carlos Pignataro. > > Excuze typofraphicak errows > > > >> On May 19, 2016, at 21:17, Brian E Carpenter <[email protected]> > wrote: > >> > >> As a famous physicist once said when the discovery of the muon was > announced, "Who ordered that?" > >> > >> In other words, I don't understand the use case that motivated this. > >> In the Introduction, I find: > >> > >> "By encapsulating the Softwire > >> service traffic into an UDP tunnel and using the source port of the > >> UDP header as an entropy field, the existing load-balancing > >> capability as mentioned above can be leveraged to provide fine- > >> grained load-balancing of Softwire service traffic traffic over IP > >> networks." > >> > >> What is meant by "the Softwire service traffic"? Does it just mean a > >> bunch of traffic from a single customer? Why does it all need a > >> common header for load balancing? The individual microflows in the > >> traffic will all get load-balanced anyway. > >> > >> I trust we are only talking about IPv6. If we're talking about IPv4, we > >> certainly shouldn't be developing new methods. If we're talking about > >> IPv6, we have the flow label for this (and it avoids tricky problems > >> like finding the transport header in the presence of extension headers). > >> That's already covered in RFC 6438 for any kind of tunnel, although > >> IP in IP seems a lot simpler than IP in UDP in IP. > >> > >> (If you really must do IPv4, IPv4 in IPv6 could still be load-balanced > >> as per RFC 6438, I guess.) > >> > >> Brian > >> > >> > >>> On 20/05/2016 05:03, Wassim Haddad wrote: > >>> Dear all, > >>> > >>> The authors of draft-xu-intarea-ip-in-udp-03 (“Encapsulating IP in UDP”) > have requested that the working group adopt this work as a WG work item. > >>> So far, WG chairs have not seen widespread support and considering that > lack of opposition does not qualify as support, we’re starting a working group > adoption call until June 3rd. > >>> > >>> If you consider that the draft should be adopted as a WG work item, please > indicate the reason. > >>> > >>> > >>> Regards, > >>> > >>> Wassim & Juan Carlos > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > _______________________________________________ > 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
