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

["Templin, Fred L" <[e-mail]>]

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.

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
>