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

[Jen Linkova <[e-mail]>]

On Fri, Mar 9, 2018 at 3:40 AM, Mudric, Dusan (Dusan) <[e-mail]> wrote:
> I believe I understood the intent of the draft. Let me explain my understanding of rule 5.5. Please see inlined.

>> ISP uplink is either "preferred" (hosts are allowed to use it, the
>> network can send packets there, because the uplink is up and there is
>> no explict policy which indicates that the uplink should not be used
>> if other uplinks are available) or not preferred (it's down or there
>> is a policy to prevent using this uplink ex. for backup).
>> It's binary state.

> [[Dusan]] The router knows more than that. For 'usable' prefixes, the router knows which prefix is the most preferred.

Would you be able to give an example for 'most preferred'? The network
has two uplinks to two ISPs, two prefixes. Both uplinks can be used.
Each border router has a default route pointing to the uplink.
What prefix is 'most preferred' to reach  Internet?

>The router can pass that knowledge in RA PIO option, using 'reserved' bits, for example (like Prf in rfc4191#section-2.2 ). Without this information, if there are two prefixes (ISP1-D and ISP2-D) how will host know if it should talk to D over ISP1 or ISP2? Rule 5.5 cannot determine it:
>
>    Rule 5.5: Prefer addresses in a prefix advertised by the next-hop.
>    If SA or SA's prefix is assigned by the selected next-hop that will
>    be used to send to D and SB or SB's prefix is assigned by a different
>    next-hop, then prefer SA.
>
> You can consider the trick in https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-03#section-4.2.2 by setting two routes in RA and the Prf from rfc4191#section-2.2, based on the router policy. This would allow a host to select the preferred next hop and use the preferred next hop in Rule 5.5. Using Prf in RIO the router policy is distributed to all hosts and they can select the preferred ISP. A router SHOULD set Prf based on the ISP selection policy. There might be use case when the network would use only one route and advertise one prifix.

I'm not sure if you've been following the whole story....When
draft-ietf-rtgwg-enterprise-pa-multihoming was presented to v6ops in
Berlin, we came to conclusion that while the described trick is nice,
it could not be widely used now. So some tactical solution is needed.
That's why this draft was 'forked' from the RTGWG one.
So anything which require protocol changes/new features/rule 5.5
support is out of scope of this draft by the definition.

> [[Dusan]] Because the router should not limit the communication over one ISP by advertising only one prefix. The host should be able to decide which of the two ISPs to use. Both prefixes should be given to the host

In the 'load sharing' scenario it is exactly what happens. All ISP
prefixes are included in PIO.
In the active/backup scenario only active uplinks prefixes are
advertised, because the network policy does not allow hosts to use the
backup uplink so hosts should not select backup uplinks.

> and they should have the preference assigned.

Which hosts would not recognize.

>> Have I sent this email to 6man@ by mistake? Ah, does not look like that :)
>> And I seem to set the document status to 'Informational'.

> [[Dusan]] If we change IPO option, it is not informational any more.

Again, the goal of *this particular* draft is to document existing
solution, which can be used right now w/o any changes on the host.

If we have ideas how to improve the protocol - great, but those ideas
should not be in this draft.

-- 
SY, Jen Linkova aka Furry