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

["Adrian Farrel" <[e-mail]>]

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:[e-mail]] On Behalf Of Ross Callon
Sent: 03 August 2015 16:45
To: [e-mail]
Cc: [e-mail];
[e-mail]
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 ( <mailto:[e-mail]>
[e-mail]).
 
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