On 2/22/2018 3:10 AM, [email protected] wrote:
Hi Eric,
Thanks a lot for the update.
And thank you for your continued attention to the details. I have
posted -08. Responses in-line.
Couple of more comments:
Section 2:
I still have some concern about these two sentences:
1)"This flag SHOULD NOT be set
unless it is known that all the PEs that are to receive the route
carrying the PTA support the flag."
2)"By setting LIR as well as
LIR-pF, one forces a response to be sent by an egress node that does
not support LIR-pF."
[SLI] As per 1), the situation described in 2) should not happen
Do we agree that this should not happen ?
I think we can make the text more clear about the implications of setting the
LIR-pf in a partial deployment scenario.
We can add a text like after 1):
"Setting the LIR-pF in a network where only a subset of PEs supports it prevents the
ingress PE to have a complete view of the receiving PEs."
We may also modify 2) as follows:
OLD
By setting LIR as well as
LIR-pF, one forces a response to be sent by an egress node that does
not support LIR-pF. It is possible to tell from that response that
the egress node does not support LIR-pF. This may be an aid to
troubleshooting.
NEW
By setting LIR as well as
LIR-pF, one forces a response to be sent by an egress node that does
not support LIR-pF. It is possible to tell from that response that
the egress node does not support LIR-pF. As the support of LIR-pF is
recommended on all PEs, this situation should not happen.
However, in case of deployment error, this may be an aid to troubleshooting.
[Eric] In revision -08, I have reworked this text to indicate what will
happen in the case of deployment errors, and how such errors can be
detected. However, I wouldn't necessarily guarantee that there are no
corner cases in which a deployment error might go undetected.
Section 5.2:
"The encoding of these Leaf A-D routes is similar to the encoding of
the Leaf A-D routes described in section 6.2.2 of [RFC7524], which
were designed for the support of "global table multicast". However,
that document sets the RD to either 0 or -1; following the procedures
of this document, the RD will never be 0 or -1. Therefore Leaf A-D
routes constructed according to the procedures of this section can
always be distinguished from the Leaf A-D routes constructed
according to the procedures of section 6.2.2 of [RFC7524]. Also,
Leaf A-D routes constructed according to the procedures of this
section are VPN-specific routes, and will always carry an IP-address-
specific Route Target, as specified in [RFC6514]."
[SLI] I'm wondering if this text is still required as we do not modify the RD
compared to RFC6514.
[Eric] There are two situations in which an ingress node might receive a
Leaf A-D route whose route key field is not identical to the NLRI of a
current x-PMSI A-D route originated by the ingress node. One situation
is specified in RFC 7524. The other is specified in the explicit
tracking draft. I think it is useful to point out that the ingress node
can distinguish between these two cases when it receives such a Leaf A-D
route.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
