Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

From: Rui Costa <[email-masked]>
Date: Mon, 4 Jul 2011 23:02:31 +0100

IMHO and for the record:	

ITU-T comments regarding this draft haven't been discussed with ITU-T but were simply ignored. No LS describing these comments' resolution was sent.	

Several service providers regarded this draft as not meeting their transport networks' needs.	

[The v03 draft was published in Feb and went to WG LC.	
The v04 draft addressing WG LC comments was published on the 28th June (same date as the proto write-up).	
When was the WG LC launched, to verify LC comments resolution?]	

Regards,	
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (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'
  <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> 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
[email-masked] mailing lists by 2011-07-14. Exceptionally, comments may be
sent to [email-masked] 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.
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: David Allan I <[email-masked]>
Date: Wed, 6 Jul 2011 09:57:57 -0400

Hi Rui:

The comments were not ignored, the resolution of the Q10 comments as well as those collected from the MPLS WG was presented at the last IETF. My spreadsheet from which that report was generated and has been augmented to include the BFD WG comments is available at http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls

So you know...
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: Monday, July 04, 2011 3:03 PM
To: [email-masked]; IETF-Announce
Cc: [email-masked]
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

IMHO and for the record:	

Regards,	
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
Sent: quinta-feira, 30 de Junho de 2011 14:47
To: IETF-Announce
Cc: [email-masked]
Subject: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to 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 [email-masked] mailing lists by 2011-07-14. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

---

From: Loa Andersson <[email-masked]>
Date: Wed, 06 Jul 2011 17:44:08 +0200

All,

Since someone has commented about the process used for resolving 
questions on
draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below.

The history of draft-ietf-mpls-tp-cc-cv-rdi working group review
process is:

On February 3rd 2011 the working group last call was issued
on version -03

      This was copied to the the Ad Hoc Team List
      and liaised to SG15 also on February 3rd

      This working group last call ended om Feb 28

      On Feb 28 we also received a liaison with comments from SG15

The authors compiled a list of all comments received  as part the MPLS
working group last call; these  comments - and the intended resolution -
is included in the meeting minutes from the Prague meeting:

      http://www.ietf.org/proceedings/80/slides/mpls-9.pdf

  During the IETF meeting in Prague, we agreed with the BFD working
  group to do a separate working group last callfor the BFD working
  group

The (BFD) working group last call was started on March 30th and ran
for 13 days. The last call ended on April 11th.

  The authors have since worked hard to resolve comments, some
  issue has been brought to the working group mailing list for
  resolution.

  Version -04 of the document was published June 28th.

  The publication request for draft-ietf-mpls-tp-cc-cv-rdi was  sent
  June 29th.

  The AD review resulted in a "New ID needed" due to mostly editorial
  comments. Version -05 was published on June 29 and the IETF last call
  started as soon as the new ID was avaialbe.

  The current list of Last Call Comments resoltion is also avaiable at:
  http://www.pi.nu/~loa/cc-cv-rdi-Last-Call-Comments.xls

  The list of issues that the authors kept very carefully, shows without 
doubt
  that no comments been ignored.

  Loa
  mpls wg document shepherd

On 2011-07-05 00:02, Rui Costa wrote:
> Subject: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>  (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard
>
>

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 13 Jul 2011 15:02:25 +0200

Dear all,
I regret to say I have the same concerns expressed by Rui and Erminio about the procedure adopted for this document that has brought so many discussions. Anyway, probably because of the lack of a reasonable time (in my opinion) for discussions about the previous document version (-04) I have the following comments on this version:

1. it is not clear the BFD's scope
        Sect. 1: PW, LSP, SPME
        Sect. 1: LSP
        Sect 3: LSP
        Sect 3.1:LSP, PW
        Sect 3.3: PW, LSP, SPME, Section
        Sect 3.7: LSP

2. encapsulation
        Sect 1: supported encapsulation GAL/GACh, VCCV, UDP/IP: can be expressed a preference (MUST/MAY) for Transport Profile applications for interoperability issues? I would avoid single vendor networks coming from too many options.

3. diagnostic code 5
        Could you clarify what is the BFD state machine behavior receiving/transmitting a Diagn Code=5

4. detection time
        Sect 3.2: I expect it is that one defined in RFC5884 i.e. detect Mult x greater (bfd.requiredminrxinterval, last received desired min tx interval). What "interval" means is not clear

5. session periodicity
        Sec 3.3 Should be clarified being not defined in RFC5880

6. detection of loss of continuity
        Sect 3.3 can CV packet  sent on the wire replace CC packet (for LOC purpose on the far end)?

7. CV vs CC packets
        Sect 3.6 Generally speaking, how should the received CV packet's fields be managed with respect of the BFD state machine/BFD states? (beyond what is specified in such paragraph limited to P/F and Sta).

8. encoding
        Sect 3.5: could you clarify what " A BFD session will only use one encoding of the Source ID TLV" means?

9. editorial
        Source ID TLV, MEP source ID TLV, Source MEP TLV should be aligned

10. terminology
        Wrt sect 3.6 I would ask a clarification about the terminology where I found
        a- "A BFD session corresponds to a CC and proactive CV OAM instance"
        b- " A BFD session is enabled when the CC and proactive CV functionality is enabled"
        c- " When the CC and proactive CV functionality is disabled ..., the BFD session transitions to the ADMIN DOWN State and the BFD session ends"
                In the ADMIN DOWN state I understood I can have BFD control packet exchange between the end points. Is it consistent with CC/CV functionality disabled?
11. code points
        Code points are not specified in section 3.1 as stated

12. BFD fixed rate
        Sect 3.7 " This rate is a fixed value common for both directions of MEG for the lifetime of the MEG". Is this statement implying that MEG must be destroyed to be able to change the BFD rate? Should not be limited to the BFD session lifetime (to be clarified what it means... because moving to ADMIN DOWN state both ends could not be enough)

13. two BFD modes
        Sect 3.7 " Two independent BFD sessions are used for independent operation". In my opinion, this approach still remain a big limitation in BFD usage.
        Is it implementation specific the way the two ends distinguish between the two BFD modes?

14. bfd.RemoteDiscr
        Sect 3.7 " In coordinated mode, an implementation SHOULD NOT reset bfd.RemoteDiscr until it is exiting the DOWN state"
        Is it a deviation from BFD as specified in RFC 5880? If it is, could you clarified the reason for that?

15. bfd.RemoteDiscr
        Sect 3.7 Could you clarify the reasons behind different treatments for bfd.RemoteDiscr in coordinated mode and independent mode?

16. overall operation
        Sect 3.7 "Overall operation is as specified in [4] and augmented for MPLS in[8]"
        Are you sure that it can be generalized in that way? Should not be the case to specify more in details what applies and what do not apply?

17. IP-based BFD
        Sect 3.1  IP-based BFD can carry out CV functionality only if IP SA is public

18. CV during transient states
        Sect 3.2 for clarification: at start-up, CC are sent one per second. CV are sent in addition to CC (so we have two BFD packets per second)?

19. misconnections
        Sect 3.7.3 sect 3.7.3 states a misconnection bring BFD session to DOWN whilst it is not clear if sect 3.7.5 state that misconnection do not impact on BFD state transition

20. encapsulation modes
        Sect 4: if I understood well, there are 4 encapusulations and modes for BFD: UDP/IP/LSP; CC mode in G-ACh; UPD/IP in G-ACh e CC/CV mode in G-ACh.
        Do all of them satisfy transport requirements?
        I understand they are not interoperable (as well as the two BFD mode for the same CC/CV in G-Ach encapsulation). Is it correct?

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: mercoledì 6 luglio 2011 17:44
A: Rui Costa
Cc: [email-masked]; [email-masked]; IETF-Announce
Oggetto: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt> (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard

All,

Since someone has commented about the process used for resolving questions on draft-ietf-mpls-tp-cc-cv-rdi I am supplying some details below.

The history of draft-ietf-mpls-tp-cc-cv-rdi working group review process is:

On February 3rd 2011 the working group last call was issued on version -03

The authors compiled a list of all comments received  as part the MPLS working group last call; these  comments - and the intended resolution - is included in the meeting minutes from the Prague meeting:

The (BFD) working group last call was started on March 30th and ran for 13 days. The last call ended on April 11th.

  The list of issues that the authors kept very carefully, shows without doubt
  that no comments been ignored.

  Loa

On 2011-07-05 00:02, Rui Costa wrote:
> Subject: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>
> (Proactive Connectivity Verification, Continuity Check and Remote
> Defect indication for MPLS Transport Profile) to Proposed Standard
>
>
> [email-masked] mailing lists by 2011-07-14. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the

--

                                              +46 767 72 92 13 _______________________________________________

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: <[email-masked]>
Date: Thu, 14 Jul 2011 20:22:42 +0900

The changes in this version have massive impact for CC/CV/RDI implementation.
We, venders, have kept making efforts on interoperability test again and again.
These changes spoil this effort.

Especially, revival of Poll/Final sequence doesn't make sense.
Originally, in my understanding, Poll/Final sequence was excluded from this draft
to avoid making HW implementation difficult. 

Even though it was difficult to change CC interval arbitrary, 
the problem should be solved by defining how to transit DOWN/INIT state to UP state.

The direction which reached consensus once should NOT be changed easily
in order to respond to the market requirements.

IMO, such major changes should NOT be added right before becoming RFC.

I found at least four major/minor changes as follows;
1)Revival of Poll/Final sequence
2)Change of MEP ID formats
3)Change of Diag. Code
4)Change of CV interleaved definition

BR,
Hideki

---

From: "S. Davari" <[email-masked]>
Date: Thu, 14 Jul 2011 06:11:02 -0700 (PDT)

Hi,

I also have concern regarding:

1) Different MEP ID formats
2) CV interleaving

These two functions make the Hardware implementation very complex and delays 
implementation and deployment of this draft. I would have 2 suggestions to fix 
this:

1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments 
instead of TLV. TLVs are not hardware friendly.

2) Default to be All CC or All CV. Have the CV interleaving optional (if both 
sides are capable).

Thx
Shahram

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Thu, July 14, 2011 4:22:42 AM
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive 
Connectivit

Especially, revival of Poll/Final sequence doesn't make sense.
Originally, in my understanding, Poll/Final sequence was excluded from this 
draft
to avoid making HW implementation difficult. 

Even though it was difficult to change CC interval arbitrary, 
the problem should be solved by defining how to transit DOWN/INIT state to UP 
state.

BR,
Hideki

---

From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:39:37 -0400

Sharam,

The CV packets are sent at one per second i.e at a rate which does not really need hardware assist, and as such the format of these packets is not  really optimized for HW implementation.

The CC packets can be sent at whatever rate both ends can support, typically today this can be around one per milli-second hence HW assist is required for CC packets and indeed the baseline BFD is designed around this premise.

So,   quite contrary to your statement of:

> implementation and deployment of this draft. I would have 2 suggestions to fix this:

The decisions made are in fact  aimed at allowing for fast hardware implementation of CC, it is after all the same packet as baseline bFD with a different codepoint,  and not requiring it for the CV. In fact with CV having a different codepoint, as Dave explained in an earlier reply this makes  for a very simple filtering/classification of which packets are to be handled by HW and which can be punted to a slowpath.

Cheers

Rob Rennison

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of S. Davari [[email-masked]]
Sent: Thursday, July 14, 2011 9:11 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:  <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Hi,

These two functions make the Hardware implementation very complex and delays implementation and deployment of this draft. I would have 2 suggestions to fix this:

1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW, Segments instead of TLV. TLVs are not hardware friendly.

2) Default to be All CC or All CV. Have the CV interleaving optional (if both sides are capable).

Thx
Shahram

Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivit

BR,
Hideki

>[email-masked]<mailto:[email-masked]> mailing lists by 2011-07-14. Exceptionally, comments may be
>sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the
>[email-masked]<mailto:[email-masked]>
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: [email-masked]
Date: Thu, 14 Jul 2011 20:43:20 +0000

So your idea is to run CV in SW. That is quite possible but this means the BFD engine needs to be duplicated, one in HW and one in SW. 

Is that the intention of the group? If so it is not an efficient way of using the resources in a router.

Thx
SD
Sent via BlackBerry by AT&T

-----Original Message-----
From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:39:37 
To: S. Davari<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
Subject: RE: [mpls] Last Call:
	<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob Rennison

Hi,

Thx
Shahram

BR,
Hideki

---

From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:56:03 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of [email-masked] [[email-masked]]
Sent: Thursday, July 14, 2011 7:22 AM
To: [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:  <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivit

>to avoid making HW implementation difficult.

[RR] preventing a peer from modifying the rate once the initial target rate was achieved  i.e arbitrary re-negotiation was  and is excluded, that was the "problem"  the group consensus was  to solve. 

However P/F is needed to get from the initial 1 per second default rate to the desired rate. This and the rational for an initial P/F were discussed in detail back in March /April.

>the problem should be solved by defining how to transit DOWN/INIT state to UP state.

[RR] There is no problem in defining how to transit from Down/Init to UP state, it's covered in the existing state machine and is not changed. 

Cheers

Rob

BR,
Hideki

---

From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 19:39:42 -0400

Sharam,

Where one runs the protocol and how one divides it up, is up to the implementation, you may choose to run it all in SW all in HW or a combination, just like for any protocol.  I am merely pointing out those aspects which are most optimal for HW assist, in case you desire to have a more "efficient" implementation.  I'd have thought you'd  appreciate that! 

Regarding running  duplicate BFD "engines", I'm not sure in your review of the draft you spotted the following, but in case you did not.

" All BFD state changes and P/F exchanges MUST be done using CC
   packets. P/F and session state information in CV packets MUST be
   ignored."

As you can see there's no generic BFD  "engine" /state machine required for the CV messages, they do not directly affect the BFD state, they of course affect whether you enter or exit the defect state as described in defect entry and exit criteria sections. 

Cheers

Rob

________________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, July 14, 2011 4:43 PM
To: Robert Rennison; [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Thx
SD

-----Original Message-----
From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:39:37
To: S. Davari<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
Subject: RE: [mpls] Last Call:
        <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob Rennison

Hi,

Thx
Shahram

BR,
Hideki

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 14 Jul 2011 17:03:53 -0700

Robert,

May be I am missing something here. Is the intention to have 2 separate BFD sessions: one BFD CC and one BFD CV each with their own rate and state machine? Or this is all one BFD sessions in which some of the BFD packets are CV rather than CC.

If these are two separate BFD sessions then there are 3 choices:

1) process CC and CV in HW, in which case this is very complex since CC and CV have different format and different processing as well as different state Machine. Also I would need to separate BFD generator in HW at different rates

2) process CC and CV in SW, which is not practical due to fast rate of CC

3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well.

If there is only one BFD session and the CC and CV are part of the same state machine, then we only have option (1) and (2).

In either case these are not good practical choices. After all RFC's are not university thesis, they have to be reasonably implementable.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Rennison
Sent: Thursday, July 14, 2011 4:40 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob

Thx
SD

-----Original Message-----
From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:39:37
To: S. Davari<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
Subject: RE: [mpls] Last Call:
        <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob Rennison

Hi,

Thx
Shahram

BR,
Hideki

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 14 Jul 2011 17:34:59 -0700

On another note:

When any of the defects in section 3.7.2. happens, it seems that the State Machine should move to DOWN state. But the defects in section 3.7.2. are not shown as a trigger to transition to DOWN State in any of the State Machine figures.

Am I missing something?

Thx
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Thursday, July 14, 2011 5:04 PM
To: Robert Rennison; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Robert,

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Rennison
Sent: Thursday, July 14, 2011 4:40 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob

Thx
SD

-----Original Message-----
From: Robert Rennison <[email-masked]>
Date: Thu, 14 Jul 2011 16:39:37
To: S. Davari<[email-masked]>; [email-masked]<[email-masked]>; [email-masked]<[email-masked]>
Subject: RE: [mpls] Last Call:
        <draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Sharam,

Cheers

Rob Rennison

Hi,

Thx
Shahram

BR,
Hideki

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 14 Jul 2011 18:30:59 -0700

Shahram,

Having done a implementation of CC/CV, here are some notes I can share.

- Completely agree on not wanting to duplicate the BFD engine in h/w and 
s/w. Use s/w for managing all session including those that are run in 
h/w. That includes managing the different formats of sessions.

- Have s/w setup the session in h/w as necessary. But limit the 
functionality to what h/w is good at. E.g. sending of BFD packets at the 
(ms) rate agreed upon and for detection of these ms sessions when the 
BFD session has failed.

- Pass the failure of BFD session notification to s/w for it to handle 
the state machine change (including switching the LSPs).

On 7/14/2011 5:03 PM, Shahram Davari wrote:
> From: Robert Rennison<[email-masked]>
> From: "[email-masked]"<[email-masked]>
> Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivit
>

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Jul 2011 21:47:58 -0700

Shahram,

The last time I checked, there was no 'Let's make sure Shahram is  
happy before proceeding' clause in the approval process.  If you're  
asleep at the wheel, I think that is your problem.

Thanks,

John

Sent from my iPhone

On Jul 14, 2011, at 5:35 PM, "Shahram Davari" <[email-masked]>  
wrote:

> On another note:
>
> When any of the defects in section 3.7.2. happens, it seems that the  
> State Machine should move to DOWN state. But the defects in section  
> 3.7.2. are not shown as a trigger to transition to DOWN State in any  
> of the State Machine figures.
>
> Am I missing something?
>
> Thx
> Shahram
>
> May be I am missing something here. Is the intention to have 2  
> separate BFD sessions: one BFD CC and one BFD CV each with their own  
> rate and state machine? Or this is all one BFD sessions in which  
> some of the BFD packets are CV rather than CC.
>
> 1) process CC and CV in HW, in which case this is very complex since  
> CC and CV have different format and different processing as well as  
> different state Machine. Also I would need to separate BFD generator  
> in HW at different rates
>
> 3) Process CC in HW and CV in SW, which is not efficient since we  
> are duplicating the HW logic in SW as well.
>
> If there is only one BFD session and the CC and CV are part of the  
> same state machine, then we only have option (1) and (2).
>
> In either case these are not good practical choices. After all RFC's  
> are not university thesis, they have to be reasonably implementable.
>
>
> Regards,
> Shahram
>
>
> Where one runs the protocol and how one divides it up, is up to the  
> implementation, you may choose to run it all in SW all in HW or a  
> combination, just like for any protocol.  I am merely pointing out  
> those aspects which are most optimal for HW assist, in case you  
> desire to have a more "efficient" implementation.  I'd have thought  
> you'd  appreciate that!
>
>
> Regarding running  duplicate BFD "engines", I'm not sure in your  
> review of the draft you spotted the following, but in case you did  
> not.
>
> As you can see there's no generic BFD  "engine" /state machine  
> required for the CV messages, they do not directly affect the BFD  
> state, they of course affect whether you enter or exit the defect  
> state as described in defect entry and exit criteria sections.
>
> Cheers
>
> Rob
>
> So your idea is to run CV in SW. That is quite possible but this  
> means the BFD engine needs to be duplicated, one in HW and one in SW.
>
> The CV packets are sent at one per second i.e at a rate which does  
> not really need hardware assist, and as such the format of these  
> packets is not  really optimized for HW implementation.
>
>
> The CC packets can be sent at whatever rate both ends can support,  
> typically today this can be around one per milli-second hence HW  
> assist is required for CC packets and indeed the baseline BFD is  
> designed around this premise.
>
>
> The decisions made are in fact  aimed at allowing for fast hardware  
> implementation of CC, it is after all the same packet as baseline  
> bFD with a different codepoint,  and not requiring it for the CV. In  
> fact with CV having a different codepoint, as Dave explained in an  
> earlier reply this makes  for a very simple filtering/classification  
> of which packets are to be handled by HW and which can be punted to  
> a slowpath.
>
> Cheers
>
> Rob Rennison
>
> These two functions make the Hardware implementation very complex  
> and delays implementation and deployment of this draft. I would have  
> 2 suggestions to fix this:
>
> 1) Make all MEPIDs the same size (e.g. 12 bytes) for all LSP, PW,  
> Segments instead of TLV. TLVs are not hardware friendly.
>
> This e-mail message is intended for the recipient only and contains  
> information which is CONFIDENTIAL and which may be proprietary to  
> ECI Telecom. If you have received this transmission in error, please  
> inform us by e-mail, phone or fax, and then delete the original and  
> all copies thereof.
>
>
>
> This e-mail message is intended for the recipient only and contains  
> information which is CONFIDENTIAL and which may be proprietary to  
> ECI Telecom. If you have received this transmission in error, please  
> inform us by e-mail, phone or fax, and then delete the original and  
> all copies thereof.
>

---

From: <[email-masked]>
Date: Fri, 15 Jul 2011 07:58:39 +0100

I agree Shahram.  We knew 15 or so years ago CC was a mistake in ATM so I'm not sure why we want to repeat ATM's mistake in MPLS-TP.  

Important aside=> OAM needs to be as simple as is possible...because it needs to be super reliable.  For defect detection we only need CV and BDI functions.  AIS is a also a mistake in any packet-switching networks from that same ATM era (though I have to confess it took me a while to fully realise just what a bad mistake this was).  TCM is another mistake with the all the a priori configured false 'sublayered' hierarchies. I don't seem to hear many operators crying out for more complexity and potential worse reliability.  What they want is increased reliability, simple config and simple operations...so that their existing Ops folks can handle it. 

regards, Neil

This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 14 July 2011 21:43
> So your idea is to run CV in SW. That is quite possible but this means
> the BFD engine needs to be duplicated, one in HW and one in SW.
> 
> The CV packets are sent at one per second i.e at a rate which does not
> really need hardware assist, and as such the format of these packets is
> not  really optimized for HW implementation.
> 
> 
> typically today this can be around one per milli-second hence HW assist
> is required for CC packets and indeed the baseline BFD is designed
> around this premise.
> 
> 
> implementation of CC, it is after all the same packet as baseline bFD
> with a different codepoint,  and not requiring it for the CV. In fact
> with CV having a different codepoint, as Dave explained in an earlier
> reply this makes  for a very simple filtering/classification of which
> packets are to be handled by HW and which can be punted to a slowpath.
> 
> Cheers
> 
> Rob Rennison
> 
> These two functions make the Hardware implementation very complex and
> delays implementation and deployment of this draft. I would have 2
> suggestions to fix this:
> 
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform
> us by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Jul 2011 09:12:05 +0100

> 3) Process CC in HW and CV in SW, which is not efficient since we are duplicating the HW logic in SW as well.
Now I know that it depends on your implementation, but just how many 
lines of code are we talking about here?
The elements of this function that you would put in h/w do not seem complex.

- Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 15 Jul 2011 07:56:13 -0400

It is less efficient not really due to the duplication, but because the SW path is
a relatively very slow path for processing CV packets. It is also a relatively less scaleable
one as well as compared to doing in HW. So the a number of lines of processing or duplication
of code therein is a bit of a red herring if you ask me.

	--Tom

On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> Now I know that it depends on your implementation, but just how many lines of code are we talking about here?

---

From: <[email-masked]>
Date: Fri, 15 Jul 2011 21:17:10 +0900

Hi Robert,

Thank you very much for your reply, 
and I am sorry for my late response.

See inline, marked with [HE];

[HE]My understanding is far from yours.
The cc-cv-rdi-03 said 
"Poll/final discipline can only used for VCCV and UDP/IP encapsulated BFD.".
In my understanding, this meant that Poll/Final Sequence MUST NOT be used for GAL/G-ACh.
In other words, GAL/G-ACh MUST work well without Poll/Final Sequence
in the case of getting from initial state.
I think this was the group consensus.
If the consensus was only for re-negotiation, why was P/F excluded from GAL/G-ACh? 

>[RR] There is no problem in defining how to transit from Down/Init to UP state, it's covered in the existing state machine and is not changed. 
[HE]Sorry for lack of explanation.
I meant the interval change timing should be defined in the case of transition DOWN/INIT to UP state
without P/F sequence for GAL/G-ACh.

BR,
Hideki

---

From: "S. Davari" <[email-masked]>
Date: Fri, 15 Jul 2011 05:24:21 -0700 (PDT)

Tom is is correct. I meant to say not scalable.

Shahram

________________________________
From: Thomas Nadeau <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive 
Connectivity)

    It is less efficient not really due to the duplication, but because the SW 
path is
a relatively very slow path for processing CV packets. It is also a relatively 
less scaleable
one as well as compared to doing in HW. So the a number of lines of processing 
or duplication
of code therein is a bit of a red herring if you ask me.

    --Tom

---

From: Robert Rennison <[email-masked]>
Date: Fri, 15 Jul 2011 11:41:59 -0400

Se we're in agreement that there's no duplication of effort required; good.

I'll agree at a general level with a part of  Tom's overall statement that

>  It is also a relatively less scaleable >one as well as compared to doing in HW.

A HW implementation of a protocol can be made to be more scaleable than a SW only one, ok that's agreed.

>From  implementation experience with shipping scaleable and interoperable  BFD and has also  been pointed out by Mahesh, many vendors implement a combined approach, one needs software to manage the HW assist and the overall state machines, so a blended approach is usually done using HW for heavy lifting,  and distributing SW functions where necessary / desirable. 

The division of this work and the decision of what to accelerate with HW assist. is a function of where in the network the equipment is situated and the anticipated scale on it, these are descions made by vendors and born from experiences with implementations.

However one can if,  desired  accelerate aspects of CV  with "HW" assist too, it's a cos/ scale tradeoff that an implementation will make. One could have HW assist to send the one per second CV messages, and one could  add a "HW"   function to  match the CV messages if desired. 

Would  the RX match portion be more efficient with no TLVs for the various identifiers  ? Yes.  
Would the extra efficiency make a substantial difference to the HW cost, I doubt it. 
Is this a hard requirement ? Not that I've seen.

Note: all of this talk of HW vs SW is also not precise enough, vendors have so called Fast-path logic to play with too. so HW and SW are not necessarily sharp boundaries. But this is the stuff of a more general exposition and not germane to last call comments on the specific draft on the table.

Cheers

Rob

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of S. Davari [[email-masked]]
Sent: Friday, July 15, 2011 8:24 AM
To: Thomas Nadeau; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive   Connectivity)

Shahram

    --Tom

---

From: "S. Davari" <[email-masked]>
Date: Fri, 15 Jul 2011 08:50:13 -0700 (PDT)

Robert,

Forget about HW and SW. The mix of CC and CV makes any implementation complex. I 
don't see any significant benefit in it. I suggest either running CC or CV and 
of they are run together they should be 2 separate independent BFD flow.

-Shahram

________________________________
From: Robert Rennison <[email-masked]>
To: S. Davari <[email-masked]>; Thomas Nadeau <[email-masked]>; 
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Fri, July 15, 2011 8:41:59 AM
Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive 
Connectivity)

>  It is also a relatively less scaleable >one as well as compared to doing in 

A HW implementation of a protocol can be made to be more scaleable than a SW 
only one, ok that's agreed.

>From  implementation experience with shipping scaleable and interoperable  BFD 
and has also  been pointed out by Mahesh, many vendors implement a combined 
approach, one needs software to manage the HW assist and the overall state 
machines, so a blended approach is usually done using HW for heavy lifting,  and 
distributing SW functions where necessary / desirable.

The division of this work and the decision of what to accelerate with HW assist. 
is a function of where in the network the equipment is situated and the 
anticipated scale on it, these are descions made by vendors and born from 
experiences with implementations.

However one can if,  desired  accelerate aspects of CV  with "HW" assist too, 
it's a cos/ scale tradeoff that an implementation will make. One could have HW 
assist to send the one per second CV messages, and one could  add a "HW"   
function to  match the CV messages if desired.

Would  the RX match portion be more efficient with no TLVs for the various 
identifiers  ? Yes.
Would the extra efficiency make a substantial difference to the HW cost, I doubt 
it.
Is this a hard requirement ? Not that I've seen.

Note: all of this talk of HW vs SW is also not precise enough, vendors have so 
called Fast-path logic to play with too. so HW and SW are not necessarily sharp 
boundaries. But this is the stuff of a more general exposition and not germane 
to last call comments on the specific draft on the table.

Cheers

Rob

From: [email-masked] [[email-masked]] On Behalf Of S. Davari 
[[email-masked]]

Shahram

    --Tom

This e-mail message is intended for the recipient only and contains information 
which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have 
received this transmission in error, please inform us by e-mail, phone or fax, 
and then delete the original and all copies thereof.

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 15 Jul 2011 11:52:11 -0400

While I personally agree, I'd leave how it is actually run up to the operators. They might know a thing or two about running their networks. *)

	--Tom

> Robert,
> 
> Forget about HW and SW. The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it. I suggest either running CC or CV and of they are run together they should be 2 separate independent BFD flow.
> 
> -Shahram
> 
> 
> To: S. Davari <[email-masked]>; Thomas Nadeau <[email-masked]>; "[email-masked]" <[email-masked]>
> Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)
>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Jul 2011 12:05:16 -0400

In message <[email-masked]>
Stewart Bryant writes:
> lines of code are we talking about here?  The elements of this
> function that you would put in h/w do not seem complex.
>  
> - Stewart

Depending on performance requirements for a particular platform, less
functionality may be done with hardware assist in one platform and
more functionality may go into hardware.

That doesn't matter as far as standardization is concerned.  What does
matter is than anything which is time critical can be implemented in
hardware with reasonable simplicity.

It is a lot harder to get accurate counters in for every LSP for the
purpose of LM than it is to get mpls-tp-cc-cv-rdi CC or CV to work in
hardware.  Timestamps for DM are also not trivial.  These really can't
be done satisfactorily without hardware assist.  As mentioned, in many
platforms CV in software will be adequate and maybe even hardware
assist for CC detection and down transition actions in software will
be adequate for some platforms.  This is all implementation specifics.

As simple as possible but no simpler.  I think the current
mpls-tp-cc-cv-rdi meets this criteria.  This is all doable with many
currently shipping chips that can parse the OAM packets and direct the
OAM to an external FPGA.  It would save some watts and board space
when this goes onto forwarding ASICs, but it is doable at very high
speeds at reasonable density today.  (At extremely high performance
and insane density its challenging, but that too is just a small
matter of implementation detail and it is doable).

Curtis

---

From: "S. Davari" <[email-masked]>
Date: Fri, 15 Jul 2011 09:29:09 -0700 (PDT)

Everything is doable if you don't defy the laws of physics. But Simplicity is 
preferred. I think running CC alone or CV alone should satisfy most SP 
requirements. Mixing them together in a single BFD flow is also doable but more 
complex since the processing of BFD packets in a single BFD flows is now not 
unique rather two types of processing is needed. Also the draft doesn't specify 
whether the CV packets are counted toward the Sliding window or not (added 
complexity).

Shahram

________________________________
From: Curtis Villamizar <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Fri, July 15, 2011 9:05:16 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive 
Connectivity)

Curtis

---

From: Robert Rennison <[email-masked]>
Date: Fri, 15 Jul 2011 13:10:06 -0400

Hideki,

>
>>However P/F is needed to get from the initial 1 per second default rate to the desired rate. 
>>This and the rational for an initial P/F were discussed in detail back in March /April.

You are correct, the text in -03 does state this, this was back in April and I made many comments on the list as a result of the initial last-call explaining why some initial  level of P/F was necessary, Please check the thread on the list  re Poll / Final in draft-cc-cv-rdi,  for my reasoning. The authors took these concrete points into consideration and we worked together to come up with the current proposal.

I have seen no substantive concrete alternative approaches proposed  since April for modifying the rate from the starting rate to the desired rate.

Cheers

Rob

---

From: <[email-masked]>
Date: Fri, 15 Jul 2011 18:11:07 +0100

Shahram,

I could not agree with you more.  And if folks want to cogitate on the unnecessary complexity angle have a think about these points:
-       Consider PM flows.  These need stopping/starting in accordance with the entry/exit criteria of unavailability....else they are not worth bothering with.
-       All layers and sublayers need harmonising wrt unavailability entry/exit states.....now think about artificial TCM sublayers and how E2E paths move their routing at intermediate nodes in response to a failure whilst having fixed end nodes....noting there is a need to keep all the PM counters at all levels in sync here.
-       Now add a raft of different QoS classes per LSP/connection (hint=> this violates the rule of transparency anyway, and is thus just a really bad idea for something that is supposed to be a transport network) to what is noted above.

So if folks think the always-on defect handling can be complex, just wait until TCM and multiple QoS classes get added to the mix.  Simplicity is the key in OAM.

regards, Neil

From: [email-masked] [mailto:[email-masked]] On Behalf Of S. Davari
Sent: 15 July 2011 17:29
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Everything is doable if you don't defy the laws of physics. But Simplicity is preferred. I think running CC alone or CV alone should satisfy most SP requirements. Mixing them together in a single BFD flow is also doable but more complex since the processing of BFD packets in a single BFD flows is now not unique rather two types of processing is needed. Also the draft doesn't specify whether the CV packets are counted toward the Sliding window or not (added complexity).

Shahram

In message <[email-masked]<mailto:[email-masked]>>

Curtis

---

From: <[email-masked]>
Date: Sat, 16 Jul 2011 12:58:17 +0900

Robert,

>I have seen no substantive concrete alternative approaches proposed  since April for modifying the rate from the starting rate to the desired rate.

[HE]You are also correct. I know that discussion.
I'm very sorry for no reply at that time.
However, I don't think P/F is only solution for this problem.
Based on initial group consensus, the solution should be without P/F.
Therefore, I said that the interval change timing should be defined 
in the case of transition DOWN/INIT to UP state without P/F sequence for GAL/G-ACh.

BR,
Hideki

---

From: Rui Costa <[email-masked]>
Date: Mon, 25 Jul 2011 18:37:01 +0100

Thanks, Tom.
"The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it"
Agreed. We create a tool for checking the connection. That tool carries an instance identifier in the packet. That instance identifier is all we need to detect misconnections using just one type of packet.

i"f they are run together they should be 2 separate independent BFD flow"
Disagree. The problem is, we actually need a 2 way connection to run BFD's FSM, even when one just needs/can have unidireccional check (P2P unidir, P2MP...). So, what we need is a PDU integrating instance identifier sent @ constant provisioned pace, without any articulation with the opposite path other than RDI (when relevant).
If we don't consider not using BFD, then at least let's not complicate it more unnecessarily: we need a single type of packet for both CC and CV.
The frame loss draft, f.i., doesn't put it on BFD. Do we really need that?
If it's marketing we're talking about, wouldn't it be possible to set a PDU primitive protocol, integrating instance identifier, 3 counters for FL (or 4, as per draft-ietf-mpls-tp-loss-delay), timestamp, sent @ constant provisioned pace, without any articulation with the opposite path other than RDI (when relevant) and give it a cool name? BFD_NG, UFD, xFD, BFD_reloaded...)

"It is also a relatively less scaleable one as well as compared to doing in HW"
Agreed.

Kind Regards,
Rui

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: sexta-feira, 15 de Julho de 2011 16:52
To: S. Davari
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

            --Tom

Robert,

-Shahram

________________________________
From: Robert Rennison <[email-masked]<mailto:[email-masked]>>
To: S. Davari <[email-masked]<mailto:[email-masked]>>; Thomas Nadeau <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Fri, July 15, 2011 8:41:59 AM
Subject: RE: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

Cheers

Rob

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of S. Davari [[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 15, 2011 8:24 AM
To: Thomas Nadeau; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive  Connectivity)

Shahram

________________________________
From: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Fri, July 15, 2011 4:56:13 AM
Subject: Re: [mpls] Last Call:<draft-ietf-mpls-tp-cc-cv-rdi-05.txt>(Proactive Connectivity)

    --Tom

On Jul 15, 2011, at 4:12 AM, Stewart Bryant wrote:

> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Mon, 25 Jul 2011 19:20:49 +0100

Rui..I agree...but also see in-line:

Sent: 25 July 2011 18:37
To: Thomas Nadeau

Thanks, Tom.

"The mix of CC and CV makes any implementation complex. I don't see any significant benefit in it"
Agreed. We create a tool for checking the connection. That tool carries an instance identifier in the packet. That instance identifier is all we need to detect misconnections using just one type of packet.
NH=> CC is next to useless.  This is the same as I.610 ATM OAM.

NH=> It's actually quite vital that one runs defect detection OAM in a unidirectional sense for a very simple reason:  Under defect free conditions one assumes a connection is a constraining construct to both DP traffic and DP OAM....this (along with a single source assumption) is why one can take short-cuts on the labelling of co-ps mode traffic units that are not allowed on cl-ps traffic units, ie remove SA and restrict DA to link unique only, ie label swapping.  Neither is great idea but they are doable.

However, we can have instances of traffic/OAM that leaks unidirectionally out of a connection/LSP, ie there simply is no return path.  This is also why request/response OAM must not be used to detect misconnectivity or to try and trace out such leaks...this was another mistake of ATM I.610 OAM (multiple loopback technique).

And, as you also note above, one can of course have asymmetrical p2mp connections...which by definition are unidirectional.

Finally, one should run exactly the same type/rate of CV on all connections both in the same layer network and all nested instances of XoverX.  This is so that wherever misconnectivity defects occur (ie both intra and inter layer network...the latter being the new case that MPLS-TP introduces) the receiving trail termination point is easily able to make sense of parsing the received CV OAM flow.

regards, Neil

Kind Regards,
Rui

            --Tom

Robert,

-Shahram

Cheers

Rob

Shahram

    --Tom