Subject: Proposed change to draft-ietf-6man-multi-homed-host after IESG review

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Sep 2016 08:53:04 +1200

Hi,

This message concerns
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-09 .

There is one remaining issue in the draft before it can get IESG approval.
One of the routing ADs proposes the following change. It does not affect
the normative content of the draft, but it is a technical change (deletion)
so we'd like to hear if there are any objections from the WG. Please comment
within a week (silence means no objection to this change). Some more
background is below the proposed change.

OLD:

2.2.  Expectations of multihomed networks

   The mechanism specified in this document requires some form of
   support from the routing protocols used in multihomed networks.  One
   such way of providing the requisite support in routing protocols is
   described in a routing protocol independent fashion
   [I-D.ietf-rtgwg-dst-src-routing].  Network designs exist that can
   usefully limit themselves to static routing (such as a simple tree
   network), or may internally use no routers at all, such as a single
   LAN with two CE routers, each of which leads to a different upstream
   network.

NEW:

2.2.  Expectations of multihomed networks

   Network designs exist that can usefully limit themselves to static
   routing (such as a simple tree network) or may internally use no
   routers at all, such as a single LAN with two CE routers, each of
   which leads to a different upstream network.  However, the
   mechanism specified in this document may require some form of
   support from the routing protocols used in some multihomed networks.
   The details of such support are out of scope for this document.

You can see Alia's original DISCUSS comment dated 2016-08-02 at
https://datatracker.ietf.org/doc/draft-ietf-6man-multi-homed-host/history/ .
The "SHOULD" mentioned there has already been removed, but her considered
opinion is that the routing solution is simply out of scope for this draft.

Regards
   Brian Carpenter

---

From: Bob Hinden <[email-masked]>
Date: Thu, 15 Sep 2016 16:10:24 -0700

Brian,

While I don’t have a strong objection to the proposed change, I am uncomfortable with what I read is a request to not even mention source-destation routing.  I agree it should not be a requirement in this document, but I don’t see anything wrong with a forward looking pointer.  Perhaps something like this (based on the NEW text):

  Network designs exist that can usefully limit themselves to static
  routing (such as a simple tree network) or may internally use no
  routers at all, such as a single LAN with two CE routers, each of
  which leads to a different upstream network.  However, the
  mechanism specified in this document may require some form of
  support from the routing protocols used in some multihomed networks.
  The details of such support are out of scope for this document.
  One approach that is being investigated to provide the requisite support
  in routing protocols is described in [I-D.ietf-rtgwg-dst-src-routing].

Or similar.

Bob

> On Sep 15, 2016, at 1:53 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> This message concerns
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Fri, 16 Sep 2016 10:13:42 +1000

On 16 September 2016 at 09:10, Bob Hinden <[email-masked]> wrote:
> Brian,
>
> While I don’t have a strong objection to the proposed change, I am uncomfortable with what I read is a request to not even mention source-destation routing.

+1

Static policy based routing (given different names by different
vendors, e.g., Cisco call it Policy Based Routing, Juniper call it
Filter-Based Forwarding), which can include a policy based on source
address, has been around in implementations for at least 15 years. I
think the only thing new in this space is dynamic distribution of a
source address based forwarding "policy" via a routing protocol.

  I agree it should not be a requirement in this document, but I don’t
see anything wrong with a forward looking pointer.  Perhaps something
>   in routing protocols is described in [I-D.ietf-rtgwg-dst-src-routing].

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Sep 2016 21:49:56 -0300

> opinion is that the routing solution is simply out of scope for this draft.

Isn't the reference to [I-D.ietf-rtgwg-dst-src-routing] simply
informational?

If my mental diff (not having slept for quite too many hours) doesn't
fail, the only different between OLD and NEW is s/requires&may require/
and the deletion of the (alas informative) reference.

The s/requires/may require" seems to be incorrect (unless I'm missing
something). The informational diff shouldn't be a show-stopper (whether
included or removed... although I'd keep it, given the option).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Sep 2016 09:24:48 +0000

Hi,

> On 16 Sep 2016, at 01:49, Fernando Gont <[email-masked]> wrote:
> 

The question is whether a specific draft informational document needs to be cited explicitly as an example. I recall when we finalised RFC7368 for the Homenet architecture, we were guided to remove similar such references there, but to retain their spirit in the text.

I note that draft-ietf-6man-multi-homed-host doesn’t cite RFC7368, which mentions the utility of src/dst routing in sections 3.1.2, 3.2.4 (twice) and 3.5.1, with referring to any specific related draft at the time of that RFC being published. I think what was said then, at least two years ago, still holds.
 
Tim

---

From: Philip Homburg <[email-masked]>
Date: Fri, 16 Sep 2016 13:58:30 +0200

>While I don't have a strong objection to the proposed change, I 
>am uncomfortable with what I read is a request to not even mention 
>source-destation routing.  I agree it should not be a requirement in 
>this document, but I don't see anything wrong with a forward 
>looking pointer.  Perhaps something like this (based on the NEW text):

My preference is to keep host-router interactions separate and decoupled from
routing protocols.

So I think it improves the document to avoid mentioning how routers coordinate
among each other. As such not mentioning [I-D.ietf-rtgwg-dst-src-routing]
is an improvement.

There is one thing that confuses me in this document. I think the protocol
description in this draft is fine, it is some of the surrounding wording
the I find confusing.

In my experience, if routers implement some form of dst-src routing then
existing redirects are more than enough. Linux, OSX, FreeBSD work fine in
this context.

So where hosts need to change is in the situation where routers don't use any
kind of routing protocol, are unware of each other and therefor not sending
redirects. This is the main area where this draft introduces a protocol
change.

But in this case, mentioning dst-src routing is irrelevant, because the
assumption is that the routers are not talking to each other anyhow.

So I find the new text for Section 2.2 confusing. Selecting a default router
based on advertised PIOs should make routing work even if routers don't 
speak any kind of routing protocol.

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Sep 2016 15:31:50 +0200

The key point there is the support for source/destination routing in the forwarding plane; how the FIB obtains the route is secondary. It might be worthwhile making that point...

Sent from my iPhone

> On Sep 15, 2016, at 10:53 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> This message concerns

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Sep 2016 03:21:10 +0000

Hi Tim,

> The question is whether a specific draft informational document needs to be cited explicitly as an example. I recall when we finalised RFC7368 for the Homenet architecture, we were guided to remove…

Yes. Citing a specific draft seems to be the main open issue. Thanks for the 
background info about RFC7368. It is very useful.

> I note that draft-ietf-6man-multi-homed-host doesn’t cite RFC7368, which mentions the utility of src/dst routing in sections 3.1.2, 3.2.4 (twice) and 3.5.1, with referring to any specific related d…

Sounds good to me.

Thanks
Suresh