[mpls] Review of draft-ietf-mpls-gach-adv-02

["Joel M. Halpern" <[e-mail]>]

(Sorry this is a day light.  Messy travel schedule.)
This document is clear, concise, and useful.
However, I do have some comments and questions.


The TLV structure is carefully laid out so that the Length is on a 16 
bit boundary, and the whole thing can be processed on 32 bit boundaries. 
  However, there is no requirement for padding or alignment on TLVs.  As 
such, implementations must allow for someone defining a TLV that takes 
an odd number of bytes, thus apparently removing all the advantage of 
the alignment care.

What is the point of the Message Identifier?  It is set by the sender as 
they please.  It is never sent back to the sender.  So the receiver can 
not do anything with it, since they have no idea how it was set.  And 
the sender can not do anything with it, since they sender never sees it 
again.  This field either needs more explaantion, or needs to be removed.

Section 4 on the G-ACh Advertisement Protocol TLVs starts by saying that 
the TLVS for the GAP protocol itself "represent metadata and processing 
instructions rather than static data that is meant to be retained."  But 
information like Source Address distinctly appears to be static data 
meant to be retained.  yes, it should be included in each GAP message. 
But it seems likely that the primary use of having the information would 
be based on retention / reuse.

In section 3, 4th paragraph, the text says
    The payload of a GAP message is an Application Data Block (ADB)
    consisting of one or more block elements.
But, the payload consists of a fixed header followed by the ADB.  Since 
this fixed header is not inherited from some other document, and is 
described here, the summary should mention it.

This one is probably obvious to folks who have been following the G-ACh 
work more closely, so it may not be a real issue.  The GAP Request TLV 
(section 4.2) asks for a response.  In an MPLS-TP network where, for 
example, the LSPs and their usage are provisioned, is the assumption 
that that the end-points know which LSP goes back to the end-point from 
which the request was received?  Such knowledge is presumably NOT on the 
basis of the Source Address field.  Is more explanation of this useful?

For the GAP Suppress TLV (section 4.4) I presume a length of 2 and a 
Duration of 0 would remove all previously specified suppressions?  It 
would seem this should be stated.
On a related note, why does this TLV need a duration?  Shouldn't the 
lifetime specified at the application level be sufficient?
Also, this is another example of Application 0 information that is retained.

If a receiver has data for application A, TLV A-X, and receives a new 
message with application A, lifetime 0, TLV A-X, is that normally an 
instruction to delete the stored information about A-X?

In order to avoid an argument about key management, would an exemplary 
(non-normative) reference to the karp keytables draft as a way the 
key-IDs and keys might be managed be useful?

In section 6.2, first paragraph, there should probably be a phrase 
noting that the Authentication data is set as described in the algorithm 
below.

Yours,
Joel M. Halpern