Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

[Eric C Rosen <[e-mail]>]

Thanks for your review.  I have posted revision -04 which I believe 
addresses your substantive comments.

On 1/3/2018 8:01 AM, [e-mail] wrote:
>
> Hi,
>
> As shepherd of this document, please find below some comments that I have:
>
> Overall comments:
>
> -Please add a section that contains all the abbreviations expansions: 
> that may help non expert people to follow the acronyms without looking 
> for the first reference in the text.
>

This is not generally required of an RFC.

> -I usually like figures. For the intro, it may be wonderful to build a 
> figure that reminds the existing S-PMSI/Leaf A-D procedure. So without 
> reading the text, we can remember how it works.
>
> -The interAS case may also be better with a Figure and an example (or 
> couples of).
>

This seems like a matter of taste.  Admitedly, I'd probably like figures 
more if I had any skill in producing them ;-)

> Introduction:
>
> “By originating one of these BGP routes, an ingress node advertises that
>
>    it is transmitting a particular multicast flow.”
>
> [SLI] Is “is transmitting” correct ? Can’t we have situations where an 
> S-PMSI route is/was advertised but no traffic is flowing (no yet 
> started or switched, or stopped).
>

Fixed.

> “Now
>    suppose that the ingress node wants explicit tracking for each
>    individual flow that it transmits (following the procedures of
>    [RFC6625] on that P-tunnel.”
> [SLI] Missing “)”

Fixed.

> “This allows the
>    ingress node to determine the set of egress nodes that are receiving
>    flows from the ingress node.”
> [SLI] I think the Leaf A-D tells that there is a receiver interested 
> by the flow, but does not tell that it actually receives it.

Correct; fixed.

> “   Howver, this procedure requires several clarifications:”
> [SLI] There is a typo s/Howver/However/

Fixed.

> “The procedures of [RFC6625] do not clearly state how to handle an
>       S-PMSI A-D route if its NLRI contains wild cards, but its PTA
>       specifies "no tunnel info".”
> [SLI] I quickly ran over RFC6625, it does not mention anything on 
> explicit tracking or Leaf A-D routes.So we assume that RFC6513/6514 
> only applies here.

RFC 6625 specifies the handling of wildcard S-PMSI A-D routes, but did 
not consider the case where the S-PMSI A-D routes do not carry a PTA.  
This document corrects that.

> “   *  The explicit tracking procedures do not allow an ingress node
>          to "see" past the boundaries of the segmentation domain.
>          This particular problem is not further addressed in this
>          revision of this document.
> “
> [SLI] Do you plan to address it ? Or do we now consider it as out of 
> scope ?

I think this is actually addressed in Section 5.3, so I've removed the 
remark.

> Section 2:
> “Prior specifications define one flag in the PTA, the "Leaf Info
>    Required" (LIR) flag, that is used for explicit tracking.”
> [SLI] Please point to the right reference

Fixed.

> “If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA
>    SHOULD also be set.”
> [SLI] Why not using a MUST ?

If all the PEs support the LIR-pF flag, the procedures will work as 
intended even if the LIR flag is not set.  So I don't think a MUST is 
appropriate.

> “one forces a
>    a response to be sent an egress node that does not support LIR-pF”
> [SLI] Is there a missing word like ‘sent by an egress node” ?

Fixed.

> Section 3:
>
> “The definition of "match for reception" in [RFC6625] is hereby
>    modified as follows:”
> [SLI] Please point to the section that you are updating.
> In addition, section 3.2 of RFC6625 contains multiple if then else 
> conditions for each cases (C-S,C-G) and (C-*,C-G). Please give some 
> precision in where do you want to insert your new statement in this 
> processing sequence. I guess it is at the beginning.

I tried to make this clearer.

> “When finding the "match for reception" for a given (C-S,C-G) or
>       (C-*,C-G), ignore any S-PMSI A-D route that has no PTA, or whose
>       PTA specifying "no tunnel information".”
>
> [SLI] I would be in favor to introduce a normative statement here.
>

Fixed.

> “We also introduce a new notion: the "match for tracking".  This
>    differs from the "match for reception" as follows:”
> [SLI] It would be better to give a definition of the “match for 
> tracking” before giving the rules. Here you’re explaining only the 
> rules, not the difference in the meaning. Wouldn’t it be easier to 
> tell that the implementation MUST consider only the S-PMSI A-D routes 
> that have a LIR flag and/or LR-pF flag set and then run the same rules 
> as the RFC6625. Why do you want to have S-PMSI routes with PTA and LIR 
> unset in your route list for “match for tracking” ? You need to take 
> care here on your text proposal as one of your previous statement 
> updates the RFC6625 and the match reception procedure, so the rules to 
> be applied are the original one from RFC6625 and not the updated one.

IMO, the clearest way to express this is to give the rules and then 
illustrate with a couple of examples.

> “   Also note that if a match for tracking does not have the LIR flag or
>    the LIR-pF flag set, no explicit tracking information will be
>    generated.  See Section 5.”
> [SLI] Again I do not see the value added of keeping such route as a 
> match for tracking as there is no tracking requested.

As the terms are defined, there is always a "match for tracking" route 
for each flow.    If tracking is not requested, this route will have LIR 
and LIR-pF clear.  There are no unnecessary routes.

> Section 4:
> “Such a route could be an
>        I-PMSI A-D route, a (C-*,C-G1) S-PMSI A-D route, a (C-S1,C-*)
>        S-PMSI A-D route, or a (C-*,C-*) S-PMSI A-D route. “
> [SLI] Is per flow explicit tracking also required for I-PMSI ? I do 
> not see it listed in the goals of the doc ? The goal was to address 
> wildcards S-PMSI AD routes.

The above simply says that some route must specify the tunnel on which 
the (C-S1,C-G1) is to be transmitted, and that this route could be an 
I-PMSI A-D route.

> “Further, if the ingress node originates a wildcard S-PMSI A-D
>
>        route carrying a PTA specifying the tunnel to be used for
>
>        carrying (C-S1,C-G1) traffic, and if that PTA has the LIR-pF bit
>
>        set, then explicit tracking for (C-S1,C-G1) is requested by that
>
>        S-PMSI A-D route.  Thus the ingress node SHOULD NOT originate a
>
>        (C-S1,C-G1) S-PMSI A-D route whose PTA specifies "no tunnel
>
>        info"; such a route would not provide any additional
>
>        functionality.”
>
> [SLI] I do not fully understand this text in the context of your 
> procedure 1. which deals with an origination of an (C-S1,C-G1) S-PMSI 
> A-D route (no wildcard). As I understand the procedure for the 
> wildcard is defined in 2.
>

This just says that there's no point in originating S-PMSI(C-S,C-G) with 
LIR set if you've already originated S-PMSI(C-*,C-G) with LIR-pF set.  
That seems to be an appropriate bit of advice.

> “2. The following procedure can be used if (and only if) it is known
>
>        that the egress nodes support the optional LIR-pF flag.”
>
> I have some issue with this sentence. It does not seem to be normative 
> as there is no normative statement. However I understand it as a 
> critical thing (“and only if” !) so it may require at least a SHOULD.
> Then the issue I see is that this knowledge does not come from the 
> protocol, so it sounds important to me to highlight the impact of a 
> mistake.
> BUT, reading the section 5. I understand that it is not as critical as 
> it seems as the receiver will ignore simply the LIR-pF flag and apply 
> the standard procedure (LIR set).
> Please clarify the criticity to have or not this knowledge.

I added some text saying that procedure 2 may yield unexpected results 
if not all the PEs support LIR-pF, and that the procedure SHOULD NOT be 
used in that case.



> “       To terminate explicit tracking that has been initiated by an
>
>        S-PMSI A-D route whose PTA specifies a tunnel, the ingress node
>
>        re-originates the route without the LIR flag set”
>
> [SLI] Do we also need to clear the LIR-pf ? It would make sense to do so.
>

Fixed.

> “If the match for tracking has LIR set and if either (a) the
>
>        egress node does not support LIR-pF, or (b) LIR-pF is not set,
>
>        then the egress node must respond to the match for tracking,
>
>        following procedures specified in other documents for the case
>
>        where LIR is set.”
>
> [SLI] Please state the relevant document references here.
>

In the case described above, the handling of the LIR flag is not 
modified by this document.  I don't think it is necessary to cite a 
specific set of documents that discuss the LIR flag.

> Section 5.2
>
> “Note that, per RFC4364, every RD begins with a two-octet type field
>
>    that is either 0, 1, or 2.  By adding 16 to the second octet of the
>
>    RD, we force the type field to be 16, 17, or 18. “
>
> [SLI] It works but we may need to ensure that the types > 16 cannot be 
> used anymore by new applications.
>

There is  a registry for the Route Distinguisher Type field.  Only types 
16, 17, and 18 are defined here, other values are still available.

> Moreover if new RD types are created, new siblings will have to be 
> created.
>

Your point is correct, but there hasn't been a new RD type in 20 years.  
The draft shouldn't really say "add 16", it should just point out the 
new types.

> Wouldn’t it be easier to set the MSB of the RD type to 1 ? so we only 
> lock half of the type space.
>

I think it is easier to use three new type values than to turn one of 
the bits into a flag.

> Or what could be the impact of using the RD of the local VRF of the 
> egress node ?
>

The RD of the Leaf A-D route needs to be derived from the RD of the 
S-PMSI A-D route that elicits it.  Otherwise the ingress node receiving 
the Leaf A-D route will have diffculty matching it to the corresponding 
S-PMSI A-D route.

> Section 5.3
>
> “In the case where the egress
>
>    node is not a PE, but rather an ABR or ASBR, it will not know whether
>
>    it needs to receive a given flow unless it receives a Leaf A-D route
>
>    whose NLRI specifies that flow and whose IP-address-specific RT
>
>    specifies an address of the egress node.”
>
> [SLI] The sentence works but when reading it I needed multiple reread 
> to understand that the “IP-address-specific RT
>
>    specifies an address of the egress node.” was referring to the 
> ASBR/ABR and not the receiver PE.
>
> Do you mind using “this egress node” or “this ABR/ASBR” ?
>

I tried to clarify that.

> Section 8.
>
> [SLI] Do we have counter-measures against such “attack” ? Ingress PE 
> dropping ?
>

I consider the specification of such counter-measures to be outside the 
scope of the document.

> Section 9.2
>
> I think RFC7524 needs to be referenced as normative giving that its 
> knowledge is required to understand section 5.3.
>

I'm not sure that RFC7524 should be a normative reference, as this draft 
does not require segmentation at the ABRs.  However, since RFC7524 is 
already published, there's no harm in adding it to the "normative 
references" section.

> I think that section 5.3 is also updating/complementing the procedures 
> in RFC7524 with the “no-tunnel info” case.
>

There don't seem to be any clear and objective criteria for determining 
whether one document "updates" another.