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

[<[e-mail]>]

Hi Eric,

Thanks for your answers. Your proposed changes look fine to me.

Regarding the RD modification, your proposal to reuse the PTA instead of tweaking the RD looks also better.

Brgds,


From: Eric C Rosen [mailto:[e-mail]]
Sent: Tuesday, February 06, 2018 21:29
To: LITKOWSKI Stephane OBS/OINIS; [e-mail]; Dolganow, Andrew (Nokia - SG/Singapore)
Cc: [e-mail]; [e-mail]
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-expl-track

On 1/24/2018 2:25 AM, [e-mail]<mailto:[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.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.