Return-Path: 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 To: Alexander Vainshtein , "david.i.allan@ericsson.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: , <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> In-Reply-To: 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" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , Thomas Nadeau , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:32:42 -0000 --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 b= ut 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 operatio= n only. It does not involve CV operation which indeed requires its own dedi= cated 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; swallow@cisco.com Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf= .org; pwe3 (pwe3@ietf.org); Rot= em 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 havi= ng two code points is to indicate to the receiver whether there is a traili= ng 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; swallow@= cisco.com; John E Drake Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf= .org; pwe3 (pwe3@ietf.org); Rot= em 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 mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = 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, e= specially 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 L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e 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 informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion 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, p= hone or fax, and then delete the original and all copies thereof. --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha,

 

Oopsie.

 

Doesn’t RFC 5885  describe the u= se of BFD for pseudowire VCCV?   Other than the independent mode = that Greg mentioned,  RFC 6428 is just standard BFD but it is for an L= SP 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<= br>To: John E Drake; david.i.allan@ericsson.com; swallow@cisco.comCc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@i= etf.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.

 

Unfortuna= tely it does not address my question which referred to CC operation only. I= t does not involve CV operation which indeed requires its own dedicated G-A= Ch type.

 

But CC (and RDI) operation see= ms to be exactly the same in RFC 6428 and RFC 5885.<= /p>

 

Or do I miss something?

 

Regards,

  = ;   Sasha 

From: John E Drake [j= drake@juniper.net]
Sent: Wednesday, July 11, 2012 6:24 PM
T= o: Alexander Vainshtein; = david.i.allan@ericsson.com; swallo= w@cisco.com
Cc: cpignat= a@cisco.com; Thomas Nadeau; mpls@ietf.= org; pwe3 (pwe3@ietf.org); Rotem C= ohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in alloc= ation 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 pack= et is to be used for CV rather than CC.<= o:p>

 = ;

T= hanks,

 

John

 

Sent from my iPhone

 <= o:p>

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

 

Hi all,

I have doubts regarding allocation of th= e G-ACH type for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885= , it seems that the format of the MPLS-TP CC packet and the format of the r= aw BFD packet in VCCV is exactly the same. However, two different G-ACH typ= es have been allocated by IANA for these two cases.

 

=

IMHO and FWIW such duplica= tion 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 tha= t refers to existing capability to run BFD over LSP with the G-ACh using Ch= annel Type 7 only adds to the confusion IMO, since it uses un-capitalized &= #8220;may” and not one of the IETF reserved requirement level words.<= o:p>

 = ;

Cla= rification of intentions by the editors of RFC 6428 (and/or of RFC 5885) wo= uld be highly appreciated.

 

Regards,

=      Sasha

 

This e-mail message is intended for t= he recipient only and contains information which is CONFIDENTIAL and which = may be proprietary to ECI Telecom. If you have received this transmission i= n error, please inform us by e-mail, phone or fax, and then delete the orig= inal and all copies thereof.

=

This e-mail message is intended for the recipient only and contain= s information which is CONFIDENTIAL and which may be proprietary to ECI Tel= ecom. 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. =

= --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_--