Re: New Version Notification for draft-baker-rtgwg-src-dst-routing-use-cases-00.txt

["Fred Baker (fred)" <[e-mail]>]

Let me add some information regarding source/destination routing that may be useful for context.

This note, and its associated discussion, is an outcome from homenet. Homenet is chartered to describe the tools and technologies needed in an IPv6 home network. One of the issues has been egress routing in a multi-homed network. Since homenet is not chartered to actually develop routing protocols, and is working with ospf among others, it seems like the discussion of source/destination routing should move to rtgwg. You saw my note to rtgwg earlier in the week; the folks copied on it and I, along with the homenet chairs and Acee Lindem from OSPF, came up with this document to present a use case discussion.

As to the details of the discussion, a number of people have been working on the concept of source/destination routing. The first requirement is in egress routing, which Petri Helenius and I played with in RFC 3704. That particular project was a bit confusing for me; I was working on something else (which became RFC 4192 in the fullness of time), and he (as working group chair) kept sending me private mail about BCP 38, PA prefixes, uRPF, and getting packets to an ISP that was not going to drop them. I finally combined his email train into one note and sent it to him to post. 

Here's the deal. Suppose you have a network with two or more upstreams, and you are using a provider-allocated prefix from each to number your network:
                                         ,-------.
                                      ,-'         `-.
      ,---.            ,-----.      ,'               `.
     /     \    +-+  ,'       `.   /                   \
    /       +---+R+-+   ISP 1   --+---                  \
   /         \  +-+  `.       ,' ;                       :
  ; Customer  :        `-----'   |       The Internet    |
  | Network   |        ,-----.   :                       ;
  :           ; +-+  ,'       `.  \                     /
   \         +--+R+-+   ISP 2   ---+--                 /
    \       /   +-+  `.       ,'    `.               ,'
     \     /           `-----'        '-.         ,-'
      `---'                              `-------'

If a host has multiple addresses on every interface, one from each upstream, and no other information to bias its choice (remember that hosts know little or nothing about routing apart from being able to calculate that one of their addresses may be more similar to one of the target's address than another), the address it chooses is a coin toss. In a standard network, however, the network probably has a default route to follow, and will deliver a packet to one of those upstreams. If the upstream has BCP 38 filtering enabled (and let's hope it does), that gives the host a 1/N probability of selecting an address that will in fact get the packet past the filter. Wouldn't it be nice if somehow it could either select the right address in the first place, or could be assured that the network would get the packet it sent, with the address it chose, to the upstream that would not discard it? And wouldn't it be nice if we could automate that in routing, rather than making the administrator manually configure every router to do something like PBR or MTR?

There are a number of proposals in the IETF right now, which I'll list. The question was raised at IETF 87 whether we could have a common document to discuss use cases, to ensure that the solutions we develop actually solve the problem in question. This document describes the use cases we came up with, and the requirements we drew out of them.

http://tools.ietf.org/html/draft-chroboczek-babel-extension-mechanism
 "Extension Mechanism for the Babel Routing Protocol", Juliusz
 Chroboczek, 2013-06-30

http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication
 "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 2013-04-18

http://tools.ietf.org/html/draft-troan-homenet-sadr
 "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole
 Troan, Lorenzo Colitti, 2013-02-18

http://tools.ietf.org/html/draft-xu-homenet-traffic-class
 "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang,
 Jianping Wu, Fred Baker, 2013-07-15

http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing
 "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu
 Yang, Jianping Wu, Dan Wang, 2013-02-18

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
 "Using IS-IS with Role-Based Access Control", Fred Baker, 2013-02-17

http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
 "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 2013-02-17

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
 "Using OSPFv3 with Role-Based Access Control", Fred Baker, 2013-05-02

http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
 "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-05-02

http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases
 "Requirements and Use Cases for Source/Destination Routing", Fred Baker,
 2013-08-13


On Aug 13, 2013, at 10:31 AM, [e-mail] wrote:

> 
> A new version of I-D, draft-baker-rtgwg-src-dst-routing-use-cases-00.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Filename:	 draft-baker-rtgwg-src-dst-routing-use-cases
> Revision:	 00
> Title:		 Requirements and Use Cases for Source/Destination Routing
> Creation date:	 2013-08-13
> Group:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-baker-rtgwg-src-dst-routing-use-cases-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cases
> Htmlized:        http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases-00
> 
> 
> Abstract:
>   This note attempts to capture important use cases for source/
>   destination routing.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

If at first the idea is not absurd, then there is no hope for it.  
Albert Einstein