Using Conditional Router Advertisements for Enterprise Multihoming
draft-ietf-v6ops-conditional-ras-08

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..."

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

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?

I share the confusion about the relationship to ietf-rtgwg-enterprise-pa-multihoming in the abstract.

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!

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)

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.