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

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 19 August 2015 01:23 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 B21271A7002 for <mpls@ietfa.amsl.com>; Tue, 18 Aug 2015 18:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.642
X-Spam-Level:
X-Spam-Status: No, score=-101.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 lUqchutsIv-f for <mpls@ietfa.amsl.com>; Tue, 18 Aug 2015 18:22:54 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59701A7005 for <mpls@ietf.org>; Tue, 18 Aug 2015 18:22:53 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-0d-55d37d1899c2
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id DE.B6.32596.81D73D55; Tue, 18 Aug 2015 20:44:41 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Tue, 18 Aug 2015 21:22:51 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "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/dLp4L2qqAgATTkqA=
Date: Wed, 19 Aug 2015 01:22:50 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF112218A8B04@eusaamb103.ericsson.se>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB1430CED3726DFB4949F67074A5770@BY1PR0501MB1430.namprd05.prod.outlook.com> <095e01d0d699$da786cd0$8f694670$@olddog.co.uk>
In-Reply-To: <095e01d0d699$da786cd0$8f694670$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/mixed; boundary="_005_7347100B5761DC41A166AC17F22DF112218A8B04eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZXLonSley9nKowblLlhY/em4wW0w49YDJ 4vulJSwWt5auZLX4u+IKiwOrx5IlP5k8rjddZfdYsXklo8eXy5/ZAliiuGxSUnMyy1KL9O0S uDIuLtrFVrBullrFguO97A2Ms26rdDFyckgImEi8m3WGDcIWk7hwbz2QzcUhJHCUUWLmg4Os EM5yRonzqx6yglSxCRhJvNjYww5iiwiUS7zYvI4ZpIhZYAejxO3Ds8GKhAXiJO6f7WCEKIqX mP9lNVSDlcSaIyvB1rEIqEr0X9nGDGLzCvhKfJzQzQKx7QWjRPvXs2DNnALWEof3XgdrYAS6 7/upNUwgNrOAuMStJ/OZIO4WkXh48TTUD6ISLx//Y4WwlSQmLT0HZHMA1WdKvFwqDrFLUOLk zCcsExhFZyGZNAuhahaSKoiSfIlNL3YyQdg6Egt2f2KDsLUlli18zQxjnznwmAlVHBQskxgl pvz/xwrhtDJK3FuzmBHCmcgkcXzpD6hRihJTuh+yQ9jREkf/noGKu0q03//BAtFwkVFidtcG FA0LGAVWMXKUFqeW5aYbGWxiBCabYxJsujsY97y0PMQowMGoxMO7oOhyqBBrYllxZe4hRmkO FiVxXseovFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjCIGE289yliUvqXq7ZzwhNpKwd9W M4V7TBIYezynbq+yL2Hs6ZucMke4f9bOowdz33GzNJkqna9k3PR07u9evbhj7u9nGjtW//P6 NuPRqlvfbt1Xlr2willla3f6zrb5865M3SYbeTUu48O6+GdntUUOM3Us/LBHR2cem2jSAyOV uRmP6xXd8pRYijMSDbWYi4oTAUnZcPQXAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/wG_AOfnKnfOaCqSbo39wnQ44xWc>
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: Wed, 19 Aug 2015 01:23:10 -0000

Hi Adrian,
your help cannot be overvalued.
Please find my responses to your comments, notes in-lined and tagged GIM>>.
Attached are diffs of -10 and candidate for -11 as well -11 version (it may be useful for comments).

                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
GIM>> There's just one occasion and thus abbreviation is not needed at all.

- 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)
GIM>> Agreed.

---

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?

GIM>> Agreed and moved OAM expansion accordingly.
---

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...    ?
GIM>> Yes, thank you
---

2.1.3

s/Corresponding Server MEP needs/The corresponding Server MEP needs/
GIM>> Done
---

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?
GIM>> Must be treated as error
- If the corresponding bit is set, must the sub-TLV be present?
GIM>> Not necessarily. Setting only bit flag MUST configure corresponding OAM in its default setting (whatever it is). Sub-TLVs MAY be used to overwrite default OAM configuration.
- And, of course, there are fewer sub-TLVs than bits.
GIM>> CC and CV share BFD and thus one sub-TLV.

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].

GIM>> Many thanks, Adrian. I've followed your recommendations with minor changes. Please check the attached diff.
---

Are there any ordering implications for the sub-TLVs in section 2.2?
GIM>> No, should be order independent.
---

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?
GIM>> Great catch! Removed 4.
---

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.
GIM>> Agreed and incorporated.
---

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?
GIM>> I think it is MAY for Symmetric and MSUT NOT for the Integrity.
---

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.
GIM>> Agree
---

2.2.3

Acceptable Min. Asynchronous intervals: Are the values zero disallowed?
GIM>> Theoretically it is not disallowed and may be used to have uni-directional BFD session. But I agree, it is unlikely to be set to 0.
---

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?
GIM>> For example,  AdminDown MAY be used to perform transition from old to new mode of authentication and verify that new is operational.

---

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"?
GIM>> Agree
---

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.
GIM>> We're trying to control TC for E-LSP so that state of the single BFD session be used to infer state of all CoS. Would the following improves the clarity:
If TC sub-TLV is present, then value of the TC field MUST be used
as the value of the TC field of the MPLS label stack that corresponds
to the FEC for which fault detection is being performed.
---

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.
GIM>> Yes, thank you, Adrian.
---

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?
GIM>> Expanded figure and removed '4' from Length.
---

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.
GIM>> Removed '4'
---

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?
GIM>> Would references to respective sections in RFC 5880, 5884, 6374, 6375, 6427 and 6428 be sufficient?

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