Re: [mpls] [MPLS] A doubt about RFC 6428

David Allan I <david.i.allan@ericsson.com> Mon, 13 May 2013 19:57 UTC

Return-Path: <david.i.allan@ericsson.com>
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 0760E21F8EA4 for <mpls@ietfa.amsl.com>; Mon, 13 May 2013 12:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 CAQDYaePGX-l for <mpls@ietfa.amsl.com>; Mon, 13 May 2013 12:57:46 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DA21F8BBA for <mpls@ietf.org>; Mon, 13 May 2013 12:57:46 -0700 (PDT)
X-AuditID: c618062d-b7ff46d000006709-41-519145b9bfae
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.69.26377.9B541915; Mon, 13 May 2013 21:57:45 +0200 (CEST)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 13 May 2013 15:57:44 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: Alan Davey <Alan.Davey@metaswitch.com>
Thread-Topic: [MPLS] A doubt about RFC 6428
Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQA==
Date: Mon, 13 May 2013 19:57:44 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C09B253@eusaamb105.ericsson.se>
References: <C2EE31C852049D499842B19FC01C0804C1A8C004@ENFICSMBX1.datcon.co.uk> <E6C17D2345AC7A45B7D054D407AA205C097D0A@eusaamb105.ericsson.se> <C2EE31C852049D499842B19FC01C0804C1A8CD51@ENFICSMBX1.datcon.co.uk>
In-Reply-To: <C2EE31C852049D499842B19FC01C0804C1A8CD51@ENFICSMBX1.datcon.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C09B253eusaamb105ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPrO5O14mBBs8f6lk8mTaLzeLW0pWs DkweS5b8ZPI4enMucwBTFJdNSmpOZllqkb5dAlfGqxa/gvX1FbcWPWRtYLye18XIySEhYCKx Y/9zFghbTOLCvfVsXYxcHEICRxklHjx8ywrhLGeUODZpMlgVm4CBxJ7/XxhBbBEBLYkd0z8D dXBwMAsoS5y6KwNiCgOFn88qgajQltgxtYcJwnaSOHRyDpjNIqAq8eTpVbApvALeEi+fT4Ja dZVR4vPKs6wgCU4Bf4l3PUvAGhiBjvt+ag2YzSwgLnHryXwmiKMFJJbsOc8MYYtKvHz8jxXC Vpb4PucRC8Rp+RI3/ipB7BKUODnzCcsERtFZSCbNQqiahaQKokRHYsHuT2wQtrbEsoWvmWHs MwceMyGLL2BkX8XIUVqcWpabbmSwiREYT8ck2HR3MO55aXmIUZqDRUmcN4qrMVBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo21T20aV2hO3m6Vj1dl5fENqFq3LPlE04dj3CKH6J477N9W4 r2neuDI/w8PmlkfAlG+a8a2bt+VlayxyOsFy6a2kaFjq1bNrD4qtqz/783TuI/EdrQ683GKM x5RP91t8PWgYasuulcCnJC/OsLxpU00p1xvtP+r3RBhEtO8dy2PSclwSM3uOEktxRqKhFnNR cSIAFpLMzXUCAAA=
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] [MPLS] A doubt about RFC 6428
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: Mon, 13 May 2013 19:57:57 -0000

It is all in how you interpret "The length is the length of the following data."  Which is referring to the diagram above (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields.

If it said "The length is the length of the data following the length field"... it would be clearer.

Dave

________________________________
From: Alan Davey [mailto:Alan.Davey@metaswitch.com]
Sent: Thursday, May 09, 2013 3:59 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

Thank you very much for getting back to me so quickly.  I have a further question on RFC 6428 if you have another minute.

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length field is confusing because it is not clear if the length includes the AGI.  The text is currently as follows.

  The length is the length of the following data: the Global_ID, Node Identifier, and Attachment
   Circuit ID (AC_ID) are as per [9].

Am I correct in thinking that the Length field  is the length of the value fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2?  That is, should the text read as follows.

  The length is the length of the value fields.  The Global_ID, Node Identifier, and Attachment
   Circuit ID (AC_ID) are as per [9].

Thanks
Alan

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@tools.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Alan:

It is kind of implied, as in "received DOWN while NOT in a misconnectivity state". I'm not sure adding that to the state machine diagram would actually improve the clarity....I'll let others comment.

cheers
Dave

________________________________
From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org<mailto:rfc6428@tools.ietf.org>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>
Subject: [mpls] [MPLS] A doubt about RFC 6428
Folks

I have a doubt about RFC 6428.  Could you please let me know what you think of the following.

Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit from a mis-connectivity defect state occurs when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds".

However, the State Machines in section 3.7.5 have no input corresponding to an "Exit from a Mis-Connectivity Defect" timer pop.  (Although they do have a MIS-CONNECTIVITY input added by RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.

Should the State Machines be modified such that Down state following a MIS-CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity Defect" timer pop input or am I missing something?

Regards
Alan Davey

Network Technologies
Metaswitch Networks

alan.davey@metaswitch.com<mailto:alan.davey@metaswitch.com>
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<http://network-technologies.metaswitch.com/>