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

From: Nitin Bahadur <[email-masked]>
Date: Mon, 23 Aug 2010 10:40:11 -0700

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
     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 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.

Thanks
Nitin