Re: I-D Action: draft-ietf-rtgwg-dst-src-routing-05.txt

[David Lamparter <[e-mail]>]

Hi rtgwg,


TL;DR:  new section on "testing for connectivity", says checking "can i
route this?" is fine while "what can i route?" probably ain't.


as you can see, I've posted an updated version of:

On Wed, Jul 19, 2017 at 08:51:15AM -0700, [e-mail] wrote:
>         Title           : Destination/Source Routing
>         Authors         : David Lamparter
>                           Anton Smirnov
> 	Filename        : draft-ietf-rtgwg-dst-src-routing-05.txt

Unlike -04, this is not a no-change refresh, though it only extends and
elaborates further.  Changes are as follows:

- moved translation algorithms for policy-based routing implementations
  and no-backtracking into an appendix;  also added a reference to
  Matthieu's and Juliusz's paper on this topic (which is far more
  detailed than I'd want to take this in an IETF draft).

- janitorial stuff; acknowledgements.  If you think it's missing an
  acknowledgement with your name, please ping me.

- added 2 use case sections, from input at this IETF
  - 2.4.  Walled-garden Enterprise services
  - 2.5.  Information Source for Neighbor Management

- added section under Applicability To Specific Situations:
  - 5.4.  Testing for Connectivity Availability

I think only the last change could be contentious;  I'd like to ask if
there is dissent on this.  Here's the added text:

> 5.4.  Testing for Connectivity Availability
>
>    There are situations where systems' behaviour depends on the fact
>    whether "connectivity" is available in a broad sense.  These systems
>    may have previously tested for the existence of a default route in
>    the routing table.
>
>    Since the default route may now be qualified with a source prefix,
>    this test can fail.  If no additional information is available to
>    qualify this test, systems SHOULD test for the existence of any
>    default route instead, e.g. include routes with default destination
>    but non-default source prefix.
>
>    However, if the test can be associated with a source address or
>    source prefix, this data SHOULD be used in looking up a default
>    route.  Depending on the application, it MAY also be useful to -
>    possibly additionally - consider "connectivity" to be available if
>    any route exists where the route's source prefix covers the prefix or
>    address under consideration, allowing arbitrary destination prefixes.
>
>    Note though that this approach to routing SHOULD NOT be used to infer
>    a list of source prefixes in an enumerative manner, or even to guess
>    domain information.  Specifically, if an operator uses more specific
>    source prefixes to refine their routing, the inferred information
>    will provide bogus extraneous output.  This is distinct from the
>    connectivity tests mentioned above in that those actually inquire the
>    routing system, unlike domain information or enumeration, which is
>    higher-layer application information.

This is somewhat motivated by the enterprise PA multihoming &
conditional RA drafts.  To be clear here, I'm very happy with the use
these drafts make of the SADR routing information.  (Hence also the
addition of section 2.5.)  This is explicitly making use of routing
information in a routing context, answering "can I route this?".  What
I'd like to *not* see is using this routing information to guess at
things that better had their own information propagation mechanism.

This notably includes trying to enumerate available source prefixes.
Putting the question as "What can I route?" does not match routing
philosophy - there are reasons to aggregate and deaggregate routes for
routing purposes.  If this breaks the application, that's the point
where I'll be arguing, well, you're using it wrong / should be using
your own channel.

To be even more specific on PA multihoming, I'm saying: someone or
something has to decide what prefix(es) you'll be putting on a link
anyway.  You'd usually have to assign subnets out of a larger prefix.
So, something else is telling the router to put prefix X on a link.
This is the "own channel", and now the router has the information it
needs to ask "can I route this?" and control RAs & PIOs.  Same in
homenets, with HNCP in the mix.


Thanks for any input,


-David