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
>