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

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

On 1/24/2018 2:25 AM, [e-mail] wrote:
> “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.
>
>
> [Eric] 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.
>
> [SLI2] My point was that RFC6625 does not specify anything regarding 
> explicit tracking while your sentence says  “do not clearly state”. In 
> reality, it does not state anything about how explicit tracking works 
> for wildcard routes.
>

I see your point now.  I propose to change this in the -07 rev to:

       The procedures of [RFC6625] do not address the case of an S-PMSI

       A-D route whose NLRI contains wild cards, but whose PTA specifies

       "no tunnel info".


> “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 ?
>
>
> [Eric] 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.
>
> [SLI2] Ok so do we really care of having the LIR flag set ? If not, 
> couldn’t be a MAY ? I’m just wondering how important is to set the 
> LIR-flag here. It seems to be linked to the next sentence between 
> parenthesis.
>
> I understand that setting both allows to always have a response (per 
> flow or not per flow). Can we see this as an optional feature ?
>

My reasoning for suggesting that LIR SHOULD be set whenver LIR-pF is set 
is captured in the following sentence from the draft:

    (By setting LIR as well as LIR-pF, one forces a

    a response to be sent by an egress node that does not support LIR-pF,

    and it is possible to tell from that response that the egress node

    does not support LIR-pF.)


This is intended to be a troubleshooting aid.  Nodes that don't support 
LIR-pF will respond to the LIR flag, and the response to the LIR flag is 
different than the response to the LIR-pF flag, because the RD is 
modified.  LIR-pF really shouldn't be used unless all the PEs support 
it, and this is a way of detecting  a configuration/provisioning problem.

I would be happy to hear others' opinions on whether this is a 
worthwhile hack.

> “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.
>
>
> [Eric] IMO, the clearest way to express this is to give the rules and 
> then illustrate with a couple of examples.
>
> [SLI2] You are right, I’m just challenging the fact that the text says 
> that it will explain how the match for tracking differs from the match 
> from reception but it does not. It’s the job of the reader to deduce 
> the difference from the rule you are giving.
>

Okay, I get your point now.

In the -07 rev, I propose to eliminate the sentence "This differs ...", 
and to add the following sentence after the rule:

       That is, the procedure for finding the match for tracking takes

       into account S-PMSI A-D routes whose PTAs specify "no tunnel

       information" and that have either LIR or LIR-pf set.  The

       procedure for finding the match for reception ignores such routes.


> “   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.
>
>
> [Eric] 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.
>
> [SLI2] Agree, but based on my understanding such a route (with LIR and 
> LIR-pF clear) cannot be a match for tracking by definition : “ignore any S-PMSI A-D route whose PTA specifies
>
>   "no tunnel information", but does not have either LIR or LIR-pF
>
> Set”
>
> So the statement  “if a match for tracking does not have the LIR flag or the LIR-pF flag set” is IMO wrong.

As the terms are defined, the match for tracking could be a route whose 
PTA specifies a tunnel.    In this case, it would be the same as the 
match for reception.  The PTA of such a route could well have LIR and 
LIR-pF clear.

> “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.
>
>
> [Eric] 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.
>
> ad> maybe we can say “the procedures specified in this document do not 
> apply are not applicable on the egress node” instead of “then the 
> egress node…”
>
> [SLI2] That’s a good proposal
>

I've changed this to:

        then the behavior of the egress node is not affected by the

        procedures of this document.


With regard to the modification of the RD, there are a couple of issues.

[SLI2] I’m also wondering if we really need to differentiate the reply 
to a LIR-pF and to a LIR. The key point is for the ingress to know about 
the receivers for a particular (S,G). If the reply comes from a LIR or 
LIR-pF, IMO, it does not really matter. Is it ?

The pre-existing procedures for processing a received Leaf A-D route 
require one to find the S-PMSI A-D route whose NLRI is identical to the 
"route key" field of the the Leaf A-D route's NLRI.   But if the Leaf 
A-D route was elicited by the LIR-pF flag, the NLRI of the corresponding 
S-PMSI A-D route won't be the same as the route key field of the Leaf 
A-D route's NLRI.  I thought it best to have some way of distinguishing 
these two cases.  You're right that it is not strictly necessary to the 
correct operation of the protocol, but it seems like a good hack for 
aiding debugging and troubleshooting.

However, you are also right that the proposal for modifying the RD is 
problematic, for the reasons you give.  Using the high order bit of the 
RD field as a flag is also problematic, because an RD value of all 1's 
is already in use by RFC 7524.

Perhaps a better approach would be to say that a Leaf A-D route sent in 
response to LIR-pF SHOULD (or perhaps MUST) contain a PTA with LIR-pF 
set.  That would convey the information without causing the RD registry 
problems that you've pointed out.  What do you think?

> “However, if the PTA of the installed S-PMSI A-D route specifies "no
>
> tunnel info", the egress ABR/ASBR MUST pass the PTA along unchanged
>
> when it forwards the S-PMSI A-D route.  (That is, a PTA specifying
>
> "no tunnel info" MUST NOT be changed into a PTA specifying a tunnel.)
>
> Furthermore, if the PTA specifies "no tunnel info", the LIR and LIR-
>
> pF flags in the PTA MUST be passed along unchanged.”
>
> [SLI]Could you confirm that in case of SPMSI merging to IPMSI, the 
> SPMSI route is not forwarded.
>

I have to confess that I never thought there was a use case for S-PMSI 
merging to I-PMSI, and don't really know the procedures for that.    
Hopefully, no one's ever deployed that.

> I’m not fully familiar with interAS segmented case, but I have another 
> (possibly dumb) question. Is a merge case SPMSI regular (S,G) to SPMSI 
> wildcard possible ? (in a similar way as SPMSI to IPMSI). If yes, what 
> are the procedures here ?
>

I'm pretty sure there are no such procedures.

> Section 8.
>
> [SLI] Do we have counter-measures against such “attack” ? Ingress PE 
> dropping ?
>
>
> [Eric] I consider the specification of such counter-measures to be 
> outside the scope of the document.
>
> [SLI2] Fine, could you please state this in the security section ?
>

Okay, will be in the -07 rev.