Hi Brain, Thanks for your comments. Please see my response inline.
> -----Original Message----- > From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Brian E > Carpenter > Sent: Friday, May 20, 2016 9:17 AM > To: Wassim Haddad; int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > 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 don't understand what you meant. You don't know what the Softwire service traffic is? If so, please refer to RFC5565. > 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 It's not a new load-balancing method at all. Instead, as mentioned in the draft "Most existing routers in IP networks are already capable of distributing IP traffic "microflows" [RFC2474] over ECMP paths and/or LAG based on the hash of the five-tuple of User Datagram Protocol (UDP) [RFC0768] and Transmission Control Protocol (TCP) packets (i.e., source IP address, destination IP address, source port, destination port, and protocol)." > 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.) It said in the draft that " IPv6 flow label has been proposed as an entropy field for load balancing in IPv6 network environment [RFC6438]. However, as stated in [RFC6936], the end-to-end use of flow labels for load balancing is a long-term solution and therefore the use of load balancing using the transport header fields would continue until any widespread deployment is finally achieved. As such, IP-in-UDP encapsulation would still have a practical application value in the IPv6 networks during this transition timeframe. " If you believe the following statement quoted from RFC6438 is not correct, please correct it by evidences. "the end-to-end use of flow labels for load balancing is a long-term solution and therefore the use of load balancing using the transport header fields would continue until any widespread deployment is finally achieved." Best regards, Xiaohu > 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 > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
