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
