Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
Loa Andersson <loa@pi.nu> Mon, 17 August 2015 08:01 UTC
Return-Path: <loa@pi.nu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8151A8756 for <mpls@ietfa.amsl.com>; Mon, 17 Aug 2015 01:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 nfRN_E7yHoqW for <mpls@ietfa.amsl.com>; Mon, 17 Aug 2015 01:01:30 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78E7D1A874A for <mpls@ietf.org>; Mon, 17 Aug 2015 01:01:29 -0700 (PDT)
Received: from [192.168.0.103] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 234391802B24; Mon, 17 Aug 2015 10:01:27 +0200 (CEST)
Message-ID: <55D194D3.5020209@pi.nu>
Date: Mon, 17 Aug 2015 10:01:23 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Ross Callon' <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB1430CED3726DFB4949F67074A5770@BY1PR0501MB1430.namprd05.prod.outlook.com> <095e01d0d699$da786cd0$8f694670$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF112218973FF@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF112218973FF@eusaamb103.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/aQKhrqFu-EJ-NwB-uuYVd5W6iFk>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org" <draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org>
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2015 08:01:38 -0000
Adrian and Greg, I'm a co-author of this document and agree with Greg that this a very good and most of it should be worked in the draft. However - a detail - we have converged on tLDP as the abbreviation for Targeted LDP, we should use that (not T-LDP). /Loa On 2015-08-14 23:01, Gregory Mirsky wrote: > Hi Adrian, > > thank you for your kind consideration, support of this work, the utmost > thorough review and invaluable comments. > > I’ll work on updating the document and will try to make new version > available by next Friday to address all comments received in WGLC. > > Regards, > > Greg > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Adrian Farrel > *Sent:* Friday, August 14, 2015 7:02 AM > *To:* 'Ross Callon'; mpls@ietf.org > *Cc:* mpls-chairs@tools.ietf.org; > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org > *Subject:* Re: [mpls] working group last call for > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10 > > Hi Ross, > > Thanks for pursuing this to get proper review, and thanks to those who > have reviewed and commented. > > In addition to their comments I have the following observations. I don't > believe any of them says "this is a bad idea, do not publish", but I > think some polish is needed on the draft. > > Many thanks to the authors for their work, > > Adrian > > === > > I think there are a few abbreviations that the RFC Editor will ask you to > > expand. You might as well handle these at the same time as any update > > resulting from last call. > > I see... > > Abstract > > - LSP > > Main text > > - LSP > > - NMS > > - T-LDP > > - RSVP-TE (curiously RSVP is allowed, so you can say "RSVP Traffic > > Engineering (RSVP-TE)" > > - Tx and Rx (I think you might as well just write these in full) > > --- > > Para 3 of the Intro has > >> MPLS Transport Profile (MPLS-TP) > > but this is not the first use of the abbreviation. Move it up to the > > first para? > > Actually, maybe move the third paragraph to be the first para? > > --- > > 2.1.2 has > > To customize the configuration one would set the > > respective flags in the including the respective Loss and/or Delay > > sub-TLVs). > > Doesn't parse. > > ...flags in the MPLS OAM Functions TLV and including... ? > > --- > > 2.1.3 > > s/Corresponding Server MEP needs/The corresponding Server MEP needs/ > > --- > > 2.2 needs to explain: > > - The absence of the MPLS OAM Functions TLV is equivalent to the TLV > > being present with all bits set to zero > > - If more than one MPLS OAM Functions TLV is present, what will the > > receiver do? Options are: > > - Process the first and ignore subsequent instances > > - Reject the message > > - Crash > > - What happens if a bit that is unknown is set? > > Are you sure you don't want IANA to track the MPLS OAM Functions Flags? > > This is different from the flags fields in the sub-TLVs that are > > specific to particular OAM tools because in this case new OAM mechanisms > > may show up requesting configuration. > > You have... > > Length: the length of the MPLS OAM Function Flags field including the > > total length of the sub-TLVs in octets. > > MPLS OAM Function Flags: a bitmap numbered from left to right as > > shown in the figure. > > Of course, the figure doesn't show an "MPLS OAM Function Flags" field. > > This could be resolved by fixing the figure where the individual bits > > don't need to be named, and by fixing the table to show MBZ for the > > reserved bits. > > Furthermore, it's a little unclear in 2.2 what the correlation is > > between the bit flags and the sub-TLVs. > > - Can a TLV be present if the "corresponding" is clear? > > - If the corresponding bit is set, must the sub-TLV be present? > > - And, of course, there are fewer sub-TLVs than bits. > > I think you need to tidy up by adding text. > > This leaves 2.2 looking like... > > 2.2. MPLS OAM Functions TLV > > The MPLS OAM Functions TLV presented in Figure 1 is carried as a TLV > > of the MPLS Echo Request/Reply messages [RFC4379]. If the TLV is > > absent is as though it were present with all bits clear (zero) and no > > sub-TLVs present. If the TLV is present more than once the first > > instance MUST be processed and subsequent instances MUST be ignored. > > The MPLS OAM Functions TLV contains a number of flags indicating > > which OAM functions should be activated as well as OAM function > > specific sub-TLVs with configuration parameters for the particular > > function. > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MPLS OAM Func. Type (TBA1) | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MPLS OAM Function Flags | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ sub-TLVs ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: MPLS OAM Functions TLV format > > Type: indicates the MPLS OAM Functions TLV Section 4. > > Length: the length of the MPLS OAM Function Flags field including the > > total length of the sub-TLVs in octets, but excluding the length of > > the Type and Length fields of the MPLS OAM Functions TLV. > > MPLS OAM Function Flags: a bitmap numbered from left to right. These > > flags are managed by IANA. Those defined in this document as > > presented in Table 1 in Section 4. Undefined flags MUST be set to > > zero and unknown flags MUST be ignored. The flags indicate what > > OAM is being configured and direct the presence of sub-TLVs as set > > out below. > > Sub-TLVs corresponding to the different flags are as follows: > > - BFD Configuration sub-TLV MUST be included if either the CC, the > > CV or, both MPLS OAM Function flags are set in the MPLS OAM > > Functions TLV. > > - Performance Monitoring sub-TLV MAY be present to carry any of > > the following sub-TLVs. In none of these sub-TLVs is present > > then the Performance Monitoring sub-TLV is not included (that > > is, an empty Performance Monitoring sub-TLV is not used). > > - PM Loss sub-TLV MAY be included in the Performance Monitoring > > sub-TLV if the PM/Loss OAM Function flag is set. If the PM > > Loss sub-TLV is not included, default configuration values are > > used. This sub-TLV MAY also be included if the Throughput > > Measurement OAM Function flag is set and there is the need to > > specify a measurement interval different from the default one. > > In fact throughput measurement makes use of the same tools as > > loss measurement which is why the same sub-TLV is used. If > > the PM/Loss OAM Function flag and the Throughput Measurement > > OAM Function flag are both set, only at most one instance of > > the PM Loss sub-TLV is used. > > - PM Delay sub-TLV MAY be included in the Performance Monitoring > > sub-TLV if the PM/Delay OAM Function flag is set. If the PM > > Delay sub-TLV is not included, default configuration values > > are used. > > - FMS sub-TLV MAY be included if the FMS OAM Function flag is set. > > If the "FMS sub-TLV" is not included, default configuration > > values are used. > > If any sub-TLV is present without the corresponding flag being set, > > the sub-TLV SHOULD be ignored. If any sub-TLV that is required > > according to the setting of the corresponding bit is absent or if > > there is any parsing error within nested sub-TLVs this SHOULD be > > treated as an encoding error as described in [RFC4379]. > > Then, in Section 4 you can add... > > IANA maintains the Multi-Protocol Label Switching (MPLS) Label > > Switched Paths (LSPs) Ping Parameters registry. IANA is requested to > > create a new registry called the "MPLS OAM Functions Flags" registry > > and to populate it as follows. > > +------------+--------------------+---------------------------------+ > > | Bit | MPLS OAM Function | Description | > > | Position | Flag | | > > +------------+--------------------+---------------------------------+ > > | 0 | C | Continuity Check (CC) | > > | 1 | V | Connectivity Verification (CV) | > > | 2 | F | Fault Management Signal (FMS) | > > | 3 | L | Performance Measurement/Loss | > > | | | (PM/Loss) | > > | 4 | D | Performance Measurement/Delay | > > | | | (PM/Delay) | > > | 5 | T | Throughput Measurement | > > | 6-31 | | Unassigned (Must be zero) | > > +------------+--------------------+---------------------------------+ > > Table 1: MPLS OAM Functions Flags > > New flags are to be assigned by IETF Review [RFC5226]. > > --- > > Are there any ordering implications for the sub-TLVs in section 2.2? > > --- > > 2.2.1 > > Length: indicates the length of the Value field in octets (4). > > Are you sure that the lengths of the sub-TLVs are not included? > > --- > > 2.2.1 > > BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD > > Control Messages is enabled, when cleared it is disabled. > > It would be useful to add to read... > > BFD Negotiation (N): If set timer negotiation/re-negotiation via BFD > > Control Messages is enabled, when cleared it is disabled and timer > > configuration is achieved using Negotiation Timer Parameters sub-TLV > > as described in Section 2.2.3. > > --- > > 2.2.1 > > Symmetric session (S): If set the BFD session MUST use symmetric > > timing values. > > and > > Integrity (I): If set BFD Authentication MUST be enabled. > > If clear is it MUST NOT, or MAY use the appropriate functions? > > --- > > 2.2.2 > > Local Discriminator: A unique, nonzero discriminator value generated > > by the transmitting system and referring to itself, used to > > demultiplex multiple BFD sessions between the same pair of systems. > > I presume this is "unique" in the context of the transmitting system. > > The phrase "and referring to itself" is unclear. So it might read better > > as... > > Local Discriminator: A nonzero discriminator value that is unique in > > context of the transmitting system that generates it. It is used to > > demultiplex multiple BFD sessions between the same pair of systems. > > --- > > 2.2.3 > > Acceptable Min. Asynchronous intervals: Are the values zero disallowed? > > --- > > 2.2.4 > > If BFD Authentication sub-TLV used for a BFD session in Up state then > > the Sender of the MPLS LSP Echo Request SHOULD ensure that old and > > new modes of authentication, i.e. combination of Auth.Type and Auth. > > Key ID, used to send and receive BFD control packets until the Sender > > can confirm that its peer had switched to the new authentication. > > Under what circumstances would an implementation vary this SHOULD and > > what would be the effect? > > --- > > 2.2.5 > > The Traffic Class sub-TLV is carried as a sub-TLV of the "BFD > > Configuration sub-TLV" or "Fault Management Signal sub-TLV" > > Section 2.2.9 and is depicted in Figure 6. > > This is ambiguous since "or" could be read to be exclusive. How about > > using "and"? > > --- > > 2.2.5 > > If TC sub-TLV is present, then the value of the TC field MUST be used > > as the value of the TC field of an MPLS label stack entry. > > Maybe I am missing something, but I couldn't work out which LSE on which > > packet you are referring to. And it isn't even clear whether you mean to > > copy the value from the packet to this field, or from this field to the > > packet. > > Ditto the end of 2.2.9 which is a bit clearer but still not clear as to > > which LSE is being talked about. > > --- > > 2.2.6 > > If the MPLS OAM Functions TLV has either the L (Loss), D (Delay) or T > > (Throughput) flag set, the Performance Measurement sub-TLV MUST be > > present. > > I think you mean... > > If the MPLS OAM Functions TLV has any of the L (Loss), D (Delay), and > > T (Throughput) flags set, the Performance Measurement sub-TLV MUST be > > present. > > --- > > 2.2.6 > > Shouldn't Figure 7 show the optional sub-TLVs, and shouldn't the Length > > field include the lengths of those sub-TLVs? > > --- > > 2.2.9 > > When both working and protection > > paths are configured, both LSPs SHOULD be configured with identical > > settings of the E flag, T flag, and the refresh timer. > > This implies there are reasons (and mechanisms) to vary the > > configuration. You should explain them. > > --- > > 2.2.9 > > Length: indicates the length of the Value field in octets (4). > > Surely the length includes the sub-TLVs as well. > > --- > > Section 6 > > You called out the attack I was thinking of. That is, by either changing > > the signaled configuration, injecting configuration packets, or by being > > an evil (or fat-fingered or misguided) sender of configuration, it is > > possible to degrade a node. > > You need to say what the protection is. > > This may be as simple as a node paying attention to its loading and > > refusing new OAM configurations that would take it close to the edge. > > But this approach creates an interesting new vector since, by loading > > one set of LSPs I may be able to prevent you running OAM on another set. > > --- > > Section 6 > > Additionally, shouldn't you talk about the configuration of security > > mechanisms that exist for the OAM tools you are configuring? > > *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Ross Callon > *Sent:* 03 August 2015 16:45 > *To:* mpls@ietf.org <mailto:mpls@ietf.org> > *Cc:* mpls-chairs@tools.ietf.org <mailto:mpls-chairs@tools.ietf.org>; > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org > <mailto:draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org> > *Subject:* [mpls] working group last call for > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10 > > Working Group, > > This is to initiate a two week working group last call on > draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10. > > Please send your comments to the mpls wg mailing list (mpls@ietf.org > <mailto:mpls@ietf.org>). > > There are no IPR disclosures against this document. All the authors have > stated that they > > are not aware of any IPR that relates to this draft (two of the > responses were private to > > the WG chairs). > > This working group last call ends Tuesday August 18, 2015. > > The previous WGLC for this document failed due to a lack of response, > even though there were > > no objections. I will remind the working group that for a WGLC a lack of > response does not imply > > support; rather a lack of response implies either no opinion or a > failure to read the document. As > > with any WGLC, working group participants are requested to read the > document and comment, > > and if you feel that the document is ready for publication it is > appropriate to respond to any WGLC > > with a short and simple email indicating support. > > Ross > > for the MPLS WG chairs > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Hejia (Jia)
- Re: [mpls] working group last call for draft-ietf… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Nobo Akiya
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- [mpls] working group last call for draft-ietf-mpl… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Nobo Akiya
- [mpls] working group last call for draft-ietf-mpl… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Andrew G. Malis
- [mpls] working group last call for draft-ietf-mpl… Jeff Tantsura
- Re: [mpls] working group last call for draft-ietf… Eric Gray
- Re: [mpls] working group last call for draft-ietf… Zhangxian (Xian)
- Re: [mpls] working group last call for draft-ietf… Uma Chunduri
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Loa Andersson
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Ross Callon
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky
- Re: [mpls] working group last call for draft-ietf… Adrian Farrel
- Re: [mpls] working group last call for draft-ietf… Gregory Mirsky