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

Thomas Nadeau <tnadeau@juniper.net> Wed, 11 July 2012 18:42 UTC

Return-Path: <tnadeau@juniper.net>
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 0A35E11E80EF; Wed, 11 Jul 2012 11:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level:
X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, 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 SPICM64o35EA; Wed, 11 Jul 2012 11:42:55 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6F011E80DB; Wed, 11 Jul 2012 11:42:52 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT/3JR9NUXHa0q1wI4Wxx16WwTSZ6DcWN@postini.com; Wed, 11 Jul 2012 11:43:26 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jul 2012 11:41:03 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 11 Jul 2012 14:41:02 -0400
From: Thomas Nadeau <tnadeau@juniper.net>
To: John E Drake <jdrake@juniper.net>
Date: Wed, 11 Jul 2012 14:40:58 -0400
Thread-Topic: Doubts in allocation of a new G-ACH type for
Thread-Index: Ac1flLhm14+iYO1cQMyTU5OPosWnow==
Message-ID: <13CD53A9-978D-413C-8D53-A0517D6B62DE@juniper.net>
References: <F9336571731ADE42A5397FC831CEAA0209A20B@FRIDWPPMB001.ecitele.com> <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> <F9336571731ADE42A5397FC831CEAA0209A37A@FRIDWPPMB001.ecitele.com> <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, Mishael Wexler <Mishael.Wexler@ecitele.com>, "pwe3 (pwe3@ietf.org)" <pwe3@ietf.org>, Rotem Cohen <Rotem.Cohen@ecitele.com>
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 18:42:56 -0000




On Jul 11, 2012, at 11:30 AM, "John E Drake" <jdrake@juniper.net<mailto:jdrake@juniper.net>> 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

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 10:13 AM
To: John E Drake; david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>; swallow@cisco.com<mailto:swallow@cisco.com>
Cc: cpignata@cisco.com<mailto:cpignata@cisco.com>; Thomas Nadeau; mpls@ietf.org<mailto:mpls@ietf.org>; pwe3 (pwe3@ietf.org<mailto:pwe3@ietf.org>); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for


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 [jdrake@juniper.net<mailto:jdrake@juniper.net>]
Sent: Wednesday, July 11, 2012 6:24 PM
To: Alexander Vainshtein; david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>; swallow@cisco.com<mailto:swallow@cisco.com>
Cc: cpignata@cisco.com<mailto:cpignata@cisco.com>; Thomas Nadeau; mpls@ietf.org<mailto:mpls@ietf.org>; pwe3 (pwe3@ietf.org<mailto:pwe3@ietf.org>); 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:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>; swallow@cisco.com<mailto:swallow@cisco.com>; John E Drake
Cc: cpignata@cisco.com<mailto:cpignata@cisco.com>; Thomas Nadeau; mpls@ietf.org<mailto:mpls@ietf.org>; pwe3 (pwe3@ietf.org<mailto:pwe3@ietf.org>); 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.