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

[Brian E Carpenter]

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.




___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric Rosen]

> 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.

> 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.  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.

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Genart last call review of draft-ietf-bess-mvpn-expl-track-10

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-bess-mvpn-expl-track-10

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-bess-mvpn-expl-track-10.txt
Reviewer: Brian Carpenter
Review Date: 2018-10-02
IETF LC End Date: 2018-10-09
IESG Telechat date: 

Summary: Ready with issues


Comments: 
-

I agree with the point raised in the Routing Area review
(be explicit about the updated sections of RFC 6514, 6625,
and 7524).

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?


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess