On 9/30/10 12:02 AM, Templin, Fred L wrote: > Mark, > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Mark Townsley >> Sent: Tuesday, September 28, 2010 12:58 PM >> To: [email protected] >> 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 > [email protected] > >> - Mark >> >>> >>> Brian >>> >>>> >>>> Regards, >>>> Yiu >>>> >>>> >>>> On 9/27/10 9:49 PM, "WashamFan" >> <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> Please see inline. >>>>> >>>>> ----- Original Message ----- >>>>> From: Brian E Carpenter <[email protected]> >>>>> Date: Tuesday, September 28, 2010 4:17 am >>>>> Subject: Re: [Softwires] comments on >> draft-carpenter-softwire-sample-00 >>>>> To: WashamFan <[email protected]> >>>>> Cc: [email protected] >>>>> >>>>> >>>>>> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
