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

[Loa Andersson <[e-mail]>]

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:[e-mail]] *On Behalf Of *Adrian Farrel
> *Sent:* Friday, August 14, 2015 7:02 AM
> *To:* 'Ross Callon'; [e-mail]
> *Cc:* [e-mail];
> [e-mail]
> *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:[e-mail]] *On Behalf Of *Ross Callon
> *Sent:* 03 August 2015 16:45
> *To:* [e-mail] <mailto:[e-mail]>
> *Cc:* [e-mail] <mailto:[e-mail]>;
> [e-mail]
> <mailto:[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 ([e-mail]
> <mailto:[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
>
>
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>