Re: [bess] I-D Action: draft-ietf-bess-mvpn-expl-track-07.txt

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

On 2/22/2018 3:10 AM, [e-mail] 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.