Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt

["Mudric, Dusan (Dusan)" <[e-mail]>]

Hi,

In Abstract:

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

Should be:
"The problem of enterprise multihoming without address
   translation of any form has not been solved yet as it requires
   the hosts to select the correct source address based
   on a destination address for that traffic, 
   the hosts to select a first hop router based on the packet
   source address, and the network to select the correct egress ISP based on the packet
   source address"

This introduction would be more suited for Figures 2&3. If not, please clarify the intent of the draft.

3.2.1.  Single Router, Primary/Backup Uplinks

What "if{packet_destination_address is in 2001:db8:1::/48 or 2001:db8:2::/48}"? Will the next hop still be determined by the source address? If yes, is the destination address check needed?

3.2.2.  Two Routers, Primary/Backup Uplinks
Similar as above. 

Why would R1 have a policy that sends a packet to "next-hop is ISP_B_uplink", if it does not talk to ISP_B?

With R1 and R2 policies, H1 would have only one prefix all the time. How will H1 do load balancing or send one application stream over ISP_A and another over ISP_B, if needed? Maybe the first sentence needs to state that only one ISP can be used.

3.2.3.  Single Router, Load Balancing Between Uplinks
If load balancing is used, R1 sends packets to an ISP_x based on the source address. This means the host must know which ISP (source address) to select. How does host know this?

3.2.5.  Topologies with Dedicated Border Routers
"For load-balancing case ...
   prefix 2001:db8:2:1::/64 {
     if ISP_B_uplink_route is present then preferred_lifetime = 0
       else preferred_lifetime = 604800
    }"

Is this just copy and paste from the NON-load-balancing policy? Why would H1 use 2001:db8:2:1::/64 if "ISP_B_uplink_route is NOT present" and send traffic over R2 - R3 - ISP_A with 2001:db8:2:1::x source address?

Page 10:
Typo: "trgger"


Regards,
Dusan Mudric.

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Jen Linkova
> Sent: Tuesday, February 27, 2018 3:03 PM
> To: [e-mail]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
> 
> The draft (draft-ietf-v6ops-conditional-ras)has been updated to
> address comments received in Singapore.
> 
> Any feedback is appreciated, especially if you have any suggestions on
> how to improve the document.
> 
> On Wed, Feb 28, 2018 at 6:57 AM,  <[e-mail]> wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the IPv6 Operations WG of the IETF.
> >
> >         Title           : Using Conditional Router Advertisements for Enterprise
> Multihoming
> >         Authors         : Jen Linkova
> >                           Massimiliano Stucchi
> >         Filename        : draft-ietf-v6ops-conditional-ras-01.txt
> >         Pages           : 17
> >         Date            : 2018-02-27
> >
> > Abstract:
> >    This document discusses most common scenarios of connecting an
> >    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.
> >    [I-D.ietf-rtgwg-enterprise-pa-multihoming] proposes a solution to
> >    this problem by introducing a new routing functionality (Source
> >    Address Dependent Routing) to solve the uplink selection issue and
> >    using Router Advertisements to influence the host source address
> >    selection.  While the above-mentioned document focuses on solving the
> >    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
> >    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].
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dconditional-
> 2Dras_&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhI
> oUWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFiv
> eiJiW4g&s=4GiE9981xqO7DwH-RffXvRXuxwZGkG_QrwoHaFUVsc4&e=
> >
> > There are also htmlized versions available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dv6ops-2Dconditional-2Dras-
> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive
> iJiW4g&s=1q5WZlStkpgafuIZcNyITzCYHMR9sxnxPjqRsanSv0w&e=
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dv6ops-2Dconditional-
> 2Dras-
> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive
> iJiW4g&s=3Yki_IS8Q3O9n3vWhd8JTcchlcUF0_8nCIMTKUFeBc8&e=
> >
> > A diff from the previous version is available at:
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dv6ops-2Dconditional-
> 2Dras-
> 2D01&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIo
> UWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHRFive
> iJiW4g&s=EzOsCZBnjl_2C2UOT7sBNzyvAVc7XN7ULjrSXwlcL34&e=
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-
> 2Ddrafts_&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iC
> rhIoUWB8YLZU23029sMQGQ2kY&m=Tvwolb891s9E__RcQ05Srqho90KVleyHR
> FiveiJiW4g&s=k-4jLyp-ruXqFPp_GKnLNTWz_VXishJWQtLDfIixeFU&e=
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Tvwol
> b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=jY0VQvQFNS1fCWqzD1ewRO
> p807KXejHGqSOM79nXAWA&e=
> 
> 
> 
> --
> SY, Jen Linkova aka Furry
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl1
> SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Tvwol
> b891s9E__RcQ05Srqho90KVleyHRFiveiJiW4g&s=jY0VQvQFNS1fCWqzD1ewRO
> p807KXejHGqSOM79nXAWA&e=