On 1/24/2018 2:25 AM, 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 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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
