Subject: [mpls] Comments on draft-ietf-mpls-tp-cc-cv-rdi-01

From: Greg Mirsky <[email-masked]>
Date: Wed, 21 Jul 2010 23:12:27 -0700

Dear Authors and All,
please find my comments to the document below:

·         Abstract, first paragraph s/are/the

·         Section 3. From description of CV mode it is not clear, as from
description of CC mode, whether RDI functionalities supported in CV mode.
Though description of RDI explicitly mentions that. Either mention RDI
functionality in connection to CV mode or remove it from CC for consistency.

·         Section 3.1 “It's possible to run BFD in CC mode on some transport
paths and BFD in CV mode on other transport paths.” I think that this is
important to mention only for paths between the same pair of end nodes.

·         Section 3.4 “A BFD session is enabled when the CC or proactive CV
functionality is enabled on a configured Maintenance Entity (ME) or in the
case of an associated bi-directional path, pair of Maintenance Entities”
conflicts with “A new BFD session is initiated when the operator enables or
re-enables the CC or CV functionality on the same ME” as the latter
statement refers to a single ME instance regardless whether bi-directional
path is co-routed or associated. I think that a BFD session is one-to-one
mapped with ME regardless number of MEs that used to monitor connectivity
and/or continuity of p2p bidirectional path.

·         Section 3.5, first paragraph. I think that even though BFD is
capable to change frequency of transmitting messages on a fly, in MPLS-TP
such action must go through Admin Down state as one BFD session is
effectively taken down and another, with different parameters, is enabled.

·         Section 3.5,  p.7. I think that there’s another clarification of
how MEP with zero transmit rate send its BFD control packets will be in
useful - how this MEP sends these packets. Perhaps use of ACH encapsulation
over reverse direction of the associated bi-directional path will be default
behavior. But it could be over DCN with or without IP addressing.

Regards,

Greg

---

From: David Allan I <[email-masked]>
Date: Thu, 22 Jul 2010 12:13:02 -0400

Hi Greg:

Thanks for the read of the document and the feedback....

Dear Authors and All,

*         Abstract, first paragraph s/are/the

OK

*         Section 3. From description of CV mode it is not clear, as from description of CC mode, whether RDI functionalities supported in CV mode. Though description of RDI explicitly mentions that. Either mention RDI functionality in connection to CV mode or remove it from CC for consistency.

We will clarify in the next version.

*         Section 3.1 "It's possible to run BFD in CC mode on some transport paths and BFD in CV mode on other transport paths." I think that this is important to mention only for paths between the same pair of end nodes.

It would be even clearer if the mode was MEG specific. MEs in a MEG need to be homogenous in operation. If you agree we'll edit accordingly.

*         Section 3.4 "A BFD session is enabled when the CC or proactive CV functionality is enabled on a configured Maintenance Entity (ME) or in the case of an associated bi-directional path, pair of Maintenance Entities" conflicts with "A new BFD session is initiated when the operator enables or re-enables the CC or CV functionality on the same ME" as the latter statement refers to a single ME instance regardless whether bi-directional path is co-routed or associated. I think that a BFD session is one-to-one mapped with ME regardless number of MEs that used to monitor connectivity and/or continuity of p2p bidirectional path.

This has come up before, I believe the correct resolution is an associated bi-directional path is a single ME. We will edit accordingly.

*         Section 3.5, first paragraph. I think that even though BFD is capable to change frequency of transmitting messages on a fly, in MPLS-TP such action must go through Admin Down state as one BFD session is effectively taken down and another, with different parameters, is enabled.

I agree we do not want any changes on the fly. And we could say MUST for admin down to change anything, but that also means there are likely existing implementations out there that may not respect this.

*         Section 3.5,  p.7. I think that there's another clarification of how MEP with zero transmit rate send its BFD control packets will be in useful - how this MEP sends these packets. Perhaps use of ACH encapsulation over reverse direction of the associated bi-directional path will be default behavior. But it could be over DCN with or without IP addressing.

I'll take a look and see if this should be clarified.

cheers

Dave

---

From: "Reith, Lothar" <[email-masked]>
Date: Fri, 23 Jul 2010 20:21:57 +0200

Dear Authors and All,

please find some comments below:

Issue 1:   inconsistent use of the abbreviation "CV"

 in the title the subject starts with "Proactive Connection
Verification..." 

However, in the abstract the meaning of the abbreviation CV is
introduced as:

- Proactive Connectivity Verification (CV)

But in the section 2.1. Terminology the term CV is introduced as
follows:

CV: Connection Verification

Suggested resolution: The abbreviation CV should be used in an
unambiguous way throughout the document.

Issue 2: Clarification of the difference between the terms
"Connectivity" and "Connection"

As the apparently ambigous use of the abbreviation "CV" shows, the terms
"connectivity" and "connection" may be used synonomously in some cases.
However, I believe the concepts "Connectivity" and "Connection" are
different. 

Suggested Resolution: Provide a reference to where these terms are
defined, and double check if the usage of these terms is always aligned
with these definitions.

This should also help the reader in understanding the difference between
the terms "connectivity", "connection", and "path", which are all used
in the document, and perhaps also to the term "tunnel" in the meaning
"MPLS TP tunnel" as related to issue 3 below:

Issue 3:  I am missing any mention of "MPLS-TP tunnels", even though an
important construct within MPLS_TP is a connection which is provided
across a working and a protection LSP.

Suggested Resolution: Consider adding a section "applicability to MPLS
TP tunnels",  or add some wording in some other way that explains, if cc
and cv are affected by the state of an MPLS TP tunnel being traversed,
e..g when the tunnel switches from the working LSP to the protection
LSP.

Best Regards, Lothar

---

From: David Allan I <[email-masked]>
Date: Fri, 23 Jul 2010 14:33:29 -0400

hi Lothar:

Thanks for the suggested clarifications. We'll update the document accordingly.

As for tunnel, we quite deliberately tended to steer away from any multiple LSP constructs as we considered that out of scope of the document. That is more of a survivability framework or draft-wiengarten topic. We are focused on the granularity of an LSP or bi-directional LSP pair (associated or co-routed). At the moment I do not see a reason to introduce tunnels into the draft...

hope that helps
Dave

________________________________
From: Reith, Lothar [mailto:[email-masked]]
Sent: Friday, July 23, 2010 2:22 PM
To: David Allan I; Greg Mirsky; John E Drake; [email-masked]; Annamaria Fulignoli; Sami Boutros; [email-masked]; Siva Sivabalan(msiva); David Ward; [email-masked]; [email-masked]
Subject: AW: [mpls] Comments on draft-ietf-mpls-tp-cc-cv-rdi-01

Dear Authors and All,

 in the title the subject starts with "Proactive Connection Verification..."

However, in the abstract the meaning of the abbreviation CV is introduced as:

But in the section 2.1. Terminology the term CV is introduced as follows:

Suggested resolution: The abbreviation CV should be used in an unambiguous way throughout the document.

Issue 2: Clarification of the difference between the terms "Connectivity" and "Connection"

As the apparently ambigous use of the abbreviation "CV" shows, the terms "connectivity" and "connection" may be used synonomously in some cases.  However, I believe the concepts "Connectivity" and "Connection" are different.

Suggested Resolution: Provide a reference to where these terms are defined, and double check if the usage of these terms is always aligned with these definitions.

This should also help the reader in understanding the difference between the terms "connectivity", "connection", and "path", which are all used in the document, and perhaps also to the term "tunnel" in the meaning "MPLS TP tunnel" as related to issue 3 below:

Issue 3:  I am missing any mention of "MPLS-TP tunnels", even though an important construct within MPLS_TP is a connection which is provided across a working and a protection LSP.

Suggested Resolution: Consider adding a section "applicability to MPLS TP tunnels",  or add some wording in some other way that explains, if cc and cv are affected by the state of an MPLS TP tunnel being traversed, e..g when the tunnel switches from the working LSP to the protection LSP.

Best Regards, Lothar