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

[Suresh Krishnan <[e-mail]>]

Hi Jen,

> On Aug 10, 2018, at 8:25 AM, Jen Linkova <[e-mail]> wrote:
> 
> 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!

Looks good to me with the minor clarification that Jinmei-san proposed. Thanks for addressing these comments.

Regards
Suresh