Subject: [RRG] Reminder: Conceptual Summary and Analysis documents due tomorrow

From: Lixia Zhang <[email-masked]>
Date: Sun, 2 Mar 2008 21:16:28 -0800

A friendly reminder for those proposals that have not submitted yet: a  
summary and an analysis document is due tomorrow March 3rd.

> Below was a msg sent to RRG 2 months ago asking the backers of each  
> proposal to submit a conceptual summary and an analysis document.   
> Embarrassingly, I forgot the deadline myself (somehow I wrongly got  
> Philly IETF as deadline in my mind:(
>
> Thanks to Robin who reminded us about this (see his msg February 19,  
> 2008 7:00:47 AM PST) and was the first one to submit the requested  
> documents!
>
> We still believe that a summary and an analysis document for each  
> proposal would be a tremendous help towards systematic comparisons  
> of various proposals.  It is our fault for not reminding the group  
> about the deadline ahead of time.  We'd like to remedy the situation  
> by extending the submission deadline to March 3, that would leave  
> one week for people to work on the document, and one week for the  
> group to review the documents before our Philly meeting.
>
> Tony and Lixia
>
> On Dec 20, 2007, at 12:47 PM, Lixia Zhang wrote:
>
>> Hi all,
>>
>> As we've discussed, RRG aims to converge on a single recommended  
>> solution for a scalable routing and addressing architecture over  
>> the next year.  Towards that end, we would like to ask the backers  
>> of the various proposals to prepare some documents to aid in our  
>> comparison and discussions of proposals.
>>
>> 1) Conceptual Summary
>> This document should summarize the entire proposal at a conceptual  
>> level, and explain the fundamental ideas behind the proposal.  It  
>> is important that the document clearly identify whether the  
>> proposal is a complete solution to a scalable routing architecture,  
>> or one function in a complete solution.  In the latter case, it  
>> should also identify the other functions of the solution the  
>> proposal depends on, and give a clear description of the interface  
>> to these other functions.
>>
>> 2) Analysis
>> This document should compare the proposal against the RADIR problem  
>> statement and the design goals draft.
>>
>> Each of the above two documents should be 4 pages or less,  
>> including all the tables and figures if any, but excluding the  
>> reference list, with font size 11pt or larger, and 1 inch margin on  
>> each side.  A proposal may provide a combined document that  
>> encompasses both of these with a total length of 8 pages or less.
>>
>> Finished documents should be added to the RRG wiki page under  
>> "Proposal Summaries" whenever they are ready, but should be no  
>> later than the Internet draft -00 deadline for Philadelphia, which  
>> is Feb 18., 22:00 UTC, to leave adequate time for discussions  
>> before our next meeting.
>>
>> Note that this request for documenting the conceptual summary and  
>> analysis is only the first step towards systematic comparisons of  
>> various proposals.  Our final design recommendation will need  
>> substantially more work to aid the evaluation process, such as the  
>> performance evaluation and incremental deployment/migration  
>> strategies.  We encourage people to start working on these issues  
>> early; they should also be documented in due time.
>>
>> Regards,
>> Tony and Lixia
>>
>>
>> --
>> to unsubscribe send a message to [email-masked] with the
>> word 'unsubscribe' in a single line as the message text body.
>> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>
>
> --
> to unsubscribe send a message to [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Brian Dickson <[email-masked]>
Date: Mon, 03 Mar 2008 16:53:59 -0500

> summary and an analysis document is due tomorrow March 3rd.
Okay, I've decided to put my proposal down on "paper". (Attached in ID 
format.)

I'll upload it to the wiki site as well.

Comments are certainly welcome - it's a first draft, and I might have 
missed some obvious problem areas.

Brian Dickson

rrg                                                           B. Dickson
Internet-Draft                                       Afilias Canada, Inc
Expires: September 4, 2008                                 March 3, 2008

  V6DH: Incremental IPv6 Dual-Homing Approach for addressing end-site
            reliability needs (per RADIR problem statement)
                       draft-dickson-rrg-v6dh-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 4, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Dickson                 Expires September 4, 2008               [Page 1]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

Abstract

   This Internet Draft describes .

   FIXME

Dickson                 Expires September 4, 2008               [Page 2]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

Author's Note

   This Internet Draft is intended to result in this draft or a related
   draft(s) being placed on the Standards Track for rrg.

   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 [1].

   Intended Status: Proposed Standard.

Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Proposal . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Addressing Convention - Format . . . . . . . . . . . .  4
       1.1.2.  FIB/host lookup changes  . . . . . . . . . . . . . . .  5
       1.1.3.  DNS tweaks for sites/hosts . . . . . . . . . . . . . .  5
       1.1.4.  Edge reachability  . . . . . . . . . . . . . . . . . .  6
     1.2.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
   2.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

Dickson                 Expires September 4, 2008               [Page 3]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

1.  Background

   The RADIR problem statement summarizes requirements for new solutions
   to the pressure under which the routing system for IPv4 and IPv6
   finds itself, particularly in the DFZ.

   By ignoring the issue in IPv4 and presenting a solution that fits
   well with the existing routing infrastructure and routing protocols
   for IPv6, this proposal hopes to bypass deficiencies and trade-offs
   of solutions which attempt to solve both IPv6 and IPv4 routing
   growth.

   This deliberate choice may be best understood by comparing the
   resulting design with other solutions within the IPv6 space only, and
   considering that son-of-NAT-PT may be sufficient for IPv4 legacy
   needs.

1.1.  Proposal

   The central element of this proposal is the use of a new addressing
   CONVENTION.

   Rather than creating a new addressing space that is not routed (LISP
   use of EIDs), or any other new addressing mechanism, this involves
   the assignment of special addresses within one PA assignment, which
   corresponds to the other PA assignment for a dual-homed site.

   Consequently, the addresses used in V6DH are always routable, and all
   the rest of the proposal elements are effectly optimizations, on
   performance and reliablity.  Some of the additional proposal elements
   are similarly new conventions on how to make use of existing
   mechanisms (e.g.  DNS), and do not require changes to third party
   equipment for the end site to realize some benefits.

   Of course, the full set of benefits are best seen upon universal
   deployment.  However, the small scope of the changes, and the fact
   that some changes can be done in more than one place topologically
   speaking, means that the incentives are likely to outweigh the
   incremental cost.

1.1.1.  Addressing Convention - Format

   Given two upstream PA assignments PA-A and PA-B, whose format is:

Dickson                 Expires September 4, 2008               [Page 4]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

   +-------- PA-A --------+ subnet-bits-A +--------------|
   + 'a' bits -+ 'b' bits +- 'c' bits ----+--- 64 bits --|
   | RIR block |  PA-net  | subnet bits   | Interface ID |
   +-----------+----------+---------------+--------------|

   where a+b+c = 64; note that 'c' may be 0 (zero) bits long.

                                 Figure 1

   New address range "subnets" within those blocks are constructed as:

   +------+---------------+------+---------------|
   | PA-A | subnet-bits-A | PA-B | subnet-bits-B |
   +------+---------------+------+---------------|

   and/or

   +------+---------------+------+---------------|
   | PA-B | subnet-bits-B | PA-A | subnet-bits-A |
   +------+---------------+------+---------------|

                                 Figure 2

   The general format semantics is Primary + Secondary, as the Primary
   will normally be used for routing if the Primary destination is
   perceived by intermediate sites as reachable.

   Those addresses may or may not be transformed via 1:1 NAT onto end
   host addresses by the site's infrastructure (e.g. edge routers).

1.1.2.  FIB/host lookup changes

   If either the host, or any router in the path (ideally the first
   router, but conceptually any router) determines that the destination
   is unreachable, the IP destination SHOULD be modified by swapping the
   first 64 bits with the last 64 bits.  This SHOULD ONLY be performed
   if the last 64 bits are determined to be a feasible destination
   (either by the host, comparing the last 64 bits to the value
   2000::/3, or by the router, checking its FIB for a valid next hop).

1.1.3.  DNS tweaks for sites/hosts

   DNS servers SHOULD be advertised from an end site with addresses from
   both PA-A and PA-B blocks.  There is no requirement that they be
   addressed via the new convention, and in fact doing so would make
   server addresses no longer a Class 1 object.  As such, DNS servers
   SHOULD NOT be addressed via the proposed convention.

Dickson                 Expires September 4, 2008               [Page 5]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

   End addresses of hosts MAY be served with the new convention.  When
   hosts' addresses are served from DNS via AAAA records using the new
   convention, the current state of reachability SHOULD be updated via
   dynamic DNS.  This reduces load on hosts and routers doing address
   swapping.  DNS TTL values SHOULD be chosen appropriately low for such
   AAAA records.  DNS TTL values for the zone cuts facing the DNS
   servers serving up such AAAA records SHOULD be in line with best
   current practices for operating DNS zones.

1.1.4.  Edge reachability

   There are two methods of determining reachability.  Host behavior is
   nearly trivial to implement.  Routing announcments are a new
   dependency for improving performance and scalability of this
   solution.

1.1.4.1.  Edge reachability - host behaviour

   Hosts SHOULD track connection reachability by use of ICMP
   unreachables.  If a destination is determined to be reachable, based
   on receipt of either host or network unreachable ICMP message, then
   the address modification method described above should be employed.

1.1.4.2.  Edge reachability - routing announcements

   Rather than having a Mapping Table which scale by the number of
   multi-homed sites, this proposal eventually requires (for scalability
   reasons) a table of "unreachable" end-site prefixes.

   The information about how a site is connected (PA-A and PA-B) is
   separated from the status of the links for provider A and provider B.

   This means that the table scales by the number of links that are
   currently out of service, rather than by the number of links.  This
   is anticipated to be, as a general rule, three or four orders of
   magnitude smaller.

   Furthermore, when widespread outages occur, they are expected to be
   localized topologically (e.g. an ISP with a major outage), and the
   unreachabilty information MAY be aggregated by ISPs.

1.1.4.2.1.  New BGP AFI/SAFI - LinkDown

   Within BGP-4, the term "unreachable" normally refers to the
   "withdrawal" of a previously announced prefix.

   However, the unreachability we need information on is the more-
   specific link status, which is normally hidden by the very

Dickson                 Expires September 4, 2008               [Page 6]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

   aggregation that make PA blocks scale well.

   This information is not needed in the DFZ itself, only at the edges.
   As such, it is appropriate to carry it in an opaque manner, as a new
   AFI/SAFI type.

   Details on this to be developed separately within IDR WG.

1.1.4.2.1.1.  Details of LinkDown Behavior

   When a network is performing BGP aggregation, it normally supppresses
   the more-specific prefixes.  The change in behavior proposed, is that
   when such more-specific prefixes "flap", that this unavailablity
   information be passed as a LinkDown BGP SAFI, across the DFZ (without
   impacting DFZ FIBs), to the sending-side edge router(s).  This
   information is used to trigger not only this proposed Dual-Homing
   mechanism, but for any destinations not structured per the
   convention, to discard packets that would not be delivered (because
   the destination is unreachable) at the ingress side.

   This provides immediate benefit to the ISP, to support this new BGP
   AFI/SAFI, and provides a scalable, standardized means of implementing
   "black-holing" of traffic.

1.1.4.2.1.2.  Routing Topology Recommended for LinkDown peering

   Since the main component of the LinkDown is the prefix, and since it
   is expected to be announced by the originator of the BGP aggregate
   covering the prefix, there are good reasons to pass this information
   along the same topology as regular BGP-4+ prefix information.

   o  The more-specific information is likely to be subject to the same
      filtering policies

   o  The trust relationship among peers, and contractual relationships,
      best supports use of the same paths for LinkDown information

   o  The exclusion of the LinkDown information from the DFZ, and its
      absence from the generalized FIBs of some or most intermediate
      ASNs, means that different BGP-4+ peers may be used for carrying
      LinkDown prefixes, with no ill effects.

   o  Further optimizations by implementing multi-hop peering for
      sharing LinkDown information are possible, e.g. where such multi-
      hop peering would not be appropriate for IPv6 prefixes for normal
      NLRI information.

Dickson                 Expires September 4, 2008               [Page 7]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

   o  The fact that no next-hop is needed (and is implicitly Null0), the
      LinkDown "FIB" can be remarkably small.

1.2.  Analysis

   Summary:

   o  Simple - to understand, to implement on hosts, to deploy at sites

   o  Cheap - and can even (marginally) reduce transit costs by dropping
      unreachable destination packets sooner

   o  Skinny - when deployed on routers, no host changes needed; router
      changes close to trivial on FIB side

   o  E2E - fully interoperable and backwards compatible (e.g. when both
      links are up)

   o  E2E - destination-only

   o  Modular - can be deployed in multiple places in a path, first hop
      with implemented preempts later hops

   o  Good Enough - does not preclude other mechanisms for later
      deployment

   o  Minimizes Options - "activated" entirely by end site with no
      intervention needed elsewhere (modulo LinkDown support by ISPs)

   o  Consistent - easy to recognize its use, doesn't affect DFZ at all

   o  Scalable - no DFZ impact, edge "mapping" three to four (or more)
      orders of magnitude smaller than map-encap schemes

   o  Performance - typically in hardware, would require O(1) extra
      lookups (e.g. where N=1, O(N) is by definition 1)

   o  Zero overhead on forwarding path - only 64/64 bit IP header swap,
      no change to packet size - no MTU issues, no fragmentation

   o  No dependency on DNS - but supports use of DNS to further enable
      early adoption with even lower barrier to deployment

   o  Supports limited end-site Traffic Engineering (choice of primary/
      secondary)

   o  Completely compatible with ISP Traffic Engineering - no change to
      addressing within PA blocks

Dickson                 Expires September 4, 2008               [Page 8]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

   o  As secure as BGP - and benefits from any new BGP security
      developments

   o  Facilitates renumbering/rehoming - renumbering is still needed,
      but is well scoped and avoids "flag day" issues

   o  No "Stretch" introduced

   o  No DFZ convergence issues introduced

   o  Edge convergence likely limited to propagation time, due to order-
      of-magnitude of edge link outages compared with number of edge
      links

   o  Dynamic-DNS and double addressing can already be deployed, and
      achieves most of the initial benefits

Dickson                 Expires September 4, 2008               [Page 9]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

2.  Security Considerations

   No additional security considerations beyond those already present in
   BGP are introduced.

Dickson                 Expires September 4, 2008              [Page 10]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

3.  IANA Considerations

   IANA may need to assign new code points for BGP Address Family and/or
   Subsequent Address Family (AFI/SAFI).

Dickson                 Expires September 4, 2008              [Page 11]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

4.  Acknowledgements

   The author wishes to acknowledge the helpful guidance of Joe Abley,
   Tony Li, and Yakhov Rehkter.

Dickson                 Expires September 4, 2008              [Page 12]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

5.  References

5.1.  Normative References

5.2.  Informative References

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

Dickson                 Expires September 4, 2008              [Page 13]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

Author's Address

   Brian Dickson
   Afilias Canada, Inc
   4141 Yonge St,
   Suite 204
   North York, ON  M2P 2A8
   Canada

   Email: [email-masked]
   URI:   www.afilias.info

Dickson                 Expires September 4, 2008              [Page 14]

Internet-Draft           V6DH: IPv6 Dual Homing               March 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.

Intellectual Property

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Dickson                 Expires September 4, 2008              [Page 15]