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

[Gregory Mirsky <[e-mail]>]

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


Greg,

Lots of thanks for a prompt response.



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


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: [e-mail] [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; [e-mail]; [e-mail]
Cc: [e-mail]; Mishael Wexler; [e-mail]; pwe3 ([e-mail]); Rotem Cohen
Subject: [mpls] 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.