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/13.4.0.100208
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
Precedence: list

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 figur=
e to avoid confusion.
     The spec currently mentions =93The flags, listed in left-to-right (mos=
t- to least-significant-bit) order=94.
     IMO, it=92s 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 =93response=94 are 0x1, 0x8. What about 0x2=
, 0x3, 0x4 and so on?

3) It=92s not clear if the sequence number is 32-bits or 64-bits. Can you c=
larify someplace.

4) Session identifier is a 16-bit field....this might be short. It means th=
at 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 ju=
st have
     STF (sender timestamp format) and SPTF (sender preferred timestamp for=
mat). That should be
     sufficient.

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 de=
rive 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.

Thanks
Nitin