Subject: RE: [Softwires] reworded charter

From: "Durand, Alain" <[email-masked]>
Date: Fri, 23 Sep 2005 16:04:31 -0400

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Friday, September 23, 2005 2:30 AM
> To: Mark Townsley
> Cc: Durand, Alain; [email-masked]
> Subject: Re: [Softwires] reworded charter
> I think the key point that needs to be emphasized here (and 
> it is ambiguous now) is that the tunnel endpoint is at a 
> different organization (be it a CPE router, a PC, or 
> whatever).  I haven't yet seen a justification for intra-ISP 
> tunnels (e.g., PE routers could be considered to be at 
> "network edge").
> 
> So I recommend s/a customer (or network edge) node/a customer 
> premises node/ below:
> 
> "The focus of this WG is to define a softwire setup 
> negotiation protocol and encapsulation to be use between a 
> customer (or network edge) node and the corresponding 
> softwire end-point."

Pekka,

I could go with your text, but still, I have a hard time to understand
why we should specifically restrict the problem space to "customer only"
at this point.

Please help me understand what this may change in the solution space.
What additional physical/contractual contraints (ok lack thereof) will
have any impact on the proctocol this wg will have to define?

   - Alain.

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Sep 2005 09:04:06 +0300 (EEST)

Hi,

Forgot to reply to this..

> why we should specifically restrict the problem space to "customer only"

During all the time that tunnel-broker -like techniques have been 
discussed in the IETF, I've never seen a real requirement from 
ISP-internal tunneling.  So, my (higher-level) response is, "because 
we know the problem statement for ISP-customer tunnels much, much 
better so we can converge on that much faster".

So, I'd consider restricting the stated applicability if not for any 
other reason than making it easier to actually get closure on the 
problem statement.

>From the top of my head, I don't see how the protocol would be 
different.  Note that I of course don't object if ISPs want to use 
this inside their topology even though I think it would be ill-advised 
-- the point is just that we should NOT be including them in the 
problem statement or the target audience.  If the protocol happens to 
work for them -- fine.  If it doesn't -- that's cool too.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings