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 6E7B611E8114; Wed, 11 Jul 2012 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 QeKIq5bJ8lY7; Wed, 11 Jul 2012 09:07:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7577211E8085; Wed, 11 Jul 2012 09:07:05 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6BG7V9H016944; Wed, 11 Jul 2012 11:07:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 11 Jul 2012 12:07:27 -0400 From: David Allan I To: Alexander Vainshtein , "swallow@cisco.com" , "jdrake@juniper.net" Date: Wed, 11 Jul 2012 12:07:26 -0400 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655Q Message-ID: <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> References: 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_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_" MIME-Version: 1.0 Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , "tnadeau@juniper.net" , "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 16:07:07 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poi= nt is purely CC operation. A 6428 code point indicates that CV will be inte= rleaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be det= ected so the overall network is more robust. If the CC messages in both 588= 5 and 6428 had a common code point, this would not be possible, and CV oper= ation would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (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 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. --_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sasha:
 
The=20 reason for this is the overall system behavior implied. A 5885 code point i= s=20 purely CC operation. A 6428 code point indicates that CV will be interleave= d=20 with the stream. We wanted to explicitly disambiguate=20 this.
 
It=20 further permits misbranching of a 5885 stream into a 6428 path to be detect= ed so=20 the overall network is more robust. If the CC messages in both 5885 and 642= 8 had=20 a common code point, this would not be possible, and CV operation would not= be=20 authoritative.
 
I hope=20 this helps
Dave

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 3:51 AM
To: David Allan I; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: Doubts in allocation of a new G-ACH type for=20

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC=20 6428.

 

Looking at both this RFC and RFC 5885, it seems that the= format=20 of the MPLS-TP CC packet and the format of the raw BFD packet in VCCV is ex= actly=20 the same. However, two different G-ACH types have been allocated by IANA fo= r=20 these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_--