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

Thanks a lot for your review, Warren!
(Especially for fixing the punctuation! ;)

I've integrated the proposed changes and modified the pseudo-code,
hopefully it's a bit more readable now.
Please let me know if you still have concerns or suggestions on how it
improve it further.

Also I've fixed a few nits reported by the id-nit tool:
- removed references from the abstract and replaced them with a plain text;
- removed 'MUST' from the text.

The -04 version:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/

https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-04

Thanks!

On Sat, May 5, 2018 at 4:18 AM, Warren Kumari <warren@kumari.net> wrote:
> 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
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
SY, Jen Linkova aka Furry