Subject: RE: [Softwires] draft-ietf-softwire-problem-statement-01 comments

From: "Durand, Alain" <[email-masked]>
Date: Wed, 3 May 2006 10:08:04 -0400

Pekka,

Thank you for your thoughough (as always) review of the document.
I will agree with all your comments except the first one on L1 vs L2 vs
L3.

You raised that issue several times in the past and so far I have not
seen
much support in the wg for going there. Going to L2VPN in VPLS type of
tunnels
would certainly add complexity that has not (yet) been justified other
than
"this would be goog for completeness reasons".

Now, let me look at it from another angle. If one service provider is
already offering L2VPN to its customers, couldn't those simply "run"
IPv6 other
it? If this is true, what would softwires have to do in this context?

   - Alain.

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Wednesday, May 03, 2006 4:21 AM
> To: [email-masked]
> Subject: [Softwires] draft-ietf-softwire-problem-statement-01 comments
> 
> Hi,
> 
> I happened to have a long flight, so I went back and looked at the 
> problem statement again.  It was in much better shape.   Issue 1) is 
> old, I believe 3) is new and 4) is old but I don't recall 
> much discussion on it.  2) should be non-controversial.
> 
> substantial
> -----------
> 
> 1) my biggest concern (again, and still) is the dual-stack 
> "requirement"
> for AFBRs.  In very many places throughout the doc, this is 
> assumed.  But as said, this is not *required* to interconnect 
> islands with different address families.  If you take an 
> LxVPN analogue, folks started with L3VPNs, soon realized that 
> they want L2VPNs as well, and now are working on L1VPNs... it 
> seems shortsighted to focus this document on L3VPN only.  So 
> I suggest removing this requirement from the doc so that we 
> don't need to write another one if folks want to go for L2, 
> and describe both approaches -- the mesh solution is likely 
> the same for both of them so there should be no loss here.
> 
> 2) you should describe and refer to the manually configured 
> tunnels [RFC4213], in 2nd paragraph of 2.1 or introduction.  
> I.e., those tunnels are perfectly good approach in many 
> scenarios, but certain considerations (dynamic IP addr, nat 
> traversal are probably the most important ones) require 
> additional solutions.
> 
> 3) the charter does not include writing BCPs on SW 
> architectures and interactions, so this needs rewording.  I'm 
> not sure if such is even needed
> -- folks seem to have been able to deploy scalable L2TP 
> deployments without much IETF guidance...:
> 
>     Softwire concentrator functionality will be based on existing
>     standards for tunneling, prefixes and addresses allocation,
>     management.  The working group must define Best Current 
> Practices for
>     Softwires Concentrator architecture and interaction between these
>     protocols and recommend profiles.
> 
> 4) I still don't believe that it's a MUST to have both an 
> end-point and path-failure detection.  Should one of these be 
> a MAY or SHOULD?
> 
>     - End-point failure detection (the detection mechanism 
> must operate
>     within the tunnel)
> 
>     - Path failure detection (the detection mechanism must operate
>     outside the tunnel)
> 
> 
> semi-editorial
> --------------
> 
>    o  Softwires are to be used in IP/MPLS based networks to 
> forward both
>        unicast and multicast traffic.
> 
> ==> drop out MPLS from here or reword.  AFAICS, softwires 
> should in no way require MPLS in a network, and the design is 
> flawed if so.
> 
>     Address Family (AF) - IPv4 or IPv6.  Presently defined values for
>     this field are specified in RFC 1700 (see the Address 
> Family Numbers
>     section).
> 
> ==> this is no longer up to date, see
> http://www.iana.org/assignments/address-family-numbers
> 
> Typically the reasons
>     for this situation include a lack of vendor support for one of the
>     address families, the (perceived) cost of upgrading them, 
> complexity
>     of running both address families natively, operation/management
>     reasons to avoid upgrades (perhaps temporarily), or 
> economic reasons
>     (such as a commercially insignificant amount of traffic 
> with the non-
>     supported address family).
> 
> ==> I want to add "(perceived)" before "complexity of running 
> both address families natively".  This complexity is by no 
> means given, and especially if you're _still_ running the 
> other address family in most of your equipment, and/or in 
> tunnels, I'm not sure how much complexity there _really_ is..
> 
>     The softwire initiator does not have to be always the same node
>     and/or always have been delegated the same IP address.  In
>     particular, in the nomadic case (e.g. a user opening up 
> his laptop in
>     various Wi-Fi hot-spots), the softwire initiator could potentially
>     obtain an IP address of one address family outside its original
>     carrier network and still want to obtain the other address family
>     addresses from its original carrier.
> 
>     Nomadicity should be supported.
> 
> ==> you should really reword the above paragraph so that you 
> could remove the second one -- you're saying the same thing 
> more or less twice..
> 
>   The details of
>     this discovery problem are outside the scope of this document,
>     however previous work could be taken in consideration.  Examples
>     include: [I-D.durand-naptr-service-discovery], 
> [I-D.ietf-v6ops-ipsec-
>     tunnels], and [I-D.palet-v6ops-solution-tun-auto-disc].
> 
> ==> I hate to say, but [I-D.ietf-v6ops-ipsec-tunnels] does 
> not include such discovery, it just discusses it much the 
> same manner as this doc does (section 8).  The best reference 
> (I may be biased because I'm co-author) for analysis on this 
> is IMHO I-D.palet-v6ops-tun-auto-disc (i.e., without 
> _solution_ in the draft name).
> 
> 
> editorial
> ---------
> 
>     Home gateway - Existing piece of equipment that connects the home
>     network to the provider network.  Usually act as CPE for 
> one or both
>     address familly.
> 
> ==> s/familly/family/ (the same in other places)
> 
>     The converse cases exist, replacing IPv4 by IPv6 and vice versa
>     in the above figures.
> 
> 
>     Figure 1
> 
> ==> "Figure 1" appears to be run-away or did you put the 
> whole section 2 as one figure?  Maybe remove?
> 
>     Residential and small-office CPE equipment may be limited 
> to support
>     only one address familly.  Often, they are owned by a customer or
>     carrier who is unwilling or unable to upgrade them to run in dual
>     stack mode (as shown in Case 2 and Case 3).
> 
> ==> these are now cases 3 & 4 (the same also in the next paragraph)
> 
>    Link local addresses allocated at both ends of the tunnel 
> are enough
>     for packets forwarding, but for management purpose like 
> traceroute,
> 
> ==> s/packets/packet/
> 
>     Existing multicast solutions can be used over the softwire.
>     Typically, such solution would be either proxy Multicast Listener
>     Discovery or Internet Group Membership Protocol and Protocol-
>     Independent Multicast.
> 
> ==> the later sentence is not clear how you should group 
> "proxy", MLD, IGMP and PIM.  Suggest rephrasing:
> 
>     Typically, such solution would be either MLD/IGMP proxy
>     [I-D.ietf-magma-igmp-proxy] or Protocol-Independent Multicast.
> 
> ...
> 
>     o  Although Softwires are long-lived, the setup time of a 
> softwire is
>        expected to be a very small fraction of the total time required
>        for startup of the Customer Premise Equipment 
> (CPE)/Address Family
>        Boundary Router (AFBR).
> 
> ==> in most cases you use AFBR for Address Family _Border_ 
> Router, in two places you use _Boundary_.  Make it consistent.
> 
>    In the data plane, the softwire solution must support IPsec and an
>     IPsec profile will must be defined. (see recommendations in
>     [I-D.bellovin-useipsec]).
> 
> ==> remove either "will" or "must".
> 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/softwires
> 

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 May 2006 09:02:21 +0300 (EEST)

On Wed, 3 May 2006, Durand, Alain wrote:
> You raised that issue several times in the past and so far I have 
> not seen much support in the wg for going there.

Have you seen objection ?

> Going to L2VPN in VPLS type of tunnels would certainly add 
> complexity that has not (yet) been justified other than "this would 
> be goog for completeness reasons".

I'm not sure if I have seen that complexity -- AFAIK, the solutions 
use very similar techniques, with already existing and deployed IETF 
solutions.

If anything, it _could_ decrease the amount of complexity in the ISP 
network as it would not need to run all its PE routers as dual-stack 
(but could use v6-only if it wanted to).

> Now, let me look at it from another angle. If one service provider 
> is already offering L2VPN to its customers, couldn't those simply 
> "run" IPv6 other it? If this is true, what would softwires have to 
> do in this context?

The same would apply for L3VPN with service provider using 
draft-ietf-l3vpn-bgp-ipv6-07.txt (in RFC ed queue).

I.e., you can't just look at LxVPN like they're used for intra-site 
VPNs for how softwire scenarios would play out.

The mesh scenarios will need to consider how the customer will 
interconnect with other customers of the ISP and the rest of the 
Internet.

So, how could L2 softwires address this?  CPE boxes are connected with 
an IPLS offering a virtual LAN ("IPv4 Exchange Point"), so they can 
exchange traffic directly.  The service provider can also provide its 
own services (e.g., upstream connectivity or aggregating routers for 
those who don't want to build a full mesh) on that "exchange".  PEs 
don't need to be dual-stack.

Whether this approach is preferable to L3 softwires depends a lot on 
the ratio of CPE vs PE boxes and which ones would be required to be 
dual-stack.