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

[Stewart Bryant <[e-mail]>]

On 23/08/2010 18:40, Nitin Bahadur wrote:
> 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.
OK - we will fix

> 2)  The control code values for “response” are 0x1, 0x8. What about 0x2, 0x3, 0x4 and so on?
We split the assignments up into response groups (Success, notification, 
error), but we can revisit these details as the draft progresses, and WG 
consensus develops.

> 3) It’s not clear if the sequence number is 32-bits or 64-bits. Can you clarify someplace.
Figure 2 shows this as 64bits and the table below says

Sequence Number       64-bit sequence number, incremented for each
                          message

However we will note that it is 64bits in the figure.

> 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.
Please note that this is 64K per LSP, and if you are running PW over LSP 
it is 64K per PW. This seems to us to be sufficient, but if there is WG 
consensus that we need to increase this we can of course do so.
> 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.
The format that we described allows us to describe the two formats 
actually used and to negotiate a preferred format in a single message 
exchange.
If you just use STF and SPTF we have no way of recoding in the message 
the format that was used by the responder in a two way measurement.
> 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.
Yes, but we do not have many flags available. However we are forming the 
view that we need to
add optional TLVs to the packet, in which case we would use a bit to 
indicate the presence of the
TLVs and we would propose that padding be moved to a TLV.

Our thoughts with the original approach was that if a LSR needed to copy 
the padding it would need
to get hold of the padding bytes, thus the do-not-copy case was an 
aborted copy rather than an
operation in its own right.

> 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.
We are looking at ways to accommodate the additional information needed 
by the protocol.
> Thanks
> Nitin
>

Thanks for this helpful review.

Dan and Stewart (replying as an author)