Using Conditional Router Advertisements for Enterprise Multihoming
RFC 8475

Note: This ballot was opened for revision 05 and is now closed.

(Spencer Dawkins) Yes

Comment (2018-07-29 for -05)
No email
send info
I echo Mirja's thanks for a well-written document (and her curiosity about the near-null Security Considerations - there's at least one recommendation in this document, so it seems possible that some security consideration is worth mentioning). But I think I understand this topic, and now I think I understand it much better. Thanks for that. 

I do have some minor comments, but they are non-blocking, so do the right thing. 

This text toward the bottom of the abstract

   this document
   adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-
   multihoming" draft to provide a solution for a limited number of
   common use cases.

is pretty easy to miss. If the reader misses it, the first sentence is kind of misleading - it just says

   This document discusses the most common scenarios of connecting an
   enterprise network to multiple ISPs using an address space assigned
   by an ISP.

Perhaps it's worth pointing that out in the first sentence, rather than towards the end of the abstract?

I've been on the IESG far too long, but I have tried repeatedly to read

   While some work is being done in the Source Address Dependent Routing
   (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]),

without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. If 

   While some work is being done on Source Address Dependent Routing
   (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]),

that would stop startling at least one reader ...

In 3.2.5.  Topologies with Dedicated Border Routers

   For simplicity, all topologies above show the ISP uplinks terminated
   on the first-hop routers.  Obviously, the proposed approach can be
   used in more complex topologies when dedicated devices are used for
   terminating ISP uplinks.  In that case VRRP mastership or interface
   status can not be used as a trigger for conditional RAs and route
   presence as described above should be used instead.

"as described above" might be easier to navigate if it was "as described above in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross reference correctly, and if I'm not, an explicit section reference would be even more appreciated.

I'm not sure that

  It should be noted that the proposed approach is not a silver bullet
   for all possible multihoming scenarios. 

"silver bullet" is clear for readers from cultural contexts that don't include werewolves or vampires ... but do the right thing, of course.

It's a nit, but "such as latencyetc".

It's a nit, but "correspodning".

Suresh Krishnan Yes

Comment (2018-08-02 for -06)
No email
send info
* Section 3.1.1.

I think a reference to RFC3704 (specifically written for describing ingress filtering for multihomed networks) might be a good addition here to RFC2827

* Sections 3.2.1., 3.2.2. etc.

=> I think it is important to specify (at least the bounds of) the valid lifetimes here as well. e.g. when the preferred lifetime is getting set to zero it is important to specify that the valid lifetime is set to a non zero value so that the host will form an address at all (even though it will not be used when there are preferred addresses). This is important to reduce the potential packet losses when the preferred uplink goes down.

* Section 3.2.2.

I think there is some text missing here about VRRP priorities here. There seems to be an assumption in the draft that the uplink A failure will lead to R1 becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this is not obvious at all. There needs to be a priority change with interface tracking if this has to happen and the backup has to take over as the master.

Warren Kumari Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Comment (2018-07-31 for -05)
No email
send info
Agree with Spencer - I needed to reread the abstract and intro several times to understand the relationship
of this document with rtgwg's. As Spencer noted, I think the first sentence throws the reader off. Suggest
deleting it so as to be more direct.

Same as Spencer - "area" had me wondering if there was/had been such an IETF area, suggest:
in the Source Address Dependent Routing (SADR) area/s/on Source Address Dependent Routing (SADR)

(Ben Campbell) No Objection

Comment (2018-08-01 for -06)
No email
send info
I share the confusion about the relationship to ietf-rtgwg-enterprise-pa-multihoming in the abstract.

Alissa Cooper No Objection

Comment (2018-08-01 for -06)
No email
send info
I, too, was confused about the references to ietf-rtgwg-enterprise-pa-multihoming in the abstract, so would support the fixes previously suggested. Furthermore, the places where that document is named should be replaced with direct citations to it, which can then be updated to point to the corresponding RFC if it gets published in time or if it gets converted to a normative reference. Using 'the "ietf-rtgwg-enterprise-pa-multihoming" draft' is not going to age well since it won't always be a draft.

In Section 5.1, I wonder if it's worth pointing out that by supporting enterprise multihoming the techniques described in this document can provide a privacy benefit to users, since remote peers view their traffic as having multiple source addresses?

Benjamin Kaduk No Objection

Comment (2018-08-01 for -06)
No email
send info
I'll echo Mirja and Spencer's question about the "empty" security considerations.  (I actually don't much
care for the "This memo introduces no new security considerations" formulation in general, unless it's
literally the only content of the section -- it's either followed by new security considerations, in which
it's just wrong, or followed by calling out specific portions of the referenced security considerations that
are particularly relevant.  In the latter case, it seems useful to provide more of a lead-in like "The general
security considerations of [X] and[Y] apply, and in particular [...]".)

Unfortunately, I don't seem to be in a good position to comment on actual additions to the security considerations
section, since I don't have a clear picture of what the proposal in this document actually changes when compared
to current/normal practices.  This is presumably just a matter of my lacking the appropriate background knowledge
for the routing bits, but in a scenario like Figure 3, with distinct edge and first-hop routers, what kind of RAs would the
first-hop routers normally be sending?  Would they be announcing the routes in question here just without the
PIO markings, or not advertising anything at all, or something else?

Other than that, thanks for the well-written document!

Mirja Kühlewind No Objection

Comment (2018-07-25 for -05)
No email
send info
Thanks for the well-written document. Please find some comments below:

1) The shepherd write-up says "The responsible Area Director is Ron Bonica." and questions 7 and 8 say "TBD" and the RFC8174 biolerplate is missing...

2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a normative reference (and that the abstract should be updated with the respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is published). Any even if it is not a normative reference, should those docs be published together in order to refer to the RFC in the abstract (instead of an draft)?

3) Would it makes sense to also discuss what to do when one ISP is down but packets from that address space are received at the border router? Should those packet be forwarded to that ISP anyway or dropped? Or should they be forwarded to the other ISP with or without address translation?

4) It doesn’t seem right to me that the security consideration section is empty.

5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2.

(Terry Manderson) No Objection

Adam Roach No Objection

Comment (2018-08-01 for -05)
No email
send info
Thanks to everyone who worked on this document. I have one substantive comment
and a handful of editorial suggestions.

---------------------------------------------------------------------------

§3.3.1:

>  It should be noted that in IPv4 multihoming with NAT, when the egress
>  interface is chosen without taking packet source address into account
>  (as internal hosts usually have addresses from [RFC1918] space),
>  sessions can not be preserved after an uplink recovery.

This isn't necessarily true. For example, if the NAT is tracking which
ISP-facing interface is associated with a given established session, the
sessions will survive restoration of an uplink.  I have exactly such an IPv4
multi-homing configuration working on my home network (with RFC 1918 addresses
assigned to all local devices), and will happily share details of my
configuration with interested parties.

I propose striking this paragraph from the document.

---------------------------------------------------------------------------

§1:

>  general multihoming scenario for enterprise networks and proposes
>  solution which relies heavily on the rule 5.5 of the default address

Nit: "...proposes a solution..."

---------------------------------------------------------------------------

§3.2.6:

>  (as there is no preferred addresses available) and the source address

Nit: "...as there are no..."

---------------------------------------------------------------------------

§3.3:

>  into account any other uplinks properties (such as latencyetc), so

Nit: "...latency, etc.), so..."

---------------------------------------------------------------------------

§3.3.1:

>  interrupted as there is no egress path for those packets and there is
>  not return path from the Internet to the correspodning prefix.  In

Nit: "...there is no return path..."

Nit: "...corresponding..."

---------------------------------------------------------------------------