Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

[Eric Rosen <[e-mail]>]

On 10/22/2018 9:41 PM, Benjamin Kaduk wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This document places normative requirements on new tunnel types but does
> not indicate this in a way that someone specifying a new tunnel type would
> be forced to see.  This occurs both in Section 5.2:
>
>     o  When additional tunnel types are defined, the specification for
>        how MVPN is to use those tunnel types must also specify how to
>        construct the PTA of a Leaf A-D route that is originated in
>        response to the LIR-pF flag.  As an example, see [BIER-MVPN].
>
> and in Section 6:
>
>     If L's PTA specifies a tunnel type not mentioned above, the
>     specification for how MVPN uses that tunnel type must specify the
>     actions that N is to take upon receiving L.  As an example, see
>     [BIER-MVPN].
>
> I think the best way to do this would be to have IANA Considerations
> updating the registration procedure for
> P-Multicast Service Interface (PMSI) Tunnel Type codepoints to note that
> new registrations must include this information.  It might also suffice to
> call out the existence of these requirements in the portion of the
> Introduction that discusses how this document Updates RFC 6514 (though, per
> the COMMENT section, this portion of the Introduction doesn't exist in a
> good form yet).
>
> Thank you for providing the BIER example, though -- it is helpful to see
> how the requirement plays out in practice!

Well, let me make a counter-proposal :-)

In section 2, I'd like to add the following text:

Use of the LIR-pF flag in a PTA whose tunnel type is not one of the
    types listed in Section 5 of [RFC6514] is outside the scope of this
    document.  Presumably, if an additional tunnel type is used, there
    will be a specification for how that tunnel type is used in MVPN.  If
    it is desired to use that tunnel type along with the LIR-pF flag,
    that specification will have to specify the rules for using the LIR-
    pF flag with that tunnel type.  As an example, see [BIER-MVPN].  In
    the absence of such a specification, the LIR-pF flag SHOULD NOT be
    set in a PTA that specifies that tunnel type, and its value SHOULD be
    ignored.

And for section 5.2:

o  If the tunnel type of the PTA attached to the match for tracking/
       reception is any other tunnel type, the rules for constructing the
       PTA of a Leaf A-D route that is originated in response to the
       LIR-pF flag are outside the scope of this document. Presumably
       there will be a specification for how that tunnel type is used in
       MVPN.  If it is desired to use that tunnel type along with the
       LIR-pF flag, that specification will have to specify the rules for
       constructing the PTA.  As an example, see [BIER-MVPN].  In the
       absence of such a specification, the LIR-pF flag in a PTA
       specifying that tunnel type SHOULD be ignored.

(The context will make it clear that "any other tunnel type" is "any 
tunnel type not mentioned in Section 5 of RFC 6514".)

And for section 6:

If L's PTA specifies a tunnel type not mentioned above, presumably
    there is a specification for how MVPN uses that tunnel type.  If the
    LIR-pF flag is to be used with that tunnel type, that specification
    must specify the actions that N is to take upon receiving L.  As an
    example, see [BIER-MVPN].  In the absence of such a specification,
    the LIR-pF flag SHOULD BE ignored.


(The context will make it clear that "a tunnel type not mentioned above" 
is "any tunnel type not mentioned in Section 5 of RFC 6514".)

I think that these passages address your issue.  If someone wants to use 
a new tunnel type with MVPN and they don't care about the LIR-pF flag, 
then they don't have to do anything, and the flag will be ignored.  If 
they do care about LIR-pF, then they'll look at this document and see 
just what they need to specify.

What do you think?

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 1
>
>     This document clarifies the procedures for originating and receiving
>     S-PMSI A-D routes and Leaf A-D routes.  This document also adds new
>     procedures to allow more efficient explicit tracking.  The procedures
>     being clarified and/or extended are discussed in multiple places in
>     the documents being updated.
>
> This is in effect saying to the reader, "you must read the updated
> document(s) in their entirety and decide for yourself whether a procedure
> being updated is described", which is perhaps not the most friendly thing
> to be doing.

Your point is well-taken, but unfortunately RFC 6514 is not organized in 
a manner  that makes it really feasible to point out each place that 
might be relevant.  If I tried to find every place in RFC 6514 that 
might be affected, I'd probably end up omitting a few, and that would 
introduce a bug into the document.

If someone is adding LIR-pF support to an existing implementation, this 
is not really a big problem, because they just have to find the places 
in their code where the S-PMSI and Leaf A-D routes are handled.

>
> Section 2
>
>     If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the LIR
>     flag of that PTA MUST also be set.
>
> What do I do if I receive a PTA in violation of the MUST?

I've change the above text to:

If the LIR-pF flag is set in the PTA of an S-PMSI A-D route, the
    originator of that route MUST also set the LIR flag.  If the PTA of a
    received wildcard S-PMSI A-D route has LIR-pF set but does not have
    LIR set, the receiver MUST log the fact that the flags appear to have
    been improperly set.  However, the route MUST then be processed
    normally (as if both flags were set), as specified in this document.

(The reason for setting both flags is that it helps you to detect the 
presence of an egress node that doesn't support LIR-pF.  But if a 
receiving node supports LIR-pF, it doesn't really matter if LIR is set 
or not, so there's no reason to do anything more than log the issue.)

>
>     Note that support for the LIR-pF flag is OPTIONAL.  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.  How this is known is
>     outside the scope of this document.
>
> Maybe remind us what a PE that doesn't support this flag will do if it
> happens to receive a PTA with it set?  (I see discussion below of the state
> at the ingress node in this case, but not an explicit confirmation of what
> egress nodes do.)

A PE that doesn't support the LIR-pF flag will just ignore it.  But it 
will respond to the LIR flag, and the response will enable the ingress 
node to determine that the egress node doesn't have LIR-pF support.  I 
think this is discussed in Section 2.

> It would also be nice to give non-normative examples of
> how a sender might know that receivers support the flag.

I've added the following text:

       (Typically, this means that the ability to set this flag would be
    controlled by a configuration knob, and operators should not set this
    knob unless they know that all the PEs support this feature.)

>
> Section 3
>
>     The rules for finding a "match for reception" in [RFC6625] are hereby
>     modified as follows:
>
> Maybe give a section reference too?  (Especially since 6625 does not use
> the abbreviated version we define here, and instead writes "Finding the
> Match for Data Reception".)

The immediately preceding paragraph begins:

Section 3.2 of [RFC6625] specifies a set of rules for finding the
    S-PMSI A-D route that is the "match for data reception" (or more
    simply, the "match for reception") of a given (C-S,C-G) or (C-*,C-G)
    state.

I think that provides what you're asking for?

>
>        For a given C-flow ((C-S,C-G) or (C-*,C-G)) the "match for
>        tracking" is chosen as follows.  Ignore any S-PMSI A-D route that
>        has no PTA.  Also ignore any S-PMSI A-D route whose PTA specifies
>        "no tunnel information present", but does not have either LIR or
>        LIR-pF set.  (That is, DO NOT ignore an S-PMSI A-D route that has
>
> I think this would be clearer as "and has neither LIR nor LIR-pF set" --
> the "but" can easily lead the reader astray.
>
>        a PTA specifying "no tunnel information present" unless its LIR
>        and LIR-pF bits are both clear).  [...]

Okay, I've made that change.

>
>        Note that the procedure for finding the match for tracking takes
>        into account S-PMSI A-D routes whose PTAs specify "no tunnel
>        information present" and that have either LIR or LIR-pf set.  The
>        procedure for finding the match for reception ignores such routes.
>
> Why are we talking about this like LIR and LIR-pF can be set independently,
> when just last page we said that if LIR-pF is set, LIR MUST be set?

So that things will still work if some ingress node sets LIR-pF but 
fails to set LIR.

>
> Section 4
>
> Please expand I-PMSI on first usage.

Done.

>
>         When following this procedure, the PTA of the S-PMSI A-D route
>         may specify a tunnel, or may specify "no tunnel information
>         present".  The choice between these two options is determined by
>         considerations that are outside the scope of this document.
>
> Could you give some examples of what sort of things might be involved in
> making that choice?

This really depends upon how the operator chooses to assign flows to 
tunnels.  That involves a whole bunch of inter-related considerations 
that really are not within the scope of this document.

>
> Section 5.3
>
>     Suppose the forwarded S-PMSI A-D route has a PTA specifying a tunnel,
>     and also has LIR-pF set.  [...]
>
> nit: is this this "route being forwarded" (i.e., where the ABR/ASBR acts as
> egress) or the "after forwarding route" (i.e., where the ABR/ASBR acts as
> ingress)?

Good catch!  We're talking here about the PTA as received, but that is 
not at all clear from the text.  I'll make some adjustments to make that 
clear.

>
>     As a result of propagating such an S-PMSI A-D route, the egress ABR/
>     ASBR may receive one or more Leaf A-D routes that correspond to that
>     S-PMSI A-D route.  [...]
>
> Just to check my understanding (no document change requested), this
> correspondance is determined by the NLRI in the Leaf A-D route matching the
> NLRI from the S-PMSI A-D route?

More precisely, the "route key" field from the Leaf A-D route's NLRI 
matches the NLRI from the S-PMSI A-D route.

>
>     The "global administrator" field of the modified RT will be set to
>     the IP address taken either from the S-PMSI A-D route's next hop
>     field ([RFC6514]), or from its Segmented P2MP Next Hop Extended
>     Community ([RFC7524]).
>
> How do I choose which one to use?

I'll add text stating that the address from the EC is used if the EC is 
present, otherwise the address from the next hop field is used.

>
> Section 6
>
>     then the action taken by N when it receives L is a local matter.  In
>     this case, the Leaf A-D route L provides N with explicit tracking
>     information for the flow identified by L's NLRI.  However, that
>     information is for management/monitoring purposes and does not have
>     an effect on the flow of multicast traffic.
>
> I would prefer to say "does not necessarily have an effect".

How about "does not have any direct effect on"?