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

From: Pekka Savola <[email-masked]>
Date: Wed, 3 May 2006 11:20:40 +0300 (EEST)

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