Re: [Gen-art] Genart last call review of draft-ietf-bess-mvpn-expl-track-10

[Brian E Carpenter <[e-mail]>]

Hi Eric,

On 2018-10-05 04:15, Eric Rosen wrote:
>> Minor issues:
>> -------------
>>
>> As I understand it, if a network only partially supports the new
>> (LIR-pF) flag, it doesn't work properly. So we find at the end of
>> section 2:
>>
>> ...the ingress node can conclude
>>     that the egress node originating that Leaf A-D route does not support
>>     the LIR-pF flag.
>>
>>     The software at the ingress node SHOULD detect this, and should have
>>     a way of alerting the operator that the deployment is not properly
>>     configured.
>>
>> I don't see why this is only a SHOULD, and I don't see why the operator
>> alert is not a MUST too. Surely the operator always needs to be alerted?
> 
> Good point, I have changed this to:
> 
>     The software at the ingress node MUST detect this, and MUST have a 
> way of alerting the operator that the deployment is not properly configured.

Thanks.
 
>> I agree with the point raised in the Routing Area review
>> (be explicit about the updated sections of RFC 6514, 6625,
>> and 7524).
> 
> The clarifications and extensions may affect the procedures for 
> originating and receiving/processing S-PMSI A-D routes and Leaf A-D 
> routes.  These procedures are discussed in many different places in the 
> updated drafts.  

Fair enough. I suggest adding a version of those two sentences in the
Introduction. Otherwise you can bet on this point being raised by the
IESG anyway.

Regards
    Brian

> I don't believe there is any value in having the 
> authors of mvpn-expl-track go through those drafts to try to make a list 
> of all the places where S-PMSI A-D routes and/or Leaf A-D routes are 
> discussed.  If we attempted to do so, we'd surely miss a few places and 
> thereby introduce bugs into the spec.  The information currently in the 
> document is sufficient to enable anyone who understands the updated 
> references to figure out what needs to be done.