[v6ops] AD Review of: draft-ietf-v6ops-conditional-ras

[Warren Kumari <[e-mail]>]

Hello,

Thank you to the editors and WG for your efforts on
this document, it's a well written, useful  and easy to understand
draft.  I do have a few comments that I’d like addressed
before I start IETF LC.

The majority of these are nits (and 2 substantive comments), but
addressing these now will avoid
issues later in the process.

Please let me know LOUDLY AND EXPLICITLY once you've had a chance to
address them and I'll kick off IETF LC.

W


  Section: Abstract

This document discusses most common scenarios of connecting an

O: discusses most common
P: discusses the most common

   enterprise network to multiple ISPs using an address space assigned
   by an ISP.  The problem of enterprise multihoming without address
   translation of any form has not been solved yet as it requires both
   the network to select the correct egress ISP based on the packet
   source address and hosts to select the correct source address based
   on the desired egress ISP for that traffic.
...
   general problem and on covering various complex use cases, this
   document describes how the solution proposed in
   [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited

O: adopted for limited
P: adopted for a limited

   number of common use cases.  In particular, the focus is on scenarios
   where an enterprise network has two Internet uplinks used either in
   primary/backup mode or simultaneously and hosts in that network might
   not yet properly support multihoming as described in [RFC8028].


Section: 1.  Introduction

   Using Provider Independent (PI) address space is not
   always an option as it requires running BGP between the enterprise
   network and the ISPs, not mentioning administrative overhead of
   obtaining and managing PI address space.  As IPv6 host can, by

O:

 Using Provider Independent (PI) address space is not
   always an option as it requires running BGP between the enterprise
   network and the ISPs, not mentioning administrative overhead of
   obtaining and managing PI address space.  As IPv6 host can, by

P:

 Using Provider Independent (PI) address space is not
   always an option, since it requires running BGP between the enterprise
   network and the ISPs. Administrative overhead of
   obtaining and managing PI address space can also be a concern.  As
IPv6 hosts can, by

R: Readability

design, have multiple addresses of the global scope, multihoming using
provider address looks even easier for IPv6: each ISP assigns an IPv6 block
(usually /48) and hosts in the enterprise network have addresses assigned
from each ISP block. However using IPv6 PA blocks in multihoming scenario
introduces some challenges, including but not limited to: ...

   The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses
   these and other related challenges in details in relation to the

O: in details

P: in detail

   general multihoming scenario for enterprise networks.  Unfortunately
   the proposed solution heavily relies on the rule 5.5 of the default

O: heavily relies
P: relies heavily

O: on the rule 5.5 [...
P: maybe reference the rule more specifically, provide more detail,
etc. This is an introductory section, it it unlikely that people will
remember what rule 5.5 says.

   address selection algorithm ([RFC6724]) which has not been widely
   implemented at the moment this document was written.  Therefore

O: at the moment
P: when

   network administrators in enterprise networks can't yet assume that
   all devices in their network support the rule 5.5, especially in the
   quite common BYOD ("Bring Your Own Device") scenario.  However, while
   it does not seem feasible to solve all the possible multihoming
   scenarios without reliying on rule 5.5, it is possible to provide

O: reliying
P: relying

   IPv6 multihoming using provider-assigned (PA) address space for the
   most common use cases.  This document discusses how the general
   solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can
   be applied to scenarios when:

   o  An enterprise network has two or more ISP uplinks;

   o  Those uplinks are used for Internet access in active/backup or
      load sharing mode w/o any soficticated traffic engineering

O: soficticated
P: sophisticated

      requirements;


Section:  2.2.  Two ISP Uplinks, Used for Load Balancing

   This scenario has the following key characteristics:

   o  The enterprise network is using uplinks to two (or more) ISPs for
      Internet access;

   o  Each ISP assigns an IPv6 PA address space;

   o  All the uplinks may be used simultaneously, with the traffic flows
      being randomly (not nessesary equally) distributed between them;

O: nessesary
P: necessarily


   o  Hosts in the enterprise network are not expected to support the
      Rule 5.5 of the default address selection algorithm ([RFC6724]).


...

Section:  3.1.1.  Uplink Selection

   While some work is being done in the Source Address Dependent Routing
   (SADR) area, the simplest way to implement the desired functionality
   currently is to apply a policy which selects a next-hop or an egress
   interface based on the packet source address.  Most of the SMB/

O: Most of the
P: Most

   Enterprise grade routers have such functionality available currently.

3.1.2.  Source Address Selection and Conditional RAs

   Sending a
   router advertisement to change the preferred lifetime for a given
   prefix provides the following functionality:


   o  deprecating addresses (by sending an RA with the
      preferred_lifetime set to 0 in the corresponding POI) to indicate

O: POI

R: POI? or PIO? -- also, need a POI reference.

      to hosts that that addresses from that prefix should not be used;

...

   The trigger is not only forcing the router to send an unsolicited RA
   to propagate the topology changes to all hosts.  Obviously the RA
   fields values (like PIO Preferred Lifetime or DNS Server Lifetime)
   changed by the particular trigger MUST stay the same until another
   event happens causing the value to be updated.  E.g. if the ISP_A
   uplink failure causes the prefix to be deprecated all solicited and

O: to be deprecated all
P: to be deprecated, all

   unsolicited RAs sent by the router MUST have the Preferred Lifetime
   for that POI set to 0 until the uplink comes back up.

   It should be noted that the proposed solution is quite similar to the
   existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the
   documented behaviour of homenet devices.  It is using the same


O: behaviour
P: behavior


   mechanism of deprecating a prefix when the corresponding uplink is
   not operational, applying it to enterprise network scenario.


Section:  3.2.1.  Single Router, Primary/Backup Uplinks




   To ensure that packets with source addresses from ISP_A and ISP_B are
   only routed to ISP_A and ISP_B uplinks respectively, the network
   administrator needs to configure a policy on R1:


if {
     packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48
     packet_source_address is in 2001:db8:1::/48
} then {
       default next-hop is ISP_A_uplink
}
if {
     packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/48
     packet_source_address is in 2001:db8:2::/48
}
then {
       default next-hop is ISP_B_uplink
}

C: Pseudocode is always tricky; it is hard to get the level of
abstraction right. I think that this needs a bit more work / words /
parenthesis...

Is this:
A: packet_destination_address is not in 2001:db8:1::/48 AND IS NOT IN
2001:db8:2::/48

or

B: packet_destination_address is not in 2001:db8:1::/48 OR IS IN
2001:db8:2::/48 ? (The first is implied, but not really explicit)


Also, is the "packet_source_address is in 2001:db8:1::/48" AND or OR
with the first condition?


I think:
(packet_destination_address is not in (2001:db8:1::/48 or
2001:db8:2::/48)) and (packet_source_address is in 2001:db8:1::/48)
is clearer, but not sure (same for other pseudocode too) ....

...

3.2.5.  Topologies with Dedicated Border Routers

   For simplicity reasons all topologies below show the ISP uplinks

O: For simplicity reasons
P: For simplicity,

   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 inteface status can not be used as a trigger for

O: inteface
P: interface

   conditional RAs and route presence as described above should be used
   instead.

 ...

   R1 and R2 policy:

   prefix 2001:db8:1:1::/64 {
     if ISP_A_uplink_route is present then preferred_lifetime = 604800
     else preferred_lifetime = 0
     }
   prefix 2001:db8:2:1::/64 {
     if ISP_A_uplink_route is present then preferred_lifetime = 0
       else preferred_lifetime = 604800
    }

   For load-balancing case the policy would look slightly different:

O: For load-balancing case
P: For the load balancing case ?

each prefix has non-zero preferred_lifetime only if the correspoding ISP
uplink route is present: Section: 3.2.6. Intra-Site Communication during
Simultaneous Uplinks Outage Prefix deprecation as a result of an uplink
status change might lead to a situation when all global prefixes are
deprecated (all ISP uplinks are not operational for some reason). Even when
there is no Internet connectivity it might be still desirable to have
intra-site IPv6 connectivity (especially when the network in question is an
IPv6-only one). However while an address is in a deprecated state, its use
is discouraged, but not strictly forbidden ([RFC4862]). In such scenario
all IPv6 source addresses in the candidate set

O: such scenario
P: such a scenario,

([RFC6724]) are deprecated which means that they still can be used

O: deprecated which means
P: deprecated, which means

(as there is no preferred addresses available) and the source address
selection algorith can pick up one of them, allowing the intra-site
communication. However some OSes might just fall back to IPv4 if the
network interface has no preferred IPv6 global addresses. Therefore if
intra-site connectivity is vital during simultanious outages of multiple
uplinks, administrators might consider using ULAs or provisioning
additional backup uplinks to protect the network from double-failure cases.
3.2.7. Uplink Damping If an actively used uplink (primary one or one used
in load balaning scenario) starts flapping, it might lead to undesirable
situation of

O: to undesirable situation
P: to the undesirable situation

   flapping addresses on hosts (every time the uplink goes up hosts
   receive an RA with non-zerop preferred PIO lifetime, and every time

O: non-zerop
P: non-zero

   the uplink goes down all address in the affected prefix become

O: all address
P: all addresses

deprecated). Undoubtedly it would negatively impact user experience, not
mentioning spikes of DAD traffic every time an uplink comes back

O: Undoubtedly it would negatively impact user experience,

   not mentioning spikes

P: This would, undoubtedly, negatively impact the user experience, not to
mention the impact of spikes up. Therefore it's recommended that router
vendors implement some form of damping policy for conditional RAs and
either postpone sending an RA with non-zero lifetime for a POI when the
uplink comes up for a number of seconds or even introduce accumulated
penalties/ exponential backoff algorithm for such delays. (In the case of
multiple simultaneous uplink failure scenario, when all but one uplinks are
down and the last remaining is flapping it might result in all addresses
being deprecated for a while after the flapping uplink recovers.) O: (In
the case of

   multiple simultaneous uplink failure scenario, when all but one
   uplinks are down and the last remaining is flapping it might result
   in all addresses being deprecated for a while after the flapping
   uplink recovers.)

P: (In the case of a

   multiple simultaneous uplink failure scenario, when all but one
   uplink is down and the last remaining one is flapping, this might result
   in all addresses being deprecated for a while after the flapping
   uplink recovers.)


3.3. Solution Limitations It should be noted that the proposed approach is
not a silver bullet for all possible multihoming scenarios. The main goal
is to solve some common use cases so it would suit very well relatively
simple topologies with straightforward policies. The more complex the

O:

so it would suit very well relatively simple
   topologies with straightforward policies.

P: -- I don't know, but I am having trouble parsing the above.

   network topology and the corresponding routing policies more

O: policies more
P: policies, the more

configuration would be required to implement the solution. Another
limitation is related to the load balancing between the uplinks. In that
scenario when both uplinks are active hosts would

O: In that scenario when both uplinks are active hosts
P: In the scenario in which both uplinks are active, hosts

select the source prefix using the Default Address Selection algorithm
([RFC6724]) and therefore the load between two uplinks most

O: algorithm ([RFC6724]) and therefore the load
P: algorithm ([RFC6724]), and therefore the load

likely would not be evenly distributed. (However the proposed

O: However
P: However,

   mechanism does allow a creative way of controlling uplinks load in
   SDN networks where controllers might selectively deprecate prefixes
   on some hosts but not others to move egress traffic between uplinks).
   Also the prefix selection does not take into account any other
   uplinks properties (such as RTT etc) so egress traffic might not be

O: (such as RTT etc) so
P: (such as RTT etc), so


   sent to the nearest uplink if the corresponding prefix is selected as
   a source.  In general if not all uplinks are equal and some uplinks
   are expected to be preferred over others then the network

O: In general if not all uplinks are equal and some uplinks
   are expected to be preferred over others then

P: In general, if not all uplinks are equal and some uplinks
   are expected to be preferred over others, then

   adminitrator should ensure that prefixes from non-preferred ISP(s)

O: adminitrator
P: administrator

   are kept deprecated (so primary/backup setup is used).

3.3.1.  Connections Preservation

   The proposed solution is not designed to preserve connections state

O: connections
P: connection
   after an uplink failure.  If all uplinks to an ISP go down all

O: If all uplinks to an ISP go down
P: If all uplinks to an ISP go down,

   sessions to/from addresses from that ISP address space are
   interrupted as there is no egress path for those packets and there is
   not return path from Internet to the correspodning prefix.  In this

O: not return path from Internet to the correspodning prefix.
P: no return path from the Internet to the corresponding prefix.

regard it is similar to IPv4 multihoming using NAT, where an uplink failure
and failover to another uplink means that a public IPv4 address changes and
all existing connections are interrupted. An uplink recovery, however, does
not nessesary leads to connections

O: nessesary leads
P: necessarily lead

   interruption.  In the load sharing/balancing scenario an uplink
   recovery does not affect any existing connections at all.  In the
   active/backup topology when the primary uplink recovers from the
   failure and the backup prefix is deprectaed, the existing sessions

O: deprectaed
P: deprecated

   (established to/from the backup ISP addresses) can be preserved if
   the routers are configured as described in Section 3.2.1 and send
   packets with the backup ISP source addresses to the backup uplink
   even when the primary one is operational.  As a result, the primary
   uplink recovery makes the usage of the backup ISP addresses
   discouraged but still possible.


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf