Re: [mpls] 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: 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 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: "mpls@ietf.org" <mpls@ietf.org>, 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: [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: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.