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

[Stewart Bryant <[e-mail]>]

On 16/06/2012 19:59, Joel M. Halpern wrote:
> (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.
>
This is a good point. The IETF tends to align align fields and forgets 
that the most common
datalink header is 14bytes.

The existing TLVs do not need padding. Reserved fields have proved useful in
protocols in the past, and thus it seems unwise to remove them. I propose
leaving the text as is, but if other feel strongly that we need to make 
a change
here we will do so during the next review period.

> 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.
Later in the section it says:

In some cases additional reliability may be desired for the delivery of 
a GAP message. When this is the case, the RECOMMENDED procedure is to 
send three instances of the message in succession, separated by a delay 
appropriate to the application. This procedure SHOULD be used, if at 
all, only for messages that are in some sense exceptional; for example 
when sending a flush instruction following device reset.

I have added the following sentence:
"The MI may be used to detect and discard duplicate messages."

>
> 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.
Flush and Suppress are action messages that are not intended to be retained.

Source and Authentication only have the scope of the message that they 
are sent in, although
one could argue that that source is of use to the applications and 
should in any case
be retained until the next message is received to note a change in 
sender. It is arguable as to
whether this is retention or short term operation of the state machine.

However the point here is that the TLVs used to operate the GAP itself 
are ephemeral and hence
I think the preamble is correct.

>
> 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.
It now says:

A Gap message consits of a fixed header followed by a GAP payload. The 
payload of a GAP message is an Application Data Block (ADB) consisting 
of one or more block elements.....

>
> 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? 
In P2P MPLS-TP the relationship between the LSP pair is known. This is 
discussed
in the MPLS-TP architecture.

P2MP is more complex, but we have not finished it's architecture and 
thus it is premature
to comment on that.

> Such knowledge is presumably NOT on the basis of the Source Address 
> field.  Is more explanation of this useful?
I think that if you are implementing this in an MPLS-TP case you know 
this, however
if you are operating in a non-MPLS-TP environment, you may well use SA 
to construct
the response, but again the implementer would know this.

The key point here is that the implementer knows the context and can 
work out
how to make this work without  us enumerating the set context that we
currently have in mind.

>
> 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? 
I have added

A duration of zero cancels any existing suppress requests for the listed 
applications.
> 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?
The application lifetime is the sender saying how long the data is 
valid. The suppress
duration the receiver saying don't remind me (perhaps because it 
currently does not
care to receive information about that application).

> Also, this is another example of Application 0 information that is 
> retained.
It is still semi-ephemeral rather than permanent, and I think that is 
the distinction.
>
> 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?
Yes, this is an execute immediate protocol so the data would be 
overwritten on receipt of the
the TLV and immediately marked timed out.

The text now says:

The Lifetime field specifies how long, in seconds, the receiver should 
retain the data in this message. If the lifetime is zero the data is 
immediately marked as expired.

>
> 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?
I have added

Implementors SHOULD consider the use of 
[ID.draft-ietf-karp-crypto-key-table]
for key management.

the ref is informative
>
> 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.
>
It already says:
The sender then computes a hash for the message as described below, and 
fills the Authentication Data field of the GAP Authentication TLV with 
the hash value. The message is then sent.

but I will put in a refence to section 6.3 to make it clearer

Thank you for your comments

- Stewart

> Yours,
> Joel M. Halpern
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html