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

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

Hi Jen,

Please see inlined.

Thanks,
Dusan.

> -----Original Message-----
> From: Jen Linkova [mailto:[e-mail]]
> Sent: Saturday, March 17, 2018 10:09 AM
> To: Mudric, Dusan (Dusan)
> Cc: Gert Doering; [e-mail]
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-01.txt
> 
> 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?

[[Dusan]] 
[[Dusan]] One ISP might be more reliable or can provide better QoS, for example.

> 
> >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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Drtgwg-2Denterprise-2Dpa-
> 2Dmultihoming-2D03-23section-
> 2D4.2.2&d=DwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCr
> hIoUWB8YLZU23029sMQGQ2kY&m=-
> jWKLsdR_Ty6WyW71Q4s9hNbRCBu7cfr6LE5DlJd-
> RE&s=i7CFt5kd63hOe44GmGE3u3pd8OVgZnJxGGsj1JONwrs&e= 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]] 
[[Dusan]] Why the Prf from rfc4191#section-2.2 cannot be set by the router? This is not a protocol change? The flags are already defined in the RFC4191.


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

[[Dusan]] 
[[Dusan]] This is an implementation aspect. If hosts implement the Prf from rfc4191#section-2.2, they will recognize Rrf. You should not limit the options based on the current implementations.

> 
> >> 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.
> 
[[Dusan]] I think Rrf setting should be in the draft. It might not be used by the hosts today, but can be used by the hosts of tomorrow.

> --
> SY, Jen Linkova aka Furry