Subject: [Softwires] WG LC Problem Statement

From: David Ward <[email-masked]>
Date: Wed, 14 Dec 2005 13:36:55 -0600

All -
    We are staring the WG last call on the problem statement draft:

http://www.ietf.org/internet-drafts/draft-ietf-softwire-problem-statement-00
.txt

We will close the Last Call period December 31, 2005.

Many thanks

-DWard

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Dec 2005 09:28:42 +0100

In your previous mail you wrote:

=> I noted many things last week, here are the editorial comments
(please note I haven't yet read the other comments):

2.  Introduction

   The Softwires Working Group is specifying the standardization of
               ^ no s

   multicast trafic.  They are also assumed to be non-ephemeral in
                ^ traffic

   setup time of the CPE/Address Family Boundry Router (AFBR)
                     ^^^ the abbrev must be introduced before

2.1.  Terminology

   AFBR - Address Family Boundry Router (aka PE)
                                             ^^ ??
   (it is either CPE or PE without any introduction for the abbrev)

   CPE - Customer Premisis equipment (Host, small router, or "modem")
                        ^ e

3.  Hubs and Spokes Problem

   which are shown in Diagram 1.
                     ^ Reference

   Case 1: IPv6 connectivity across an IPv4 access network. Softwire
   initiator is the home gateway.
                                ^ (HGW)

   Case 3: IPv6 connectivity across an IPv4 access network. Softwire

                         +-------+  +------------+  +-------+
                         |       |  |Softwire    |  |IPv6   |
               +-----+   | IPv4  |--|concentrator|--|Network|=>Internet
          +----| HGW |---|       |  +------------+  +-------+
      -------- +-----+   |Network|
      |      |           +-------+
   +-----+ +----------+
   |Host | | softwire |
   +-----+ | initiator|
           +----------+
                        _ _ _ _ _ _ _ _ _
                      ()_ _ _ _ _ _ _ _ _()
                           "softwire"
   |------------------||-----------------||-------------------------|
          Dual stack       IPv4 only           IPv6 or dual stack

=> I propose another version with a clearer local LAN:

                         +-------+  +------------+  +-------+
  +-----+ |              |       |  |Softwire    |  |IPv6   |
  |Host |-+    +-----+   | IPv4  |--|concentrator|--|Network|=>Internet
  +-----+ +----| HGW |---|       |  +------------+  +-------+
          |    +-----+   |Network|
          |              +-------+
          | +----------+
          | | softwire |
          +-| initiator|
          | +----------+
                        _ _ _ _ _ _ _ _ _
                      ()_ _ _ _ _ _ _ _ _()
                           "softwire"
   |------------------||-----------------||-------------------------|
          Dual stack       IPv4 only           IPv6 or dual stack

   Figure 1
   ^^^^^^^^
=> this is only Reference Diagram 1!

3.1.  Description

   In this problem, ISPs (or large enterprise networks acting as ISP for
                                                                   ^ s
   network, reluctance to touch CPE, etc. are all reasons brought
                                        ^ ,
3.4.  Static Prefix Delegation

   privacy extension or cryptographically generated addresses (CGA).

=> reference is RFC3972

   attached behind it, a /64 prefix will be delegated.
                                            ^^^^^^^^^
=> assigned 

3.5.  Softwire Initiator

   The softwire initiator does not have to be always the same node
   and/or always have the same IP address.  In particular, in the
                 ^^^^ to get

3.6.  Softwire Concentrators

   On the ISP side, softwires are termintated on a softwire
                                        ^
   contentrator.  An ISP may deploy several concentrators (for example
      ^

3.7.  Softwire Concentrator Discovery

   When the initiator of the softwire is a CPE, the IP address or DNS
   hostname of the softwire concentrator must be known.  The simplest
   ^^^^

=> I propose name in place of hostname

   way for this to be known by the CPE is for it to be configured by the
   user, or by the provider of the CPE in advance.  Alternatively, an
   automated discovery phase may be run in order to return the IP
   address(s), or hostname(s) of the concentrator.  The details of this
                  ^^^^ DNS name(s)
   discovery problem are outside the scope of this document.

3.8.  Scaling

   of softwire inititators by adding more hubs (i.e. softwire
                                                    ^ ,
   concentrator).
               ^ s

3.9.  Routing

   As customers networks are typically attached via a single link to
   their ISP, a default or static route is the only thing that is needed
            ^           ^^
=> static and default are orthogonal properties...

3.12.  Operations and Management (OAM)

   - End-point failure detection (must be encapsulated w/in the tunnel
                                                       ^^^^ within

3.13.  Encapsulations

   IPv6/IPv4, IPv6/UDP/IPV4 and IPv4/IPv6 are on the critical path for
                         ^ v

4.  Mesh Problem

   Figure 2
   ^^^^^^^^

4.1.  Mesh Description

   differing address family type.  For an example, See Figure 1.  Note
                                                   ^^^^^^^^^^^^
=> see Reference Diagram 1

   that this is just an example and the converse AF problem may exist.
                                                 ^^ Address Family
(please don't use the AF abbrev)

   The AFBR's are the only devices in the network that must be able to
           ^
   Note that this creates a multipoint to point
   reachability but, in essence a point to point logical overlay of
   softwire connectivity.

=> terrible wording

   Layer 2 discovery performance issues.  It also prevents having to
                                                           ^^^^^^^^^
   have fully meshed point to point Layer 2 connectivity between the
   ^^^^
   nodes in differing islands as Layer 2 technology choice must be
   preserved.

=> same!

4.2.  Scaling

   In the mesh problem, the number of AFBRs is on the order of the
   number of islands though it should be clear that an AFBR could handle
                                                    ^^
   many islands if they have distinct routing and forwarding tables.
                   ^^^^
   Internet' (with respect to the islands native AF) plus, VPNs.  The
                                                 ^^      ^
   number of peering points of an AFBR will be on the order of any
   Autonomous System Border Router (ASBR) which are assumed to be
   multiply peered to the transit core for reliability.

=> bad wording

   also have multiple AFBRs for reliability as well.  Both the island or
   the transit core can contain route reflectors or hierarchical routing
                    ^^^
   with impunity.
   ^^^^^^^^^^^^^

=> I propose "may"

4.4.  AF/SAF Reachability

   used over the softwire.  If native multicast services are enabled,
                        ^ s

4.6.  Security

   In the data plane, the softwire solution must support IPsec and an
   IPsec profile will have to be defined. (see Steve Bellovin
                                                             ^ 's
   recomendations)
       ^ m

=> BTW they are in draft-bellovin-useipsec-04.txt
"Guidelines for Mandating the Use of IPsec", and I highly recommend
the section 8, i.e., we have to answer to its 8 questions.

4.7.  OAM

   - End-point failure detection (must be encapsulated w/in the tunnel
                                                       ^^^^
4.8.  Encapsulations

   encapsulations, like IPv4/IPv4 or IPLS as defined in the L2VPN
                                     ^^^^ please introduce the abbrev!

7.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

=> many missing refs...:
 - RFC2663 for NAT terminology (3.2)
 - RFC3041 and RFC3972 (3.4)
 - draft-bellovin-useipsec-04.txt (4.6)
 - draft-ietf-v6ops-ipsec-tunnels (6)
etc

Regards

[email-masked]

Li, et al.                Expires June 10, 2006                [Page 15]

Internet-Draft         Softwire Problem Statement          December 2005

Authors' Addresses

   Xing Li
   CERNET
   Room 225 Main Building, Tsinghua University
   Beijing 100084
   China

   Phone: +86 10 62785983
   Fax:   +86 10 62785933
   Email: [email-masked]

   Alain Durand
   Comcast
   1500 Market st
   Philadelphia
   PA 19102 USA

   Email: [email-masked]

   Shin Miyakawa
   NTT Communications
   3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku
   Tokyo
   Japan

   Phone: +81-3-6800-3262
   Fax:   +81-3-5365-2990
   Email: [email-masked]

   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas - Madrid
   E-28108 - Spain

   Phone: +34 91 151 81 99
   Fax:   +34 91 151 81 98
   Email: [email-masked]

Li, et al.                Expires June 10, 2006                [Page 16]

Internet-Draft         Softwire Problem Statement          December 2005

   Florent Parent
   Hexago
   2875 boul. Laurier, suite 300
   Sainte-Foy, QC  G1V 2M2
   Canada

   Phone: +1 418 266 5533
   Email: [email-masked]

   David Ward
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134
   USA

   Phone: +1-408-526-4000
   Email: [email-masked]

Li, et al.                Expires June 10, 2006                [Page 17]

Internet-Draft         Softwire Problem Statement          December 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Li, et al.                Expires June 10, 2006                [Page 18]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Dec 2005 09:54:26 +0100

=> I noted many things last week, here are the not-editorial comments
(please note I haven't yet read the other comments):

Network Working Group                                              X. Li
Internet-Draft                                                    CERNET
Expires: June 10, 2006                                         A. Durand
                                                                 Comcast
                                                             S. Miyakawa
                                                      NTT Communications
                                                                J. Palet
                                                             Consulintel
                                                               F. Parent
                                                                  Hexago
                                                                 D. Ward
                                                           Cisco Systems
                                                        December 7, 2005

=> there are too many authors (the limit is 5), I suggest to apply
http://www.rfc-editor.org/policy.html "Author Overload"

1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

=> IMHO it is not a good idea to use the requirement keywords in a
problem statement document. BTW they are not use in a coherent way
in this document.

=> as the CPE is the central concept it should be really fine to
explain where is this #@$ CPE in these 3 cases.

3.3.  Non upgradable CPE router

=> please explain this is related to cases 2 and 3, but not 1.

=> delegation is not assignment, i.e., take care to use the right term.

=> the term "hostname" (in place of simply "name") closes the door to
smarter scheme like RFC2782, i.e., SRV vs. A RRs.

3.11.1.  Authentication, Authorization and Accounting

   The softwire protocol must support user authentication in order to
   authorize access to the service, and provide adequate logging of
   activity (accounting).

=> I strongly object against the word "user" here: this limit the
scenarios to mono-user when multi-user boxes and systems can become
again the common case. We need a better word, as we have CPE every two
lines I propose "customer".

4.1.  Mesh Description

=> IMHO it is not clear in the document whether the case of private
IPv4 networks spread on many islands is supported...

4.6.  Security

   In contrast with the hub and spoke problem, routers are advertizing
   routers for relatively large islands, and never a single user so
   there is no "user authentication" necessary.  However, if running
   over an untrusted network, control or data plane security may be
   necessary.

=> s/user/customer/

6.  Security Considerations

   The softwire protocol (control plane) must support user

=> s/user/customer/

   authentication, and should be configurable to offer mutual
   authentication.  The authentication mechanism has to be compatible
   with existing AAA protocols.  The authentication must be protected
   using an already defined secure mechanism.

=> note the sections 4.6 and 6 need to say compatible things (:-).

Regards

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 30 Dec 2005 10:18:57 +0100

Hi Francis,

Just a couple of comments below, in-line.

(all editorial comments skipped, as they are/have already being corrected)

Regards,
Jordi

> De: Francis Dupont <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 29 Dec 2005 09:28:42 +0100
> Para: David Ward <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "Durand, Alain"
> <[email-masked]>
> Asunto: Re: [Softwires] WG LC Problem Statement
> 

[Jordi] I think is delegated, as in DHCP-PD (prefix delegation).

> => I propose name in place of hostname

Actually I think it should be just DNS (it implies already name ?).

>    differing address family type.  For an example, See Figure 1.  Note

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 30 Dec 2005 10:23:47 +0100

Again, just a couple of comments below, in-line.

Regards,
Jordi

> Fecha: Thu, 29 Dec 2005 09:54:26 +0100

We need to clarify why you insist is assignment, otherwise we may have to
reword DHCP-PD also ;-)

> smarter scheme like RFC2782, i.e., SRV vs. A RRs.

Agree, actually my be clear DNS RR ?

> lines I propose "customer".

Agree

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Dec 2005 16:20:27 +0100

=> I refer to the RIPE 267 which defines allocation and assignment,
here the /64 can't be delegated further so the best term is assignment.
(i.e., at least it is better than allocation)

   
=> not in my English but I am not the right person to decide.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Dec 2005 16:28:13 +0100

=> we have three possible terms:
 - allocation
 - assignment
 - delegation

RIPE 267 gives the usage of allocation vs. assignment. Delegation is more
for DNS zone but is used in DHCP-PD document.

PS: from RIPE 267:

2.5. Allocate

To «allocate» means to distribute address space to IRs for the purpose
of subsequent distribution by them.

2.6. Assign

To «assign» means to delegate address space to an ISP or End User for
specific use within the Internet infrastructure they
operate. Assignments must only be made for specific purposes
documented by specific organisations and are not to be sub-assigned to
other parties.

>From RFC 3769:

   With the deployment of IPv6 [1], several Internet Service Providers
   are ready to offer IPv6 access to the public.  In conjunction with
   widely deployed "always on" media such as ADSL and the expectation
   that customers will be assigned a /48 IPv6 unicast address prefix
   (see RFC 3513 [3] and section 3 of RFC 3177 [2]), an efficient
   mechanism for delegating address prefixes to the customer's sites is
   needed.  The delegation mechanism will be intended to automate the
   process of informing the customer's networking equipment of the
   prefixes to be used at the customer's site.

So delegation is more technical than administrative...?

Regards

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 31 Dec 2005 00:27:14 +0100

Hi Francis,

I think is unfortunate that we have not used since the beginning the same
terminology for RIRs and IETF, but right now, it will be better to keep
using IETF notation instead of confusing people when reading different IETF
documents.

Regards,
Jordi

> De: Francis Dupont <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 30 Dec 2005 16:28:13 +0100
> Para: <[email-masked]>
> CC: "[email-masked]" <[email-masked]>