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

Benjamin Kaduk <kaduk@mit.edu> Thu, 29 November 2018 22:09 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57B2126DBF; Thu, 29 Nov 2018 14:09:04 -0800 (PST)
X-Quarantine-ID: <0y9liY5pqazf>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y9liY5pqazf; Thu, 29 Nov 2018 14:09:02 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422D41274D0; Thu, 29 Nov 2018 14:09:01 -0800 (PST)
X-AuditID: 12074423-9abff7000000031c-fc-5c0063799609
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 49.F9.00796.A73600C5; Thu, 29 Nov 2018 17:08:59 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.14.7/8.9.2) with ESMTP id wATM8qVE023090; Thu, 29 Nov 2018 17:08:53 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wATM8lCF004993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Nov 2018 17:08:50 -0500
Date: Thu, 29 Nov 2018 16:08:47 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rosen <erosen@juniper.net>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bess-mvpn-expl-track@ietf.org" <draft-ietf-bess-mvpn-expl-track@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "bess@ietf.org" <bess@ietf.org>
Message-ID: <20181129220847.GY10033@kduck.kaduk.org>
References: <154025886476.13484.16270011990649784514.idtracker@ietfa.amsl.com> <af80f9ab-6c1e-b8d7-b6fd-e32d4f6ae9e9@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <af80f9ab-6c1e-b8d7-b6fd-e32d4f6ae9e9@juniper.net>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nrludzBBjMHkCi8XOi3+YLVYcn8ls ceDMdkaLdRs+MFvM+DOR2eLr3oesDmweS5b8ZPK43nSV3aPl2Um2AOYoLpuU1JzMstQifbsE roxTb+MKPqVWLL/yiLGB8YBvFyMnh4SAiUR3yw6WLkYuDiGBNUwS79eeZYNwNjJK/L7xhxGk SkjgLpNE58daEJtFQFXi4rdudhCbTUBFoqH7MjOILSKgLNG8aCUzSDOzwAomielTXoAVCQtk Ssx8fwasiBdo3a/zz6DWNTNKLDnSwgSREJQ4OfMJC4jNLKAjsXPrHaAzOIBsaYnl/zggwvIS zVtng83hFLCX6H03H6xVFGjx3r5D7BMYBWchmTQLyaRZCJNmIZm0gJFlFaNsSm6Vbm5iZk5x arJucXJiXl5qka6ZXm5miV5qSukmRnAkuCjvYHzZ532IUYCDUYmH1+HX/2gh1sSy4srcQ4yS HExKorzW+gwxQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR47RWAcrwpiZVVqUX5MClpDhYlcd4/ Io+jhQTSE0tSs1NTC1KLYLIyHBxKErybkoAaBYtS01Mr0jJzShDSTBycIMN5gIZvB6nhLS5I zC3OTIfIn2LU5Xgz98cMZiGWvPy8VClxXh6QIgGQoozSPLg5oAQmkb2/5hWjONBbwrzawHQm xANMfnCTXgEtYQJaEtMD9DBvcUkiQkqqgZF33vPNCkbnZq4yU7A++ezaaa4Fco9qxVi4LS5p vzESP/JYW8lu3+W2S6e/Hw7781GVbfkf+/dd0fXKuhOvyO7YHF3Bbt79eusXjU+uL9zWrV7t UsdfbXN37w8tlmVR9svYcsx8GmS91Tfy7Du6Jt7f9Nr3cu6HTRXV3aI/D8dMdXvz4VW/pLAS S3FGoqEWc1FxIgCDzZVVOwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/7vCtuv-6bd417rk0phgPPiiBjXQ>
Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Nov 2018 22:09:05 -0000

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