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

Alan Davey <Alan.Davey@metaswitch.com> Tue, 21 May 2013 08:23 UTC

Return-Path: <Alan.Davey@metaswitch.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 F36F621F9793 for <mpls@ietfa.amsl.com>; Tue, 21 May 2013 01:23:46 -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 d0-825EPKXyb for <mpls@ietfa.amsl.com>; Tue, 21 May 2013 01:23:41 -0700 (PDT)
Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id BADB321F9636 for <mpls@ietf.org>; Tue, 21 May 2013 01:23:40 -0700 (PDT)
Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 09:23:27 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Tue, 21 May 2013 09:23:35 +0100
From: Alan Davey <Alan.Davey@metaswitch.com>
To: David Allan I <david.i.allan@ericsson.com>
Thread-Topic: [MPLS] A doubt about RFC 6428
Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQAF5nPeQ
Date: Tue, 21 May 2013 08:23:35 +0000
Message-ID: <C2EE31C852049D499842B19FC01C0804C1A901F6@ENFICSMBX1.datcon.co.uk>
References: <C2EE31C852049D499842B19FC01C0804C1A8C004@ENFICSMBX1.datcon.co.uk> <E6C17D2345AC7A45B7D054D407AA205C097D0A@eusaamb105.ericsson.se> <C2EE31C852049D499842B19FC01C0804C1A8CD51@ENFICSMBX1.datcon.co.uk> <E6C17D2345AC7A45B7D054D407AA205C09B253@eusaamb105.ericsson.se>
In-Reply-To: <E6C17D2345AC7A45B7D054D407AA205C09B253@eusaamb105.ericsson.se>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.18.71.124]
Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1A901F6ENFICSMBX1datco_"
MIME-Version: 1.0
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: Tue, 21 May 2013 08:23:47 -0000

Hi Dave

Thank you for your response.  I think that it is worth raising an erratum for section 3.5.3 because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

I propose the following.

Section 3.5.3

Original text:

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

Corrected text:

   The length is the length of the data following the length field.
   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: 13 May 2013 20:58
To: Alan Davey
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

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<mailto: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<mailto:rfc6428@tools.ietf.org>
Cc: mpls@ietf.org<mailto: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/>