Re: [mpls] Doubts in allocation of a new G-ACH type for

[David Allan I <[e-mail]>]

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



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


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 [[e-mail]]
Sent: Wednesday, July 11, 2012 7:21 PM
To: Alexander Vainshtein
Cc: [e-mail]; pwe3 ([e-mail])
Subject: RE: Doubts in allocation of a new G-ACH type for

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

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


Dave,

Lots of thanks for a prompt response.



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 [[e-mail]]
Sent: Wednesday, July 11, 2012 6:07 PM
To: Alexander Vainshtein; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; pwe3 ([e-mail]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

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:[e-mail]]
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; pwe3 ([e-mail]); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

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.

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.