[mpls] Few comments on draft-ietf-mpls-tp-loss-delay-00

Nitin Bahadur <nitinb@juniper.net> Mon, 23 August 2010 17:43 UTC

Return-Path: <nitinb@juniper.net>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id BDB3D3A68F6 for <mpls@core3.amsl.com>; Mon, 23 Aug 2010 10:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id oZpI0TrlbYHv for <mpls@core3.amsl.com>; Mon, 23 Aug 2010 10:43:26 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com []) by core3.amsl.com (Postfix) with ESMTP id BBF943A68D8 for <mpls@ietf.org>; Mon, 23 Aug 2010 10:43:26 -0700 (PDT)
Received: from source ([]) (using TLSv1) by exprod7ob114.postini.com ([]) with SMTP ID DSNKTHKzXxv2U/DDYR69LyULJ+sDOAVRRMx7@postini.com; Mon, 23 Aug 2010 10:44:00 PDT
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 23 Aug 2010 10:40:14 -0700
From: Nitin Bahadur <nitinb@juniper.net>
To: "stbryant@cisco.com" <stbryant@cisco.com>, "danfrost@cisco.com" <danfrost@cisco.com>
Date: Mon, 23 Aug 2010 10:40:11 -0700
Thread-Topic: Few comments on draft-ietf-mpls-tp-loss-delay-00
Thread-Index: ActC6jwz7MiEIsleRU+1szF4PTl0Rw==
Message-ID: <C898008B.173EE%nitinb@juniper.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Few comments on draft-ietf-mpls-tp-loss-delay-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 23 Aug 2010 17:43:27 -0000

Hi Dan,

    I have a few comments on draft-ietf-mpls-tp-loss-delay-00...

In Section 3.1,

1)  In figure 2, the flags fields should be indicated inline with the figure to avoid confusion.
     The spec currently mentions “The flags, listed in left-to-right (most- to least-significant-bit) order”.
     IMO, it’s clearer to have the exact positions in the figure itself, to avoid some developer interpreting it
     the reverse way.

2)  The control code values for “response” are 0x1, 0x8. What about 0x2, 0x3, 0x4 and so on?

3) It’s not clear if the sequence number is 32-bits or 64-bits. Can you clarify someplace.

4) Session identifier is a 16-bit field....this might be short. It means that we are limited to OAM on 64K sessions
    at a time. Probably not an issue today, but maybe we should consider a bigger field for future scalability.

In Section 3.2,

1)  There is QTF, RTF and RPTF. Is there a need for all 3 fields? Can we just have
     STF (sender timestamp format) and SPTF (sender preferred timestamp format). That should be

2) As per the draft,

  >  The value of the first octet
  > of padding provides information about the padding.  If in a Query the
  > first bit of the first pad octet is 1, the padding SHALL be copied to
  > the response, assuming one was requested.  If this bit is 0, the
  > response MUST NOT include padding.  The remaining bits in the first
  > pad octet are reserved and SHALL be set to 0.

The packet format contains a message  length field. It should be easy to derive the length
of the padding based off that. Looking at pad data to determine what to do with the pad data looks
like a hack. We should introduce a new flag instead.

If you make the session-id (in Figure 2) 32-bits, and if you get rid of RTF (in Figure 3), then you can easily extend flag field
to 8-bits to make space for additional flag values (and get rid of the hack). Worst case, use a bit from the Reserved field
in Figure 3 to get rid of the hack.