Subject: [PWE3] Doubts in allocation of a new G-ACH type for

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jul 2012 10:51:19 +0000

Hi all,
I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC message in RFC 6428<http://tools.ietf.org/html/rfc6428>.

Looking at both this RFC and RFC 5885<http://tools.ietf.org/html/rfc5885>, it seems that the format of the MPLS-TP CC packet and the format of the raw BFD packet in VCCV is exactly the same. However, two different G-ACH types have been allocated by IANA for these two cases.

IMHO and FWIW such duplication can only create interoperability problems, especially with progress of the new VCCV Type (using GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capability to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un-capitalized "may" and not one of the IETF reserved requirement level words.

Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885) would be highly appreciated.

Regards,
     Sasha

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: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jul 2012 11:37:05 -0400

Dear Sasha, et al.,
I think that one of differences between CC defined in RFC 5885 and RFC 6428 in introduction of independent mode to monitor associated bi-directional p2p connections. Then there's FSMs fo coordinated and independent modes, Fig.7 and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV while there's no CV for neither Control Channel 0x07.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; [email-masked]; [email-masked]
Cc: [email-masked]; Mishael Wexler; [email-masked]; pwe3 ([email-masked]); Rotem Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type for

Hi all,

Regards,
     Sasha

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Jul 2012 12:07:26 -0400

Hi Sasha:

The reason for this is the overall system behavior implied. A 5885 code point is purely CC operation. A 6428 code point indicates that CV will be interleaved with the stream. We wanted to explicitly disambiguate this.

It further permits misbranching of a 5885 stream into a 6428 path to be detected so the overall network is more robust. If the CC messages in both 5885 and 6428 had a common code point, this would not be possible, and CV operation would not be authoritative.

I hope this helps
Dave

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; pwe3 ([email-masked]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

Hi all,

Regards,
     Sasha

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Jul 2012 09:24:01 -0700

Sasha,

The BFD packet format is the same for both CC and CV.  The  reason for having two code points is to indicate to the receiver whether there is a trailing source ID TLV, in which case the packet is to be used for CV rather than CC.

Thanks,

John

Sent from my iPhone

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 3:51 AM
To: [email-masked]; [email-masked]; John E Drake
Cc: [email-masked]; Thomas Nadeau; [email-masked]; pwe3 ([email-masked]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

Hi all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jul 2012 17:12:53 +0000

John,

Lots of thanks for a prompt response.

Unfortunately it does not address my question which referred to CC operation only. It does not involve CV operation which indeed requires its own dedicated G-ACh type.

But CC (and RDI) operation seems to be exactly the same in RFC 6428 and RFC 5885.

Or do I miss something?

Regards,

     Sasha

________________________________
From: John E Drake [[email-masked]]
Sent: Wednesday, July 11, 2012 6:24 PM
To: Alexander Vainshtein; [email-masked]; [email-masked]
Cc: [email-masked]; Thomas Nadeau; [email-masked]; pwe3 ([email-masked]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Sasha,

Thanks,

John

Sent from my iPhone

Hi all,

IMHO and FWIW such duplication can only create interoperability problems, especially with progress of the new VCCV Type (using GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capability to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un-capitalized “may” and not one of the IETF reserved requirement level words.

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jul 2012 17:17:31 +0000

Dave,

Unfortunately I have to say that it is confusing: interleave of CC and CV packets on the same stream is achieved by using a different G-ACh type for CV messages. This type discriminates between CC and CV messages equally well for any of the two G-ACh types that potentially could be used for carrying CC messages.

Do I miss something fundamental?

Regards,

     Sasha

________________________________
From: David Allan I [[email-masked]]
Sent: Wednesday, July 11, 2012 6:07 PM
To: Alexander Vainshtein; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; pwe3 ([email-masked]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Hi Sasha:

I hope this helps
Dave

Hi all,

Regards,
     Sasha

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Jul 2012 13:21:09 -0400

Hi Sasha:

cc list trimmed....

I'm sorry, I'm not quite grasping your point.

We need to know when CC will not have CV interleaved.
We need to know when CC will have CV interleaved.
We need to know when a CV TLV will be present.

Ergo 3 code points. Could you clarify your concern?
Dave

Sent: Wednesday, July 11, 2012 10:18 AM

Dave,

Regards,

     Sasha

Hi Sasha:

I hope this helps
Dave

Hi all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jul 2012 17:29:50 +0000

Greg,

Regarding your first point - ability to maintain independent BFD sessions for associated unidirectional LSPs: Do you imply that, as far as co-routed bidirectional LSPs are concerned, G-ACh Type = 7 is as good as G-ACh Type = 22?

As for ability to deduce from receiving something with G-ACh Type = 22 that you should be also reqdy to receive something with G-ACh Type = 23 (CV), I do not think that this is explicitly specified anywhere. From my point of view, ability to support CV MUST be explicitly synchronized between the LSP endpoints (by configuration or signaling).

My 2c,

     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Wednesday, July 11, 2012 5:37 PM
To: Alexander Vainshtein; David Allan I; [email-masked]; [email-masked]
Cc: [email-masked]; Mishael Wexler; [email-masked]; pwe3 ([email-masked]); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Dear Sasha, et al.,

    Regards,
        Greg

Hi all,

Regards,
     Sasha

---

From: John E Drake <[email-masked]>
Date: Wed, 11 Jul 2012 11:30:27 -0700

Sasha,

Oopsie.

Doesn't RFC 5885  describe the use of BFD for pseudowire VCCV?   Other than the independent mode that Greg mentioned,  RFC 6428 is just standard BFD but it is for an LSP rather than a pseudowire.  Or did I miss something 8->?

Thanks,

John

Sent from my iPhone

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 10:13 AM
To: John E Drake; [email-masked]; [email-masked]
Cc: [email-masked]; Thomas Nadeau; [email-masked]; pwe3 ([email-masked]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

John,

Or do I miss something?

Regards,

     Sasha

________________________________
From: John E Drake [[email-masked]]
Sent: Wednesday, July 11, 2012 6:24 PM
To: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Thomas Nadeau; [email-masked]<mailto:[email-masked]>; pwe3 ([email-masked]<mailto:[email-masked]>); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for
Sasha,

Thanks,

John

Sent from my iPhone

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 3:51 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; John E Drake
Cc: [email-masked]<mailto:[email-masked]>; Thomas Nadeau; [email-masked]<mailto:[email-masked]>; pwe3 ([email-masked]<mailto:[email-masked]>); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

Hi all,

Regards,
     Sasha

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jul 2012 20:04:17 -0400

Hi Sasha,
if one is interested only in CC monitoring on bi-directional p2p LSP in coordinated mode, then, IMHO, use PW-ACH ecapsulation is as good as MPLS-TP CC code point.
In Section 3.3 of RFC 6428 I read (apologies for a lengthy quote):
  "CC and CV operations are simultaneously employed on a maintenance
   entity (ME) within a single BFD session.  The expected usage is that
   normal operation is to send CC BFD protocol data units (PDUs)
   interleaved with a CV BFD PDU (augmented with a Source MEP-ID and
   identified as requiring additional processing by the different ACh
   channel types)."
Yes, though there is no MUST or even CAN but I'd interpret it as SHOULD. At the same time MPLS-TP CC ACh MAY be used, by mutual agreement between the end points, as CC only, without expectation of CV messages. AFAIK, http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 supports explicit CC and CC/CV configuration.

    Regards,
        Greg

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, July 11, 2012 10:30 AM
To: Gregory Mirsky; David Allan I; [email-masked]; [email-masked]
Cc: [email-masked]; Mishael Wexler; [email-masked]; pwe3 ([email-masked]); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Greg,

My 2c,

     Sasha

Dear Sasha, et al.,

    Regards,
        Greg

Hi all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2012 04:29:03 +0000

Greg,

Lots of thanks for a prompt and highly informative response!

Regards,

     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Thursday, July 12, 2012 2:04 AM
To: Alexander Vainshtein
Cc: [email-masked]; Mishael Wexler; pwe3 ([email-masked]); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Hi Sasha,

    Regards,
        Greg

Greg,

My 2c,

     Sasha

Dear Sasha, et al.,

    Regards,
        Greg

Hi all,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jul 2012 04:58:40 +0000

Dave,

Lots of thanks for a prompt response. My reading of this response is like following:

  1.  If you are only interested in CC but do not use CV functionality, use G-ACH type = 7 (from RFC 5885).
  2.  If you are interested in CC and CV interleaved, use G-ACH type = 22 for CC and G-ACH type = 23 for CV.
  3.  If the session has been brought up using G-ACH type = 7, any received CV messages MUST be ignored.
  4.  If the session has been set up with G-ACH Type = 22 but no CV messages have ever been received, no defect is detected and hence no consequent action is taken.

Did I miss something?

If this reading is correct, how could it become common? As I see it, the current situation creates ample opportunities for interoperability problems.

Regards,

     Sasha

________________________________
From: David Allan I [[email-masked]]
Sent: Wednesday, July 11, 2012 7:21 PM
To: Alexander Vainshtein
Cc: [email-masked]; pwe3 ([email-masked])
Subject: RE: Doubts in allocation of a new G-ACH type for

Hi Sasha:

cc list trimmed....

Dave,

Regards,

     Sasha

Hi Sasha:

I hope this helps
Dave

Hi all,

Regards,
     Sasha

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 11 Jul 2012 14:40:58 -0400

On Jul 11, 2012, at 11:30 AM, "John E Drake" <[email-masked]<mailto:[email-masked]>> wrote:

Sasha,

Oopsie.

Doesn’t RFC 5885  describe the use of BFD for pseudowire VCCV?

yes

Tom

Other than the independent mode that Greg mentioned,  RFC 6428 is just standard BFD but it is for an LSP rather than a pseudowire.  Or did I miss something 8->?

Thanks,

John

Sent from my iPhone

To: John E Drake; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

John,

Or do I miss something?

Regards,

     Sasha

From: John E Drake [[email-masked]<mailto:[email-masked]>]

Thanks,

John

Sent from my iPhone

Hi all,

Regards,
     Sasha

---

From: David Allan I <[email-masked]>
Date: Thu, 12 Jul 2012 13:29:18 -0400

HI Sasha:

You are correct in noting that there is no representation in the RFC for requiring any sort timer associated with CV PDU reception (it only discusses send interval), which means a non-compliant implementation sending CVs could operate undetected by an implementation that made no measurement at all of reception of CVs and if it misbranched into a different LSP, would not be detected.

Another LSP running CV leaking into the LSP served by the non-compliant implementation would still be detected.

Well spotted!
Dave

Sent: Wednesday, July 11, 2012 9:59 PM
To: David Allan I

Dave,

Did I miss something?

Regards,

     Sasha

Hi Sasha:

cc list trimmed....

Dave,

Regards,

     Sasha

Hi Sasha:

I hope this helps
Dave

Hi all,

Regards,
     Sasha