Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
draft-ietf-mpls-tp-cc-cv-rdi-06

[Ballot comment]
Hoping you'll take a look at these during AUTH48.

1) Both the secdir reviewer and I tripped over the use of integrity in the abstract:

Abstract: "integrity of the continuity" seems redundant. Just
"continuity" is better.

Abstract: "any loss of continuity defect". So you lost a "continuity
defect", did you? Slipper little guys, aren't they? Maybe you mean
"any loss-of-continuity defect".

#2) Expand OAM on first use.

#3) Introduction: Double references: "[12][12]" and "[13][13]".

#4) Introduction: Missing commas: "the same
  continuity check (CC) proactive continuity verification (CV) and
  remote defect indication (RDI) capabilities" should be "the same
  continuity check (CC), proactive continuity verification (CV), and
  remote defect indication (RDI) capabilities".

#5) Section 2.1: Please include entries for P/F, MPLS, OAM, and PDU.

#6) Section 3.7.4.1: Are the figure #s correct?

#7) Section 4: There should be a blank line before the title.

#8) Figure 4, Figure 6: There should be a blank line after the Figure label.

#9) Section 4, Section 6: No blank line before Section header.

#10) Section 4: Ends with a list of length 1. List constructs should not be
used for lists of length one.

#11) Section 6: There should be a blank line before the title.

[Ballot comment]
This is updated.

1) Both the secdir reviewer and I tripped over the use of integrity in the abstract:

Abstract: "integrity of the continuity" seems redundant. Just
"continuity" is better.

Abstract: "any loss of continuity defect". So you lost a "continuity
defect", did you? Slipper little guys, aren't they? Maybe you mean
"any loss-of-continuity defect".

#2) Expand OAM on first use.

#3) Introduction: Double references: "[12][12]" and "[13][13]".

#4) Introduction: Missing commas: "the same
  continuity check (CC) proactive continuity verification (CV) and
  remote defect indication (RDI) capabilities" should be "the same
  continuity check (CC), proactive continuity verification (CV), and
  remote defect indication (RDI) capabilities".

#5) Section 2.1: Please include entries for P/F, MPLS, OAM, and PDU.

#6) Section 3.7.4.1: Are the figure #s correct?

#7) Section 4: There should be a blank line before the title.

#8) Figure 4, Figure 6: There should be a blank line after the Figure label.

#9) Section 4, Section 6: No blank line before Section header.

#10) Section 4: Ends with a list of length 1. List constructs should not be
used for lists of length one.

#11) Section 6: There should be a blank line before the title.

[Ballot comment]
1) Both the secdir reviewer and I tripped over the use of integrity in the abstract:

Abstract: "integrity of the continuity" seems redundant. Just
"continuity" is better.

Abstract: "any loss of continuity defect". So you lost a "continuity
defect", did you? Slipper little guys, aren't they? Maybe you mean
"any loss-of-continuity defect".

#2) Expand OAM on first use.

#3) Introduction: Double references: "[12][12]" and "[13][13]".

#4) Introduction: Missing commas: "the same
  continuity check (CC) proactive continuity verification (CV) and
  remote defect indication (RDI) capabilities" should be "the same
  continuity check (CC), proactive continuity verification (CV), and
  remote defect indication (RDI) capabilities".

#5) Section 2.1: Please include entries for P/F, MPLS, OAM, and PDU.

#6) Section 3.7.4.1: Are the figure #s correct?

#7) Section 4: There should be a blank line before the title.

#8) Figure 4, Figure 6: There should be a blank line after the Figure label.

#9) Section 4, Section 6: No blank line before Section header.

#10) Section 4: Ends with a list of length 1. List constructs should not be
used for lists of length one.

#11) Section 6: There should be a blank line before the title.

[Ballot discuss]
#1) Is there a reason there's not a normative reference to "OAM, as defined in [RFC6291]."?

#2) (This is related to the my discuss #2 on draft-ietf-mpls-tp-identifiers) I was going to place this against the mpls-tp-identifiers draft, but it says that the protocols that make use of the identifiers have to explain the security considerations of the identifiers...so ... Are there security consequences if the identifiers are not unique?  If additional text gets added to tp-identifiers, are there any additional concerns?

[Ballot comment]
Joel Jaeggli made a number of editorial suggestions in his OPS-DIR review. I suggest that these are taken into consideration:

2.1

I would add continuity check to the glossary since cv is in there (both are also defined elsewhere)

3.5 says:

  The base spec is unclear on aspects of how a MEP with a BFD transmit
  rate set to zero behaves. One interpretation is that no periodic
  messages on the reverse component of the bi-directional LSP originate
  with that MEP, it will only originate messages on a state change.

I would prefer think that by suggesting this the doucment would simply state thst this is the interpretation that SHOULD be used. it should probably also site teh mpls tp base spec.

  3.7.7. Discriminator values

  In the BFD control packet the discriminator values have either local
  to the sink MEP or no significance (when not known).
   
  My Discriminator field MUST be set to a nonzero value (it can be a
  fixed value), the transmitted your discriminator value MUST reflect
  back the received value of My discriminator field or be set to 0 if
  that value is not known.
   
Your Discriminator show always be capatalized given that it's the name of the field.

likewise:

   
  Per RFC5884 Section 7 [8], a node MUST NOT change the value of the
  "my discriminator" field for an established BFD session. 

My Discriminator  should also be capitalized, I would also be consistent about the use of quotes either use them or not. probably I would just be consistent with rfc 5884

IANA has several questions about the actions requested by
draft-ietf-mpls-tp-cc-cv-rdi-05.txt.

ACTION 1:

Upon approval of this document, IANA will register the following
Pseudowire Associated Channel Types at
http://www.iana.org/assignments/pwe3-parameters

Value Description TLV Follows Reference
----- ----------- ----------- ---------
TBD MPLS-TP CC message (?) [RFC-to-be]
TBD MPLS-TP CV message (?) [RFC-to-be]

QUESTION: How should we fill in the "TLV Follows" column for these
registrations?


ACTION 2:

Upon approval of this document, IANA will create the following registry
at http://www.iana.org/assignments/pwe3-parameters

Registry Name: MEP-ID TLV Registry (?)
Reference: [RFC-to-be]
Registration Procedures: Standards Action

Value Name Reference
----- ---- ---------
(?) Section MEP-ID [RFC-to-be]
(?) LSP MEP-ID [RFC-to-be]
(?) PW MEP-ID [RFC-to-be]

QUESTION: Since this document is creating the registry, it should supply
the values. Should the first entry, Section MEP-ID, be 0, 1, or
something else? Should 0 be marked "reserved"?

QUESTION: What is this registry's maximum value?

QUESTION: What's the name of this registry? "MEP-ID TLV Registry,"
"Source MEP-ID TLV," or something else?

QUESTION: The IANA Considerations section says that this document's
"parent registry" will be the "PW Associated Channel Type" registry. Is
this correct? I'm asking because the name "MEP-ID" doesn't seem to be
associated with any of the existing values in PW Associated Channel
Types, as we would expect for a sub-registry.


ACTION 3:

Upon approval of this document, IANA will register the following in the
BFD Diagnostic Codes registry at
http://www.iana.org/assignments/bfd-parameters

Value BFD Diagnostic Code Name Reference
----- ------------------------ ---------
TBD mis-connectivity defect [RFC-to-be]

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Proactive Connectivity Verification, Continuity Check and Remote
  Defect indication for MPLS Transport Profile'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  Continuity Check, Proactive Connectivity Verification and Remote
  Defect Indication functionalities are required for MPLS-TP OAM.

  Continuity Check monitors the integrity of the continuity of the
  label switched path for any loss of continuity defect. Connectivity
  verification monitors the integrity of the routing of the label
  switched path between sink and source for any connectivity issues.
  Remote defect indication enables an End Point to report, to its
  associated End Point, a fault or defect condition that it detects on
  a pseudo wire, label switched path or Section.

  This document specifies methods for proactive continuity check,
  continuity verification, and remote defect indication for MPLS-TP
  label switched paths, pseudo wires and Sections using Bidirectional
  Forwarding Detection.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-cc-cv-rdi/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD review

Hi authors,

I have done my usual AD review of your draft having received a
publication request from the working group. The purpose of the
review is to ensure that the document has a smooth passage through
IETF last call and the IESG.

Listed below are a nuber of editorial issues that I would like you
to resolve before I advance the document. All points are open for
discussion.

I have put the document into "revised I-D needed" state, but as soon
as I see a revised version I will request IETF last call.

Thanks for the work.

Adrian

---

idnits shows that reference [12] is not used. Either insert this where
it is needed, or remove the reference.

---

BFD is not a "recognized" acronym. Please expand it on first use in the
Introduction. Please also include a reference to [4].
                                                                                           
---

s/sub path/sub-path/

---
                                                                                           
G-ACh, p2p and p2mp need to be expanded on first use.

---

Section 1.1 is unusual and seems unnecessary in view of the Authors'
Addresses section. The RFC Editor will ask you why you need this section
and I would encourage you to remove it.

---

Section 2.1

LSP is missing

MPLS-TP LSP s/Label Switch Path/Label Switched Path/

---

Section 3.1

  Implementations MAY also interoperate with existing equipment by
  implementing [2], or [8] in addition to the procedures documented in
  this memo.

s/MAY/may/
s/existing/legacy/                                             

But this is a strange sentence. It implies that there are two different
ways to interoperate with same legacy equipment. Is that right?

It also implies that in order to interoperate with legacy equipment you
must implement *all* the procudures in this document.

I can't parse whether you mean...

  2 or (8 and this memo)
or
  (2 or 8) and this memo

---

Section 3.2

  RDI is communicated via the BFD diagnostic field in BFD CC messages.
  It is not a distinct PDU. A sink MEP will encode a diagnostic code of
  "1 - Control detection time expired" when the interval times detect
  multiplier have been exceeded, and with "5 - Path Down" as a
  consequence of the sink MEP receiving AIS with LDI set. A sink MEP
  that has started sending diagnostic code 5 SHOULD NOT change it to 1
  when the detection timer expires.

I couldn't work out whether this is new behavior or existing behavion.
I think the latter. If so, you need a reference like "As defined in
[foo] a sink MEP..."

Probably s/will/SHOULD/ according to the referenced text?

---

Section 3.3

This launches straight into the figure without saying what is going on.
Can you add a short paragraph to say "Figure 1 shows..."                                                                                   


  The first nibble (0001b) indicates the ACH.
This is not a new definition, so can you add the reference?

  - BFD CC code point = 0xXX. [HH to be assigned by IANA from the PW
  Associated Channel Type registry.] or,

  - BFD proactive CV code point = 0xXX+1. [HH to be assigned by IANA
  from the PW Associated Channel Type registry.]
s/HH/XX/ twice

---

Section 3.4

I believe you will want the XX in the figure to be updated by the RFC
Editor. You need to add a note to ask the RFC Editor to do this.

---

Section 3.5

Similarly, you will want XX+1 replaced with an absolute number

  The length in the BFD control packet is as per [4], the MEP Source ID
  TLV is not included.

Is that s/The length/If the length/ ?

  When GAL label is used, the time to live (TTL) field of the GAL MUST
  be set to at least 1, and the GAL will be the end of stack label
  (S=1).

s/GAL label/GAL/
You say "will be" because this behavior is defined elsewhere. Please
give a reference.

---

Section 3.5.1

I understand why this section is the way it is. However, you should
remove this section and add text to the Introduction such as...

  This document utilizes identifiers for MPLS-TP systems as defined in
  [9]. Work is on-going in the ITU-T to define a globally-unique
  semantic for ITU Carrier Codes (ICCs), and future work may extend
  this document to utilize ICCs as identifiers for MPLS-TP systems.

---

Section 3.5.2 - 3.5.4

There are stray "=" characters in the figures.

A bit odd that these figures are not numbered.

---

Section 3.5.3

  The format for the LSP MEP-ID is as defined in [9]

The referenced document does not define any format. This is good because
it means you are not duplicating a format definition, but is bad because
the text is wrong.

---

Section 3.5.4

As 3.5.3

---
                                 
Section 3.7.3

  The blocking of traffic as a consequent action MUST be driven only by
  a defect's consequent action as specified in draft-ietf-mpls-tp-oam-
  framework [11] section 5.1.1.2.

Please don't name the document in the text. Use the reference.

---

Section 3.7.5

It may be helpful to show the event "LDI set" in quotes in the text to
make things easier to parse.

  For independent mode, there are two state machines. One for the
  source MEP (who requested bfd.MinRxInterval=0) and the sink MEP (who
  agreed to bfd.MinRxInterval=0).

s/who/which/  twice

---

Section 4

  The following is an exemplary set of configuration parameters for a
  BFD session:

Nothing perfect about that set :-)
s/exemplary/example/

---

Section 5

Dave Ward is an author. You can remove hi from this section.

---

Section 6

  This draft requires the creations of a source MEP-ID TLV
  registry with initial values of:

      Xx  - Section MEP-ID

      Xx+1 - LSP MEP-ID

      Xx+2 - PW MEP-ID

You will need to say what the parent registry of this new subregistry
is.

You need to say what information needs to be tracked (maybe just TLV
Type, Name, and reference.
                                           
You should reference RFC 5226 for the allocations policy.

In section 3.5 you use X1, X2 and X3. I think you should use that here.

---

Section 7 is very thin!

Anyway, in 3.5 you say...
  When digest based authentication is used, the Source ID TLV MUST NOT
  be included in the digest
But doesn't this give us a problem making sure that the TLV has not been
modified? It is clearly important that this is not modified because you
wrote:
  A node MUST NOT change the value in the MEP Source ID TLV.
If this field cannot be protected, you need to note this in Section 7
and observe the consequences if it is modified. Also helpful to state
the mitgation.

The MPLS WG requests that:

      Proactive Connectivity Verification, Continuity Check and Remote
              Defect indication for MPLS Transport Profile
                      draft-ietf-mpls-tp-cc-cv-rdi-04

is published as an RFC on the standards track.


> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members
>      and from key non-WG members? Does the Document Shepherd have
>      any concerns about the depth or breadth of the reviews that
>      have been performed?

The document has been reviewed in the mpls working group and in the SG15
of the ITU-T.


The shephered is convinced that this is sufficient review for this
framework document.


> (1.c) Does the Document Shepherd have concerns that the document
>      needs more review from a particular or broader perspective,
>      e.g., security, operational complexity, someone familiar with
>      AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is no IPR claim for this draft.



> (1.e) How solid is the WG consensus behind this document? Does it
>      represent the strong concurrence of a few individuals, with
>      others being silent, or does the WG as a whole understand and
>      agree with it?

There is a good consensus around this draft, it has been through working
group last call. The last call was brought to the notice of SG15 in ITU-U
who reviewed the document. It has also passed a working roup call to verify
that LC comments were correctly with minor comments. The comments has been
carefully discussed between the authors and people making the comments and
has been resolved.
A separate wg last call has been issued in the BFD working group, primarily
to ensure that we keep compatibility between the base and MPLS earlier
developed and the extensions developed by the mpls-tp project.



> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent? If so, please summarise the areas of conflict in
>      separate email messages to the Responsible Area Director. (It
>      should be in a separate email because this questionnaire is
>      entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

check!!


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.

All documents that are referenced are past working group last
call (RFCs, approved by te IESG or publication requested).


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There is a clear and concise IANA section in this document.


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary


  MPLS LSPs [emulating traditional transport circuits are expected to
  deliver the same the capabilities for monitoring  connections as in
  earlier types of transport networks.
  The document describe and specify, as required in RFC 5860,
  Continuity Check (CC), proactive Connection Verfication (CV) and Remoted Defect
  Indication (RDI). This document describes the use of BFD for for these
  functions for PWs, LSPs or SPMEs between two Maintenance Entity Group
  End Points (MEPs).

  CC and Proactive CV are functions used to detect loss of
  continuity (LOC), and unintended connectivity between two MEPs. 

  RDI is an indicator that is transmitted by a MEP to communicate to
  its peer MEP that a signal fail condition exists.

  This document specifies the BFD extension and behavior to satisfy the
  CC, proactive CV monitoring and the RDI functional requirements for
  both co-routed and associated bi-directional LSPs. Supported
  encapsulations include GAL/G-ACh, VCCV and UDP/IP. Procedures for
  uni-directional LSPs are for further study.

  The mechanisms specified in this document are restricted to BFD
  asynchronous mode.



Working Group Summary

  This document is a MPLS working group document, and part of the joint
  IETF . ITU.T MPLS-TP project. It ahs been reviewed in both organizations
  and there is a solid support for the document.

Document Quality

The document is well reviewed in the MPLS working group,the ITU-T and
the BFD working group.