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.


From: Eric C Rosen [mailto:ero...@juniper.net]
Sent: Tuesday, February 06, 2018 21:29
draft-ietf-bess-mvpn-expl-track.auth...@ietf.org; Dolganow, Andrew (Nokia - 
Cc: bess@ietf.org; bess-cha...@ietf.org
Subject: Re: Shepherd's review of draft-ietf-bess-mvpn-expl-track

On 1/24/2018 2:25 AM, 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com> 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 

[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 

[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

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 

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.

BESS mailing list

Reply via email to