Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras

From: Jen Linkova <[email-masked]>
Date: Mon, 3 Jul 2017 21:38:23 +1000

I received some comments off-list, so -01 version has been submitted:

https://datatracker.ietf.org/doc/draft-linkova-v6ops-conditional-ras/

- a co-author added;
- some clarification added to the "Topologies with Dedicated Border
Routers" section;
- a lot of typos, missing articles and commas fixed ;)

On Thu, Jun 15, 2017 at 4:14 PM, Jen Linkova <[email-masked]> wrote:
> Well, better late than never, right? So following the discussion on
> https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-00
> and the sad fact that default address selection rule 5.5 is not widely
> implemented (yet), I've finally managed to write down how multihoming
> on PA address space could be done now in *some* cases:
>
> https://tools.ietf.org/html/draft-linkova-v6ops-conditional-ras-00
>
> Comments are highly appreciated.
>
> P.S. It's '00' version, far from being perfect, I'll keep polish it
> and -01 will be submitted before the IETF99 deadline.
> --
> SY, Jen Linkova aka Furry

-- 
SY, Jen Linkova aka Furry

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Jul 2017 14:22:27 +0200

Jen,
Per your presentation today, slide 11 asking "potential triggers", and 
slide 12 green and blue paths.

The default route as a trigger.

An obvious trigger is the presence of the default route.  If the Router 
uses a default route towards ISP1 then it should prefer to advertise on 
its other interface defrouter capability together with the PIO 
containing the prefix it has for ISP1.

If on the other hand the router uses a default route towards ISP2, then...

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Jul 2017 14:23:38 +0200

For the case R1, R2, R3: if they are linked together on a single link 
where ICMP Redirect works then they may take advantage of that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 20 Jul 2017 12:45:06 +0000

Hi, someone at the mike just now suggested the possible use of RIOs for this.
Please see our draft on this subject from 6man:

https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, July 20, 2017 5:24 AM
> To: [email-masked]
> Subject: Re: [v6ops] Enterprise multihoming (again): draft-linkova-v6ops-conditional-ras
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: David Lamparter <[email-masked]>
Date: Thu, 20 Jul 2017 16:06:18 +0200

I've pushed a very minimal implementation to
https://github.com/opensourcerouting/frr/tree/cond-ra

It just does the bare minimum by setting the preferred lifetime to 0 if,
when sending an RA anyway, the prefix can't reach the configured test
destination.  (Changes do not trigger out-of-schedule RAs yet.)

An example config would be:
 interface dummy0
  ipv6 nd prefix 2001:db8:1234:5678::/64 86400 7200 conditional ::/0

first prefix is the prefix advertised, 86400 is valid-lft, 7200 is
preferred-lft, conditional ::/0 is the destination to test in the
routing table for reachability.

This does a lookup with src=2001:db8:1234:5678::/64 dst=::/0 and sets
preferred lifetime to zero if no (possibly less specific) route is
found.

It does not implement any of the other test conditions in the draft
(e.g. VRRP status);  I think checking route availability should be
sufficient.

Cheers,

-David