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

[Alexander Vainshtein <[e-mail]>]

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

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:[e-mail]]
Sent: Wednesday, July 11, 2012 3:51 AM
To: [e-mail]; [e-mail]; John E Drake
Cc: [e-mail]; Thomas Nadeau; [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.