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

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 11 July 2012 15:36 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98021F86B3; Wed, 11 Jul 2012 08:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIkfgqvAEv61; Wed, 11 Jul 2012 08:36:53 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD8F421F86A1; Wed, 11 Jul 2012 08:36:52 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6BFb6Z7019664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 10:37:20 -0500
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 11 Jul 2012 11:37:07 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, David Allan I <david.i.allan@ericsson.com>, "swallow@cisco.com" <swallow@cisco.com>, "jdrake@juniper.net" <jdrake@juniper.net>
Date: Wed, 11 Jul 2012 11:37:05 -0400
Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for
Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAJsURg
Message-ID: <FE60A4E52763E84B935532D7D9294FF137D71927CC@EUSAACMS0715.eamcs.ericsson.se>
References: <F9336571731ADE42A5397FC831CEAA0209A20B@FRIDWPPMB001.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA0209A20B@FRIDWPPMB001.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D71927CCEUSAACMS0715e_"
MIME-Version: 1.0
Cc: Mishael Wexler <Mishael.Wexler@ecitele.com>, "mpls@ietf.org" <mpls@ietf.org>, Rotem Cohen <Rotem.Cohen@ecitele.com>, "pwe3 (pwe3@ietf.org)" <pwe3@ietf.org>, "tnadeau@juniper.net" <tnadeau@juniper.net>
Subject: Re: [mpls] Doubts in allocation of a new G-ACH type for
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 15:36:54 -0000

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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org); 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.