Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Eric Rosen <erosen@juniper.net> Thu, 15 November 2018 19:43 UTC
Return-Path: <erosen@juniper.net>
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 D6B70128D09; Thu, 15 Nov 2018 11:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level:
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 LajADF1n8260; Thu, 15 Nov 2018 11:43:35 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 51ED9127333; Thu, 15 Nov 2018 11:43:35 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAFJcs5B001806; Thu, 15 Nov 2018 11:43:34 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=F2n1ewdMvMJJ140jHuXEex2s85sES5W6XQ2zJlKfKVQ=; b=jd5lQ570FngKzhPYn6ZJwCgi9wWZoXI1A7lbqpL9rFOLeCEwzUMwGfVpmTWOEeATt4cw FNtA21E7+L03XgW6Qz9b5kKCW585qgDx6er8yDpAl5+7wMe6hEVQi5t/XiYq6/zYClE6 abi4U6xfyJI+pLZi84qflONuHocWdEcyntZjR+53lhA51yYtln/ZbEgh+dZ8l5JLMbna A7Oe7CLi+OePnYA5gQCHjcIjeQfNjO9hZuIWDY293/9ARvULCFhHqqwX+uql+vYgkPhF ObdRHXm+5CprsIEO4ia+e2SnjG871R09PNz3czXu3ppHhwegfH2fvJbma9PLMCGmpjUL yQ==
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0184.outbound.protection.outlook.com [216.32.181.184]) by mx0b-00273201.pphosted.com with ESMTP id 2nscqe89aa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 11:43:34 -0800
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com (10.167.108.27) by DM5PR0501MB3782.namprd05.prod.outlook.com (10.167.107.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.7; Thu, 15 Nov 2018 19:43:31 +0000
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf]) by DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf%5]) with mapi id 15.20.1339.019; Thu, 15 Nov 2018 19:43:31 +0000
From: Eric Rosen <erosen@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "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>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Thread-Index: AQHUanF8u9nWhF9SpU2HM1tVd+wZTaVRYhGA
Date: Thu, 15 Nov 2018 19:43:31 +0000
Message-ID: <af80f9ab-6c1e-b8d7-b6fd-e32d4f6ae9e9@juniper.net>
References: <154025886476.13484.16270011990649784514.idtracker@ietfa.amsl.com>
In-Reply-To: <154025886476.13484.16270011990649784514.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR07CA0059.namprd07.prod.outlook.com (2603:10b6:a03:60::36) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3782; 6:jW1HptTl0Huig2307pf+zUNVlyYzCtg/rTzmWNu4s7fzaCTQTudLxrs+1TQQqIieAWL3/Nbl9z4mV3RlnzftMIy0RZMw3wjP4v/5QeKWTQe+vtQEEdwJZeWrnOHFMoroKqqYANuF3LwEaxWeJ2WDPZEpYCVAzQ+/89HCBfcGMiKxV4ORm8Q4OuAwm/rHsmt82a/TevCY18lbu7iNkNNGhyTfQonKHliTMTI/l1JelHBHJgCq4jGBOZIpgJWbI4fk5tpD+sjrXpfYCwUI4dHeBzjPHnOR3hN2IkoeHRqUTFHn/MSa59Njtqqd5Q4Ht05p7rSQNkNFmpt4mHYwR3uZSTxsGNQRt02cP/+joV4oOa/BF2Ku+GWyDcySSwjBojbXSR1JDZoMoTtPwP8qpbuhUra6IDWADplNb7ueTcfxq6k5VVehnHuCGKTsK8MaP/oZFbL3D5eyk2fLmNUd/KI11Q==; 5:zgMAedFhxwfngNQmWQoFXLb5xXxkbn49HKOHdpVC8/nOaB3Sx8yZNvh3GeBlbnZ/LOLoSe5i61UJvN7BX8akyDkIW63k/WaxWfCYOywSxlcBPn+WYHAaU2EdlzYukVvgSOSRmiFDYB0Hoj2Ok0dV+HefJbvzWh2FTjtLa+lso+I=; 7:q5w1smm29+WPWE3mClGPnKM2dl6alwVjrpr+9bwu26VufQF26ljA6dbCDlI1qI9nCms3atx3a80jCSCElwe193YXQnw7GBOgx8N4KU1kjOMWjz1jNAJrjgI/Ba//MNC4XB1n9JkyL9TMhfDXH2Ufmg==
x-ms-office365-filtering-correlation-id: 29a7a3a4-d96d-4d4a-cc9e-08d64b329f56
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM5PR0501MB3782;
x-ms-traffictypediagnostic: DM5PR0501MB3782:
x-microsoft-antispam-prvs: <DM5PR0501MB37821916902272769F669B75D4DC0@DM5PR0501MB3782.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231415)(944501410)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM5PR0501MB3782; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3782;
x-forefront-prvs: 08572BD77F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(396003)(346002)(136003)(376002)(39860400002)(366004)(199004)(60444003)(51444003)(189003)(186003)(102836004)(2171002)(26005)(305945005)(97736004)(561944003)(31696002)(99286004)(68736007)(6436002)(36756003)(6506007)(53546011)(52116002)(76176011)(8676002)(6246003)(106356001)(386003)(5660300001)(105586002)(4326008)(8936002)(81156014)(86362001)(7736002)(6512007)(31686004)(345774005)(81166006)(71190400001)(2900100001)(6486002)(71200400001)(66066001)(53936002)(25786009)(14454004)(14444005)(478600001)(256004)(110136005)(5024004)(2906002)(3846002)(316002)(6116002)(4744004)(2616005)(11346002)(229853002)(476003)(446003)(486006)(54906003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3782; H:DM5PR0501MB3864.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: uf4Mw6NGB6S+7a0WgoqrFiapHDSe/ehJDmMgcYHL2ATKLYp4byrAy2EIEcDfyRKeY1vd50Fpr4LaGitvHAAq8Gv7ewqWpkakUNc1LnLYzCxR5ABH/Dwu5fG/KAaPvz2iqty1WOzDV/RExn1fTSqJvgl1J5e1hb1DWd1pLeSJ533JachjrMqx/B1F6K/1oaXMTHo09REXFdUUqXrrtHBtbNUOfHjpDdq8Xh5E6gUNc3xDySuvUJyhL/24znAsiOL/hTL3+NrGoNw6h+7l66i1d8j7MPmdeLeXYhy+phPntiytS9smMfQuBYE1Z/Qu+WOR0AC6SA+dGouxiiLGJPMTmaetCJN+MIzHS6u864GdMd8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <D00C7378F16ECF41BB1283589DE3F25F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 29a7a3a4-d96d-4d4a-cc9e-08d64b329f56
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2018 19:43:31.7850 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3782
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_14:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811150170
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Dz3WTsQkWMHESFgxzWbtHf8kX_0>
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, 15 Nov 2018 19:43:38 -0000
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"?
- [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