Hi David, > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Black, David > Sent: Friday, May 20, 2016 10:31 PM > To: Brian E Carpenter; Carlos Pignataro (cpignata) > Cc: [email protected] > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > -- 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.
I had thought the Softwire use cases are well-known to the IETF folks and therefore there is no need for a brief overview of that technology. > 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 IP-in-IP tunnels are used for carrying IPv6 traffic over IPv4 networks (see the 6rd usage as described in RFC5596 and RFC5969 and IPv6-in-IPv4 encapsulation format as described in https://tools.ietf.org/html/rfc4213#page-7) and IPv4 traffic over IPv6 networks. BTW, the IPv4-in-IPv6 and IPv6-in-IPv4 scenarios have been described in section 3 of RFC5565. Section 8 of the same RFC just lays out the rationale for RFC5512 which describes how to advertise tunnel capabilities via BGP. Best regards, Xiaohu > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
