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

From: Ross Callon <[email-masked]>
Date: Mon, 3 Aug 2015 15:44:36 +0000

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 ([email-masked]<mailto:[email-masked]>).

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 4 Aug 2015 08:14:40 -0400

Ross,

I've read the draft, and I agree with the authors that it is ready for
publication. It's been improved since the previous WG LC. My only comment
is that the reference to draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext should be
updated to RFC 7487, which is something the RFC Editor would do anyway.

Thanks,
Andy

On Mon, Aug 3, 2015 at 11:44 AM, Ross Callon <[email-masked]> wrote:

> 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 ([email-masked]).
>
>
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 4 Aug 2015 15:42:29 +0000

Yes/support

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, August 03, 2015 8:45 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

Working Group,

Ross
for the MPLS WG chairs

---

From: Eric Gray <[email-masked]>
Date: Wed, 5 Aug 2015 22:32:30 +0000

I have read the draft and feel that it is ready for submission.

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Monday, August 03, 2015 11:45 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

Working Group,

Ross
for the MPLS WG chairs

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Thu, 6 Aug 2015 09:13:39 +0000

I have just reviewed this draft and believe it is ready for publication.

Regards,
Xian

Sent: 2015年8月3日 23:45

Working Group,

Ross
for the MPLS WG chairs

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 6 Aug 2015 17:13:05 +0000

Support.

--
Uma C.

Working Group,

Ross
for the MPLS WG chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 14 Aug 2015 15:02:13 +0100

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:[email-masked]] On Behalf Of Ross Callon
Sent: 03 August 2015 16:45
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
 
Working Group,

Please send your comments to the mpls wg mailing list ( <mailto:[email-masked]>
[email-masked]).
 
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).

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

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 14 Aug 2015 21:01:11 +0000

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:[email-masked]] On Behalf Of Adrian Farrel
Sent: Friday, August 14, 2015 7:02 AM
To: 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
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.

===

I see...
Abstract
- LSP
Main text
- LSP
- NMS
- T-LDP

---

Para 3 of the Intro has

---

2.1.2 has

Doesn't parse.

---

2.1.3

---

2.2 needs to explain:

You have...

    0                   1                   2                   3

---

---

2.2.1

---

2.2.1

---

2.2.1

and

---

2.2.2

---

2.2.3

---

2.2.4

---

2.2.5

---

2.2.5

---

2.2.6

I think you mean...

---

2.2.6

---

2.2.9

---

2.2.9

---

Section 6

---

Section 6

Working Group,

Ross
for the MPLS WG chairs

---

From: Loa Andersson <[email-masked]>
Date: Mon, 17 Aug 2015 10:01:23 +0200

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:
> 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:[email-masked]] *On Behalf Of *Adrian Farrel
> *Sent:* Friday, August 14, 2015 7:02 AM
> *To:* 'Ross Callon'; [email-masked]
> *Cc:* [email-masked];
> *Subject:* Re: [mpls] working group last call for
> 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.
>
> *From:*mpls [mailto:[email-masked]] *On Behalf Of *Ross Callon
> *Sent:* 03 August 2015 16:45
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>;
> <mailto:[email-masked]>
> *Subject:* [mpls] working group last call for

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 17 Aug 2015 16:58:57 +0000

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

	Regards,
		Greg

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Monday, August 17, 2015 1:01 AM
To: Gregory Mirsky; [email-masked]; 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
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 
> 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.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 19 Aug 2015 01:22:50 +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

Hi Ross,

===

I see...
Abstract
- LSP
Main text
- LSP
- NMS
- T-LDP
GIM>> There's just one occasion and thus abbreviation is not needed at all.

GIM>> Agreed.

---

Para 3 of the Intro has

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

2.1.2 has

Doesn't parse.

GIM>> Yes, thank you
---

2.1.3

GIM>> Done
---

2.2 needs to explain:

You have...

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

    0                   1                   2                   3

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

Are you sure that the lengths of the sub-TLVs are not included?
GIM>> Great catch! Removed 4.
---

2.2.1

GIM>> Agreed and incorporated.
---

2.2.1

and

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

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

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

GIM>> Agree
---

2.2.5

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

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

---

2.2.9

GIM>> Removed '4'
---

Section 6

---

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?

Working Group,

Ross
for the MPLS WG chairs

---

From: Ross Callon <[email-masked]>
Date: Wed, 19 Aug 2015 18:50:36 +0000

This working group last call has now been completed, with sufficient support and with no opposition. However, there were some comments received. I also see that the authors have already worked on producing an update to address the comments.

Authors, when you are ready please post the updated draft to address the comments received, and then I will proceed with submitting the document for publication.

Thanks, Ross
(as MPLS wg co-chair)

Working Group,

Ross
for the MPLS WG chairs

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 Aug 2015 16:36:15 +0100

Hi Greg,

I've not checked that you implemented the changes you said you would in your
email. No reason not to trust you.

[Major snipping]

> GIM>> No, should be order independent.

OK. Maybe...
OLD
   Sub-TLVs corresponding to the different flags are as follows:
NEW
   Sub-TLVs corresponding to the different flags are as follows. No 
   meaning should be attached to the order of sub-TLVs.
END

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

Well, yes, "unlikely".
I suppose there is no reason to prevent setting zero unless you would find
reserved value useful.

> GIM>> For example,  AdminDown MAY be used to perform transition from
> old to new mode of authentication and verify that new is operational.

Silly me. I should have said, "Please explain in the document..." :-)

You really need to add and complete the following sentence...

An implementation MAY change the mode of authentication mode sooner if...

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

Nearly there...

If the TC sub-TLV is present, then the sender of any data packets on the LSP
with a FEC that corresponds to the FEC for which fault detection is being
performed MUST use the value contained in the TC field of the sub-TLV as the
value of the TC field in the top label stack entry of the MPLS label stack.

>> configuration. You should explain them.

Missing an answer?
Change SHOULD to MUST or add: "An implementation MAY configure the working and
protection LSPs with different settings of these fields if..."

> 6374, 6375, 6427 and 6428 be sufficient?

The para with these simple references that you've added is OK, but I think you
are missing discussion of how these security aspects are configured. If we are
dealing with the configuration of OAM then we should deal with the configuration
of OAM security.

However, you may be wanting to say...

In order that the configuration of OAM function can be achieved securely through
the techniques described in this document, security mechanisms must already be
in place and operational for LSP Ping. Thus the exchange of security parameters
(such as keys) for use in securing OAM is outside the scope of this document and
is assumed to use an off-line mechanism or an established secure key-exchange
protocol.

You have a spelling mistake: "extenssions"

Ciao,
Adrian

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 24 Aug 2015 18:22:15 +0000

Hi Adrian,
apologies for missed comments. I've used green to colour my responses with the same tag GIM>>.

        Regards,
                Greg

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Sunday, August 23, 2015 8:36 AM
To: Gregory Mirsky; 'Ross Callon'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

Hi Greg,

I've not checked that you implemented the changes you said you would in your email. No reason not to trust you.

[Major snipping]

OK. Maybe...
OLD
GIM>> Done.

> directional BFD session. But I agree, it is unlikely to be set to 0.

Well, yes, "unlikely".
I suppose there is no reason to prevent setting zero unless you would find reserved value useful.
GIM>> yes, the RFC 5880 states that the value zero is reserved but does not elaborate on interpretation of it nor prohibits its use.

An implementation MAY change the mode of authentication mode sooner if...
GIM>> Would the following do:
"An implementation MAY change mode of authentication if an operator re-evaluates security situation in and around the administrative domain."

>> 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
> GIM>> BFD

Nearly there...

If the TC sub-TLV is present, then the sender of any data packets on the LSP with a FEC that corresponds to the FEC for which fault detection is being performed MUST use the value contained in the TC field of the sub-TLV as the value of the TC field in the top label stack entry of the MPLS label stack.
GIM>> Adrian, the proposed text, as I interpret it, requires that TC value been applied to all data packets, not only OAM. How about the following wording:
"If the TC sub-TLV is present, then the sender of any periodic continuity monitoring messages or packets with fault management  information on the LSP with a FEC that corresponds to the FEC for which fault detection is being performed MUST use the value contained in the TC field of the sub-TLV as the value of the TC field in the top label stack entry of the MPLS label stack."

>> configuration. You should explain them.

Missing an answer?
Change SHOULD to MUST or add: "An implementation MAY configure the working and protection LSPs with different settings of these fields if..."
GIM>> I've missed it. "An implementation MAY configure the working and protection LSPs with different settings of these fields in case of 1:N protection."

> 6374, 6375, 6427 and 6428 be sufficient?

The para with these simple references that you've added is OK, but I think you are missing discussion of how these security aspects are configured. If we are dealing with the configuration of OAM then we should deal with the configuration of OAM security.

In order that the configuration of OAM function can be achieved securely through the techniques described in this document, security mechanisms must already be in place and operational for LSP Ping. Thus the exchange of security parameters (such as keys) for use in securing OAM is outside the scope of this document and is assumed to use an off-line mechanism or an established secure key-exchange protocol.

You have a spelling mistake: "extenssions"
GIM>> Thank you, Adrian. Done.
Ciao,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 25 Aug 2015 01:00:11 +0100

Perfect, Greg.
 
Thanks for all the hard work.
 
Adrian
 
From: Gregory Mirsky [mailto:[email-masked]] 
Sent: 24 August 2015 19:22
To: [email-masked]; 'Ross Callon'; [email-masked]
Cc: [email-masked];
[email-masked]
Subject: RE: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
 
Hi Adrian,
apologies for missed comments. I've used green to colour my responses with the
same tag GIM>>.
 
        Regards,
                Greg
 
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, August 23, 2015 8:36 AM
To: Gregory Mirsky; 'Ross Callon'; [email-masked]
Cc: [email-masked];
[email-masked]
Subject: RE: [mpls] working group last call for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10
 
Hi Greg,

[Major snipping]

OK. Maybe...
OLD

Well, yes, "unlikely".
I suppose there is no reason to prevent setting zero unless you would find
reserved value useful.
GIM>> yes, the RFC 5880 states that the value zero is reserved but does not
elaborate on interpretation of it nor prohibits its use.

 
 
An implementation MAY change the mode of authentication mode sooner if...
GIM>> Would the following do:
"An implementation MAY change mode of authentication if an operator re-evaluates
security situation in and around the administrative domain."

Nearly there...
 
If the TC sub-TLV is present, then the sender of any data packets on the LSP
with a FEC that corresponds to the FEC for which fault detection is being
performed MUST use the value contained in the TC field of the sub-TLV as the
value of the TC field in the top label stack entry of the MPLS label stack.
GIM>> Adrian, the proposed text, as I interpret it, requires that TC value been
applied to all data packets, not only OAM. How about the following wording:
"If the TC sub-TLV is present, then the sender of any periodic continuity
monitoring messages or packets with fault management  information on the LSP
with a FEC that corresponds to the FEC for which fault detection is being
performed MUST use the value contained in the TC field of the sub-TLV as the
value of the TC field in the top label stack entry of the MPLS label stack."

Missing an answer?
Change SHOULD to MUST or add: "An implementation MAY configure the working and
protection LSPs with different settings of these fields if..."
GIM>> I've missed it. "An implementation MAY configure the working and
protection LSPs with different settings of these fields in case of 1:N
protection."

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 25 Aug 2015 00:19:06 +0000

Hi Ross,
the updated version just been posted. It addresses all comments received during the WGLC.

                Regards,
                                Greg

From: mpls [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, August 19, 2015 11:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-10

Thanks, Ross
(as MPLS wg co-chair)

Working Group,

Ross
for the MPLS WG chairs

Subject: New Version Notification - draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-11.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 25 Aug 2015 00:16:06 +0000

A new version (-11) has been submitted for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf:
https://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-11.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.