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"? > > >
- [bess] Benjamin Kaduk's Discuss on draft-ietf-bes… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Eric Rosen
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Eric Rosen
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk