Re: [PWE3] Doubts in allocation of a new G-ACH type for
John E Drake <jdrake@juniper.net> Wed, 11 July 2012 18:32 UTC
Return-Path: <jdrake@juniper.net>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46111E80EF; Wed, 11 Jul 2012 11:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.936
X-Spam-Level:
X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.662, 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 XoVzgA+4+0ZY; Wed, 11 Jul 2012 11:32:40 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1F11E80DB; Wed, 11 Jul 2012 11:32:39 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT/3G4UKLChPQnWZ0d3ipHRzpNLe+dmEZ@postini.com; Wed, 11 Jul 2012 11:33:11 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 11 Jul 2012 11:30:27 -0700
From: John E Drake <jdrake@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "david.i.allan@ericsson.com" <david.i.allan@ericsson.com>, "swallow@cisco.com" <swallow@cisco.com>
Date: Wed, 11 Jul 2012 11:30:27 -0700
Thread-Topic: Doubts in allocation of a new G-ACH type for
Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgALh55QAAEniWcAAx45gA==
Message-ID: <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net>
References: <F9336571731ADE42A5397FC831CEAA0209A20B@FRIDWPPMB001.ecitele.com>, <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> <F9336571731ADE42A5397FC831CEAA0209A37A@FRIDWPPMB001.ecitele.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA0209A37A@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_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_"
MIME-Version: 1.0
Cc: "cpignata@cisco.com" <cpignata@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>, Andrew Sergeev <Andrew.Sergeev@ecitele.com>, Mishael Wexler <Mishael.Wexler@ecitele.com>, Thomas Nadeau <tnadeau@juniper.net>, "pwe3 (pwe3@ietf.org)" <pwe3@ietf.org>, Rotem Cohen <Rotem.Cohen@ecitele.com>
Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 18:32:42 -0000
Sasha, Oopsie. Doesn't RFC 5885 describe the use of BFD for pseudowire VCCV? 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; swallow@cisco.com Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (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] 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.
- [PWE3] Doubts in allocation of a new G-ACH type f… Alexander Vainshtein
- Re: [PWE3] [mpls] Doubts in allocation of a new G… Gregory Mirsky
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… David Allan I
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… John E Drake
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… Alexander Vainshtein
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… Alexander Vainshtein
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… David Allan I
- Re: [PWE3] [mpls] Doubts in allocation of a new G… Alexander Vainshtein
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… John E Drake
- Re: [PWE3] [mpls] Doubts in allocation of a new G… Gregory Mirsky
- Re: [PWE3] [mpls] Doubts in allocation of a new G… Alexander Vainshtein
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… Alexander Vainshtein
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… Thomas Nadeau
- Re: [PWE3] Doubts in allocation of a new G-ACH ty… David Allan I