Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 17 August 2015 16:59 UTC

Return-Path: <gregory.mirsky@ericsson.com>
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 12A891A1A77 for <mpls@ietfa.amsl.com>; Mon, 17 Aug 2015 09:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level:
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 FUATdXY8cKbe for <mpls@ietfa.amsl.com>; Mon, 17 Aug 2015 09:59:00 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665DC1A1A28 for <mpls@ietf.org>; Mon, 17 Aug 2015 09:59:00 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-81-55d1a97050a4
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 71.1B.26730.079A1D55; Mon, 17 Aug 2015 11:29:20 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Mon, 17 Aug 2015 12:58:58 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Loa Andersson <loa@pi.nu>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Ross Callon' <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
Thread-Index: AQHQzgNUa/dgnD786kKbZmnl5u/dLp4L2qqAgAAw7mCABCFAgIAAUuBA
Date: Mon, 17 Aug 2015 16:58:57 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF112218A3C34@eusaamb103.ericsson.se>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB1430CED3726DFB4949F67074A5770@BY1PR0501MB1430.namprd05.prod.outlook.com> <095e01d0d699$da786cd0$8f694670$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF112218973FF@eusaamb103.ericsson.se> <55D194D3.5020209@pi.nu>
In-Reply-To: <55D194D3.5020209@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonRLdg5cVQgzVfFCx+9Nxgtphw6gGT xb+5c5gtvl9awmJxa+lKVou/K66wOLB5LFnyk8njetNVdo8Vm1cyesya3sbm8eXyZ7YA1igu m5TUnMyy1CJ9uwSujPalL5gLPnUyVvSdes7YwLg5qYuRk0NCwESi9+4VRghbTOLCvfVsXYxc HEICRxklHnZMZoVwljNKrNi1iA2kik3ASOLFxh52kISIwCRGiZkrZ4O1MAvsYJS4fXg2K0iV sECcxP2zHWBzRQTiJeZ/Wc0OYbtJXJzbCGazCKhKvNt+AMzmFfCVWHHzBAvEuuNMEoubFoAN 4gQqOjd9FROIzQh04PdTa8BsZgFxiVtP5jNBHC4gsWTPeWYIW1Ti5eN/rBC2osS+/unsEPU6 Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRWpxalptuZLiJ ERh1xyTYHHcwLvhkeYhRgINRiYc3YfqFUCHWxLLiytxDjNIcLErivNJ+eaFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGEPuPDj9+4Bzme8VtyrGZ6KeGgL69+Yzp07a1HP74pbd6S+17dby cOxX5/scv+bIv0cOqbenizLGB31h+cv8qW365lXMhx8VZT6zEXuw/cC0n6zpi8RS+B4aBVxT 31yr4pHMPff02/IJZitvP/xqNHHVC1W1i8pexYveTpiRI+29VLVgg8D2o1uUWIozEg21mIuK EwGGm2eMmwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/Xu8E4u8ioWmiwprvdQ87IGw5buM>
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 16:59:04 -0000

Hi Loa,
thank you for pointing to it. Will change the text accordingly.

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu] 
Sent: Monday, August 17, 2015 1:01 AM
To: Gregory Mirsky; adrian@olddog.co.uk; '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

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
>