Hi Murray,
thank you for the suggested text that makes our intention is crystal clear.
I've updated the text and used your text in the second place:
OLD TEXT:
o SHOULD delete the P2MP BFD session associated with the P-tunnel;
NEW TEXT:
o the P2MP BFD session associated with the P-tunnel MUST be deleted.
The session MAY be deleted after some configurable delay, which
should have a reasonable default.
And s/SHOULD/MAY/ in Section 4.2:
When a PE receives a C-multicast route for a particular (C-S, C-G),
and the RT carried in the route results in importing the route into a
particular VRF on the PE, if the route carries the Standby PE BGP
Community, then the PE that supports this specification performs as
follows:
when the PE determines (the use of the particular method to detect
the failure is outside the scope of this document) that C-S is not
reachable through some other PE (more details are in Section 4.3),
the PE MAY install VRF PIM state corresponding to this Standby BGP
C-multicast route (the result will be that a PIM Join message will
be sent to the CE towards C-S, and that the PE will receive (C-S,
C-G) traffic), and the PE MAY forward (C-S, C-G) traffic received
by the PE to other PEs through a P-tunnel rooted at the PE.
Would these updates address your concerns?
Regards,
Greg
On Fri, Dec 18, 2020 at 6:09 PM Murray S. Kucherawy <[email protected]>
wrote:
>
>
> On Thu, Dec 17, 2020 at 8:57 PM Greg Mirsky <[email protected]> wrote:
>
>>
>> I can't quite parse the first sentence of Section 3.1.1. Maybe this will
>>> help:
>>>
>>> OLD:
>>>
>>> A condition to consider that the status of a P-tunnel is Up is that
>>> the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
>>> is reachable through unicast routing tables.
>>>
>>> NEW:
>>>
>>> When determining whether the status of a P-tunnel is Up, a condition
>>> to consider is whether the root of the tunnel, as determined in the
>>> x-PMSI Tunnel attribute, is reachable through unicast routing tables.
>>>
>> GIM>> Thank you for the suggested text, it is much clearer. I might
>> propose a small re-wording to get the following:
>> NEW TEXT:
>>
>> When determining if the status of a P-tunnel is Up,
>> a condition to consider is whether the root of the tunnel,
>> as specified in the x-PMSI Tunnel attribute, is reachable
>> through unicast routing tables.
>>
>> What do you think?
>>
>
> Yep, that's better.
>
>
>>> Section 3.1.2 has a similar concern.
>>>
>> GIM>> I agree and propose the following update:
>> OLD TEXT:
>> A condition to consider a tunnel status as Up can be that the last-
>> hop link of the P-tunnel is Up.
>> NEW TEXT:
>> When determining if the status of a P-tunnel is Up, a condition to
>> consider is whether the last-hop link of the P-tunnel is Up.
>>
>
> Looks good.
>
>
>>> Why is that a SHOULD and not a MUST in Section 3.1.6.1?
>>
>> GIM>> The thinking, as I recall, was that the operator might re-enable
>> P-tunnel tracking, and not deleting the p2mp BFD session(s) might make an
>> implementation to resume tracking faster. Though the gain might be
>> negligent for a single BFD session, but if the same PE is the root for
>> multiple multicast trees, such behavior might be useful. But thinking about
>> that now, we might give the same flexibility and still use MUST. Please
>> review the following update:
>> OLD TEXT:
>> o the P2MP BFD session SHOULD be deleted.
>> NEW TEXT:
>> o the P2MP BFD session MUST be deleted. The session MAY be deleted
>> after some of time. If an implementation uses a timer to delay
>> the cleanup, it MUST allow the configuration of the delay
>> interval, and use a reasonable default value.
>>
>
> Taking my own run at it; either is fine:
>
> o the P2MP BFD session MUST be deleted. The session MAY be deleted after
> some configurable delay, which should have a reasonable default.
>
>
>> Same question about
>>> 3.1.6.2,
>>
>> GIM>> I think that it was the same reasoning. Would applying the update
>> as above be helpful?
>>
>
> Sure.
>
>
>>
>>> and the ones in 4.2.
>>
>> GIM>> I think these two SHOULDs could have been MAYs but not MUSTs. In
>> fact, the text that follows uses MAY and then it is used to illustrate what
>> constitutes "cold root standby", "warm root standby, and "hot root
>> standby". The latter is the case when both SHOULD are followed.
>> Do you think that is reasonable?
>>
>
> My concern generally is just this:
>
> Or, if they are correctly SHOULDs, you might
>>> consider giving some guidance to the reader about when one might go about
>>> deviating from the advice given, since SHOULD offers a choice.
>>>
>>
> If you feel that your suggestion resolves that concern, I'm happy.
>
> -MSK
>
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
