Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT)

[Jen Linkova <[e-mail]>]

Hi Suresh,

On Thu, Aug 2, 2018 at 11:51 PM, Suresh Krishnan <[e-mail]> wrote:
> * Section 3.1.1.
>
> I think a reference to RFC3704 (specifically written for describing ingress
> filtering for multihomed networks) might be a good addition here to RFC2827

Done!

> * Sections 3.2.1., 3.2.2. etc.
>
> => I think it is important to specify (at least the bounds of) the valid
> lifetimes here as well. e.g. when the preferred lifetime is getting set to zero
> it is important to specify that the valid lifetime is set to a non zero value
> so that the host will form an address at all (even though it will not be used
> when there are preferred addresses). This is important to reduce the potential
> packet losses when the preferred uplink goes down.

I've added a paragraph clarifying that we only modify preferred
lifetime and that RFC4862 does not
allow an RA with both preferred and valid lifetime for the prefix set
to 0 to invalidate the address completely:

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

> * Section 3.2.2.
>
> I think there is some text missing here about VRRP priorities here. There seems
> to be an assumption in the draft that the uplink A failure will lead to R1
> becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this
> is not obvious at all. There needs to be a priority change with interface
> tracking if this has to happen and the backup has to take over as the master.

I've rephrased it to:
"R1 is the VRRP master by default (when ISP_A uplink is up).  If ISP_A
   uplink is down, then R1 becomes a backup (the VRRP interface status
   tracking is expected to be used to automatically modify the VRRP
   priorities and trigger the mastership switchover). "


Please let me know if the new version does not address your comments!

Thanks!

-- 
SY, Jen Linkova aka Furry