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

[Benjamin Kaduk <[e-mail]>]

Hi Eric,

Sorry for the slow response -- the timing of when this came in interacted
poorly with my travel/vacation schedule.

On Thu, Nov 15, 2018 at 07:43:31PM +0000, Eric Rosen wrote:
> 
> 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?

That's a fine counter-proposal; I've updated my ballot position accordingly
(but we may need more discussion about the Updates: 7582 7900 headers).

I also appreciate the discussion and updates with regards to my comments
below, and I don't have any additional comments about them.

Thanks again!

-Benjamin

> >
> >
> > ----------------------------------------------------------------------
> > 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"?
> 
> 
>