Re: [Softwires] comments on draft-carpenter-softwire-sample-00

[Mark Townsley <[e-mail]>]

On 9/30/10 12:02 AM, Templin, Fred L wrote:
> Mark, 
> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Mark Townsley
>> Sent: Tuesday, September 28, 2010 12:58 PM
>> To: [e-mail]
>> Subject: Re: [Softwires] comments on 
>> draft-carpenter-softwire-sample-00
>>
>> On 9/28/10 4:28 AM, Brian E Carpenter wrote:
>>> On 2010-09-28 15:09, Yiu L. Lee wrote:
>>>> Hi Washam,
>>>>
>>>> Don't forget there are also Softwire Hub-and-Spoke (L2TPv2 
>> based) and 6rd+.
>>>> So far, we don't hear much response to support this work 
>> in the operator's
>>>> community.
>>>
>>> One reason is that the smaller, more agile ISPs with problems
>>> in this area are simply figuring out how to deal with Teredo,
>>> e.g. with Tui boxes, http://www.braintrust.co.nz/tui/
>>
>> Oh yeah, that one too.
>>
>>>
>>> IMNSHO, cumbersome solutions like L2TPv2 will only appeal 
>> to telco-like
>>> operators.
>>
>> L2TP is often the NNI which allows a challenger ISP to setup 
>> service to
>> subscribers where the "telco-like" incumbent owns the 
>> physical layer (in
>> particular for remote locations where co-location might not be a
>> reasonable option). So, it ends up in a lot of different 
>> types of ISPs,
>> even those that do not have PPP anywhere else. The one place where it
>> almost never ends up is at a DOCSIS cable operator, which is where I
>> hear most of the resistance to its introduction.
>>
>> L2TP would and should lose a beauty contest with a brand new protocol
>> created today (surely we would have learned something in 15 years!).
>> However, on the concentrator side, virtually every SP vendor 
>> has an LNS
>> offering, alongside open source options if you want to go 
>> that route. On
>> the client side, it is in a number of RGs, pretty much every host OS,
>> not to mention your iPhone, iPad, Android... It's everywhere. Why not
>> just use it? PPP isn't *that* hard.
> 
> Actually, I had my first cursory look at L2TP only a
> few days ago. Without doing a deep dive into the spec,
> I am truly perplexed as to how you could have chastised
> my SEAL proposal as being "complex".
> 
> Some of the things I have seen so far in L2TP are
> variable-length headers prepared piecemeal instead
> of as a single unit, control messages spliced together
> from bits and pieces, cursory treatment of MTU issues,
> complicated connection control, tunnel "sessions" (?),
> ppp overlays (??), and I'm sure much more.
> 
> Most of this extra "stuff" looks to me like it was
> thrown in to compensate for the fact that L2TP does
> not seem to recognize the tunnel as a point-to-
> (multi)point interface with route configurations,
> neighbors and the like the same as for any interface.
> You should really have another look at SEAL.

I already admitted L2TP wouldn't win any beauty contests.

The point is running, interoperable, available, code. Particularly for a
transition mechanism that is targeted at being temporary.

- Mark

> 
> Fred
> [e-mail] 
> 
>> - Mark
>>
>>>
>>>    Brian
>>>
>>>>
>>>> Regards,
>>>> Yiu
>>>>
>>>>
>>>> On 9/27/10 9:49 PM, "WashamFan" 
>> <[e-mail]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please see inline.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: Brian E Carpenter <[e-mail]>
>>>>> Date: Tuesday, September 28, 2010 4:17 am
>>>>> Subject: Re: [Softwires] comments on 
>> draft-carpenter-softwire-sample-00
>>>>> To: WashamFan <[e-mail]>
>>>>> Cc: [e-mail]
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>  
>>>>>>  On 2010-09-27 21:05, WashamFan wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> It says,
>>>>>>>
>>>>>>>    The SAMPLE server will act as an IPv6 router.  In 
>> the simplest case,
>>>>>>>    it will forward all IPv6 packets to a default route, 
>> except those
>>>>>>>    whose destination address lies within the PSAMPLE 
>> prefix, which
>>>>>> will
>>>>>>>    be encapsulated and sent towards the host (CPE) and port
>>>>>> indicated by
>>>>>>>    the V4ADDR and PN values.
>>>>>>>
>>>>>>>
>>>>>>> I think it is not appropriate to assume NAT traversal without
>>>>>>> relay can be always successful.
>>>>>>  
>>>>>>  I don't understand your comment. If you have a NAT that 
>> you cannot
>>>>>>  traverse with UDP, you have many other problems, not just a lack
>>>>>>  of IPv6 connectivity.
>>>>> I misunderstood. I thought the text implies direct 
>> tunnels established
>>>>> instead of hairpinning via SAMPLE server when SAMPLE client to
>>>>> SAMPLE client communication occurs .
>>>>>
>>>>>>> Hairpinning might be always used
>>>>>>> for simplicity.
>>>>>>  
>>>>>>  Yes, that is the SAMPLE model. And it's a discussion for the
>>>>>>  community whether or not this is acceptable.
>>>>>>  
>>>>>>> I'd like to know the status of the draft, is the WG 
>> pursuing this
>>>>>>> work?
>>>>>>  
>>>>>>  There are three drafts aiming at the same problem, SAMPLE,
>>>>>>  draft-lee-softwire-6rd-udp, and draft-despres-softwire-6rdplus.
>>>>>>  Please hold your breath, there's hope of a joint proposal
>>>>>>  from several authors within a few days.
>>>>> Is it possible to combine all these efforts? I see 2 major
>>>>> difference between  draft-carpenter-softwire-sample-00
>>>>> and draft-lee-softwire-6rd-udp-02 at least:
>>>>>
>>>>> 1. According to the IPv6 address assignment, SAMPLE
>>>>> is  to connect isolated IPv6 hosts but 6rd-udp is to connect
>>>>> both isolated IPv6 hosts and LANs.
>>>>>
>>>>> 2. They are different in terms of IPv6 address assignment
>>>>> procedure. SAMPLE uses ND but 6rd-udp might use RADIUS,
>>>>> let's say.
>>>>>
>>>>> Personally, I think it is meaningful to work on tunneling
>>>>> IPv6 traversing NAT, but I think we should justify the work
>>>>> by clarifying how bad Teredo did the job before we reinvent
>>>>> the wheel.
>>>>>
>>>>> THanks,
>>>>> washam
>>>>>
>>>>>
>>>>>>     Brian
>>>>>>  
>>>>> _______________________________________________
>>>>> Softwires mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>
>>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>