Subject: Re: [Softwires] WG LC Problem Statement (Francis Dupont - editorial)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 4 Jan 2006 17:14:44 -0600

Just following up on mailing list comments...

Spencer

> In your previous mail you wrote:
>
>       We are staring the WG last call on the problem statement draft:
>
> => 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

OK

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

Was fixed by previous editor.
>   setup time of the CPE/Address Family Boundry Router (AFBR)
>                     ^^^ the abbrev must be introduced before

OK.

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

OK.

>   CPE - Customer Premisis equipment (Host, small router, or "modem")
>                        ^ e
I think this is actually "customer premise equipment", but I did make a 
change...

> 3.  Hubs and Spokes Problem
>
>   which are shown in Diagram 1.
>                     ^ Reference
OK.

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

OK.

>   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:

I had redone case 3 based on Pekka comments - please see if you agree.

>
>                         +-------+  +------------+  +-------+
>  +-----+ |              |       |  |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!

OK

> 3.1.  Description
>
>   In this problem, ISPs (or large enterprise networks acting as ISP for
>                                                                   ^ s
OK.

>   network, reluctance to touch CPE, etc. are all reasons brought
>                                        ^ ,

Umm, I can't find this text in v4.

> 3.4.  Static Prefix Delegation
>
>   privacy extension or cryptographically generated addresses (CGA).
>
> => reference is RFC3972

OK.

>   attached behind it, a /64 prefix will be delegated.
>                                            ^^^^^^^^^
> => assigned
I saw discussion between Francis and Jordi on this - staying with 
"delegated" to match RFC language - is this the right answer?

> 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

"to be delegated" seems more consistent with RFC language, but I made a 
change. And what the heck does "be the same node" mean in an IP network, if 
it's not "the same IP address"? But I'll leave this for now.

> 3.6.  Softwire Concentrators
>
>   On the ISP side, softwires are termintated on a softwire
>                                        ^

This change was made by the previous editor.

>   contentrator.  An ISP may deploy several concentrators (for example
>      ^

This change was made by the previous editor.

>
> 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

OK
>
>   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.

OK.

>
> 3.8.  Scaling
>
>   of softwire inititators by adding more hubs (i.e. softwire
>                                                    ^ ,
OK

>   concentrator).
>               ^ s
OK

>
> 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...
>
and what we need is a default route, right?

> 3.12.  Operations and Management (OAM)
>
>   - End-point failure detection (must be encapsulated w/in the tunnel
>                                                       ^^^^ within
OK

>
> 3.13.  Encapsulations
>
>   IPv6/IPv4, IPv6/UDP/IPV4 and IPv4/IPv6 are on the critical path for
>                         ^ v
OK

> 4.  Mesh Problem
>   Figure 2
>   ^^^^^^^^
OK

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

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

>   The AFBR's are the only devices in the network that must be able to
>           ^
OK

>   Note that this creates a multipoint to point
>   reachability but, in essence a point to point logical overlay of
>   softwire connectivity.
>
> => terrible wording
Umm, yeah.

How about

Note that this creates multipoint-to-point reachability using a 
point-to-point logical overlay of softwire connectivity.</t>

>
>   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!
I'm sorry, I don't understand either the original point OR the comment - 
help!

>
> 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
>                                                    ^^
OK - "a single AFBR"

>   many islands if they have distinct routing and forwarding tables.
>                   ^^^^
I'm assuming "if it has"

>   Internet' (with respect to the islands native AF) plus, VPNs.  The
>                                                 ^^      ^
OK

>   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
Perhaps " The number of peering points of an AFBR will  be on the order of 
the number of  Autonomous System  Border Routers (ASBRs), which are assumed 
to be multiply peered to the transit core for reliability."?

>
>   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"
OK.

>
> 4.4.  AF/SAF Reachability
>
>   used over the softwire.  If native multicast services are enabled,
>                        ^ s
OK

>
> 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
OK

>   recomendations)
>       ^ m
OK

>
> => BTW they are in draft-bellovin-useipsec-04.txt
Got it. I'll use the reference here.

> "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
>                                                       ^^^^
OK

> 4.8.  Encapsulations
>
>   encapsulations, like IPv4/IPv4 or IPLS as defined in the L2VPN
>                                     ^^^^ please introduce the abbrev!
OK

>
> 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
OK

>
> 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]
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/softwires 

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