Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)
draft-templin-ranger-09

Here's a suggested final change to the Ranger draft. My goal is to ensure that the draft has sufficient information about the impacts solutions like this have on the rest of the Internet. You've already put in quite a bit of material about that, thank you for that. I wanted to add a little bit more. I don't know if you can make this change before the drafts deadline, but if you do, the process should move forward immediately...

OLD:
  (It must be noted here that the selection of mapping alternatives may
  have significant implications for applications, server selection,
  route determination, security, etc.  In particular, applications that
  expect all packets (including initial ones) to experience similar
  delays may be adversely affected by a scheme that imposes non-
  negligible delays when initial packets are queued while a look-aside
  mapping table is consulted.  Still other applications may experience
  significant startup delays when its initial packets are dropped
  during a mapping lookup event.  These factors would seem to favor a
  scheme that is able to forward initial packets along a sub-optimal
  path while a mapping lookup is performed in parallel to discover a
  more direct route (e.g., such as when a default mapper is used).
  Also to be considered are attacks against the mapping mechanism which
  may result in denial of service of the mapping cache.)

  After discovering the mapping, the ITE encapsulates inner IP packets
  in an outer IP header for transmission across the commons to the RLOC
  address of an ETE.  The ETE in turn decapsulates the packets and
  forwards them over edge networks to the EID addresses of final
  destinations.  The Routing Information Base (RIB) within the commons
  therefore only needs to maintain state regarding RLOCs and not EIDs,
  while the synchronized EID-to-RLOC mapping state is maintained by a
  smaller number of nodes and is not subject to oscillations due to
  link state changes within the commons.  Finally, EIDs are routable
  only within a limited scope within edge networks (which may be as
  small as node-local scope in the limiting case).

  RANGER supports scalable addressing by selecting a suitably large EID
  addressing range that is distinct and kept separate from any
  enterprise-interior RLOC addressing ranges.  It should therefore come
  as no surprise that taking EID space from the IPv6 addressing
  architecture should lead to a viable scalable addressing alternative,
  while taking EID space from the (already exhausted) IPv4 addressing
  architecture may not.
NEW:
  After discovering the mapping, the ITE encapsulates inner IP packets
  in an outer IP header for transmission across the commons to the RLOC
  address of an ETE.  The ETE in turn decapsulates the packets and
  forwards them over edge networks to the EID addresses of final
  destinations.  The Routing Information Base (RIB) within the commons
  therefore only needs to maintain state regarding RLOCs and not EIDs,
  while the synchronized EID-to-RLOC mapping state is maintained by a
  smaller number of nodes and is not subject to oscillations due to
  link state changes within the commons.  Finally, EIDs are routable
  only within a limited scope within edge networks (which may be as
  small as node-local scope in the limiting case).

  RANGER supports scalable addressing by selecting a suitably large EID
  addressing range that is distinct and kept separate from any
  enterprise-interior RLOC addressing ranges.  It should therefore come
  as no surprise that taking EID space from the IPv6 addressing
  architecture should lead to a viable scalable addressing alternative,
  while taking EID space from the (already exhausted) IPv4 addressing
  architecture may not.

3.x Impacts to Applications and Others Parts of the Internet

  It must be noted here that the selection of mapping alternatives may
  have significant implications for applications, server selection,
  route determination, security, etc.  In particular, applications that
  expect all packets (including initial ones) to experience similar
  delays may be adversely affected by a scheme that imposes non-
  negligible delays when initial packets are queued while a look-aside
  mapping table is consulted.  Still other applications may experience
  significant startup delays when its initial packets are dropped
  during a mapping lookup event.  These factors would seem to favor a
  scheme that is able to forward initial packets along a sub-optimal
  path while a mapping lookup is performed in parallel to discover a
  more direct route (e.g., such as when a default mapper is used).

  Generally speaking, proactive mapping maintenance mechanisms may have
  scaling issues with the amount of updates they generate, while reactive
  mechanisms may involve effects to the delay of initial packets before the cached
  state is updated. Even the parallel scheme discussed above has a delay
  effect. Also to be considered are attacks against the mapping mechanism
  which may result in denial of service of the mapping cache; all caching
  based mechanisms are vulnerable to this.

  Encapsulation of packets in automatically created tunnels involves
  a number of issues as well. There is an obvious effect to the effective
  end-to-end MTU, even if SEAL mitigates other concerns related to MTUs
  (such as accidental loss of connectivity due to undetected MTU problems).
  More importantly, it is difficult to reduce the size of the global routing
  table without at the same time impacting the ability of legacy Internet
  networks to connect to those employing RANGER. As long as other
  nodes in the Internet need to connect to networks implementing RANGER,
  EID routes need to appear both in the mapping system and the global
  BGP routing tables.

Jari

[Ballot discuss]
Holding a discuss for myself in order to ensure that the text changes
are sufficient to describe downsides of this approach. The new version
(08) went a long way towards resolving these concerns, but some more
tweaking is still required.

I have reviewed this document today. The purpose of the review is to check that the document does not allocate IANA values reserved for IETF protocols or otherwise collide with IETF work. The review is not a technical review; the authors and the RFC Editor are fully responsible for that in these independent submissions.

I have basically no fundamental objection to publishing this work. In fact, I'd like to see it published. There were a couple of things in my review that I would like to change before I recommend publication, and I would like to ask Fred to revise his document and bring it back to us. These issues were:

- I'd like to see a more accurate description of how this relates to current or past IETF work, such as LISP, MP-TCP, and so on. The current text on this is partially outdated, in some cases misses significant other work, and in some other cases makes broad claims that may not be correct.

- I'd like to see a more comprehensive list of impacts that adopting this type of an architecture leads to. In particular, the document should talk about application impacts, connectivity between the new and old Internet, and incentives for deploying some of the infrastructure nodes.

If these are changed then I think we can go ahead with the standard IESG note (or if 3932bis is done by then, no IESG note). The entire IESG will review this in two weeks on October 8th. The goal of the review is to determine whether they agree with my recommendation.

There are some additional review comments below. Most of this is just personal comments, not a part of my IESG review.

Jari

>    VET
>      Virtual Enterprise Traversal (VET) [I-D.templin-autoconf-dhcp];
>      functional specifications and operational practices that provide a
>      functional superset of 6over4 and ISATAP.  In addition to both
>      unicast and multicast tunneling, VET also supports address/prefix
>      autoconfiguration as well as additional encapsulations such as
>      IPSec, SEAL, LISP/UDP, Teredo/UDP, etc.

Please be careful about forward references to ongoing work; LISP is still work in progress, so if you make an RFC that normatively references that may require a long reference wait...

> as seen through
>    evidence that core Routing Information Base (RIB) scaling will be
> unsustainable over the long term

Personally, I would have used a softer claim here, e.g., fear that core Routing Information Base (RIB) scaling is not sustainable over the long term.

> RANGER supports scalable routing through an approach known as map-
>    and-encaps.
Reference to the RFC where the original idea appeared would be nice here.

>    RANGER allows that an ITR either consult the mapping system itself
>    (while delaying or dropping initial IP packets) or forward initial
>    packets to an Enterprise Border Gateway (EBG) acting as a "default
>    mapper".
Just like with Lisp, I hope that you make clear somewhere what the potential implications may be. For instance, some applications may suffer from packet drops, server selection algorithms may pick the wrong server, spraying the ITRs with randomly destined packet will lead to DoS, etc. Truth in advertising.

More generally, the draft would benefit from a better description of what the impacts of the design are for the rest of the Internet, including downsides. There are obvious benefits, which are quite well described. But it seems that there are a number of potential downsides, for instance:

- impacts of losing/delaying first packets (discussed above)
- potential loss of the ability to talk between the new and the old parts of the Internet
- incentive issues related to deploying infrastructure nodes or translators between the new and old parts
- additional MTU problems due to the tunneling that is introduced (even if you try to fix some of them with seal)
- ...

> To determine the best next-hop, 'X2' can perform an on-demand mapping
>    lookup by consulting the enterprise mapping service (e.g., an
>    enterprise name service) while dropping or delaying initial packets.
>    This can be done, e.g., by consulting the DNS for a FQDN that matches
>    the EID prefix of the inner IP packet's destination address.

This is vague and I could not determine what exactly the system will do.

> After tunnels 'vet1' through 'vet3' are
> established and EBG's discovered, the EBRs connected to a 'vet*'
> interface can run a dynamic routing protocol such as OSPVFv3
> [RFC5340] and exchange topology information with one another over the
> 'vet*' interface.  It is important to note that EBR neighbor
> relationships can be formed on-demand and allowed to expire after
> idle periods such that a full mesh of neighbors need not be
> maintained.  This allows an overlay network that spans 'E1' to
> dynamically adapt to changing conditions within the enterprise.'

This is also vague. Can you establish tunnels dynamically, and if so, how are the endpoints discovered?


> Instead, 'R2' could act as a "Carrier-Grade NAT
>      (CGN)", and 'K's IPv4 router ('V') could use the "dual-stack-lite"
>      approach to convey 'K's packets to the CGN using IPv4-in-IPv6-in-
>      IPv4 tunneling.

Is there a reference to Dual Stack Lite, and will that reference be normative or informative from the point of view of your document?

>    The advantages of using SEAL in conjunction with the RANGER
>    enterprise-within-enterprise framework are tangible, and compare
>    favorably with the alternative of deploying an all-IPv6
>    infrastructure even for clean-slate deployments.  This is especially
>    true within enterprises that provide a commons for joining
>    organizational/political/functional entities with a spirit of mutual
>    cooperation but with competing interests or objectives.
This statement comes out of the blue and it not justified in any manner. And I'm surprised that you think this compares favorably with a new IPv6-only infrastructure in situations where that's feasible.

>    As with mobilitiy management, the contintingency of solutions is not

Typo

>    The Locator-Identifier Split Protocol (LISP) [I-D.farinacci-lisp]

Presumably this should point to draft-ietf-lisp, not the personal draft.

> A related mapping
>    function solution proposal is found in [I-D.jen-apt].

An alternative...?

>    LISP, and a number of related proposals being discussed in the
>    Routing Research Group, share common properties with the solution
>    proposed here.  They may therefore be architecturally consistent with
>    the RANGER architecture.

There are a couple of problems here. First, you only talk about RRG and not the IETF work (LISP WG). Second, there are different types of solutions that came out of the RRG, and you only talk about some of them. Do you want to contrast your solution to host based mechanisms as well, e.g., Multipath TCP?

Third, I don't think the statement "share common properties ... architecturally consistent with" are necessarily true. Perhaps at the very highest level, but there are very significant details, and your comparison above glosses over all of them.

But making this RFC a comparison effort between the many proposals would be fruitless. I would rather first make sure that you have an adequate set of pointers to what other work is happening in the IETF and IRTF. Then I would shortly contrast the type of the solution in your draft versus the other ones (e.g., both are based on map-n-encap but use very different protocols for the signaling and encapsulation), but refrain from going into too much detail and refrain from claiming anything potentially controversial/non-obvious.


>    To determine the best next-hop, 'X2' can perform an on-demand mapping
>    lookup by consulting the enterprise mapping service (e.g., an
>    enterprise name service) while dropping or delaying initial packets.
>    This can be done, e.g., by consulting the DNS for a FQDN that matches
>    the EID prefix of the inner IP packet's destination address.
>    Alternatively, 'X2' can send the packet to a default router (e.g.,
>    EBG 'R2') which in turn can forward the packet to 'X7' and return an
>    ICMPv6 redirect message to 'X2'.  When 'X2' receives the redirect, it
>    can send a SEND-signed RA message to 'X7' then forward subsequent
>    packets directly via the route-optimized path to 'X7'.

> The
>    SEND mechanism is also useful for route optimization between lower-
>    tier enterprises across a parent enterprise commons.

SEND as defined in RFC 3971 does not do route optimization. It would be more correct to say that RANGER's extensions on top of SEND make route optimization possible. It has never been mandated that routers listen to RAs and adjust their routing tables based on them.

And your text earlier does not actually specify these extensions. It would be useful to be clearer about what exactly RANGER expects the nodes to do beyond existing specifications.

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission: draft-templin-ranger-07.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Four week timeout expires on 12 October 2009.


Routing and Addressing in Next-Generation EnteRprises (RANGER)

RANGER is an architectural framework for scalable routing and
addressing in next generation enterprise networks. The term
"enterprise network" within this context extends to a wide variety
of use cases and deployment scenarios, where an "enterprise" can be
as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network,
as complex as a multi-organizational corporation, or as large as
the global Internet itself. Such networks will require an
architected solution for the coordination of routing and addressing
plans with accommodations for scalability, provider-independence,
mobility, multi-homing and security. These considerations are
particularly true for existing deployments, but the same principles
apply even for clean-slate approaches. The RANGER architecture
addresses these requirements, and provides a comprehensive
framework for IPv6/IPv4 coexistence.