Multi Protocol Label Switching Label Distribution Protocol Query Message Description
draft-ietf-mpls-lsp-query-09

IESG feedback:

RH (DISCUSS):
> I do not like the Abstract.  I propose:

>      This document describes the encoding and procedures for three
>      new Label Distribution Protocol (LDP) messages: Query Message,
>      Query-Reply Message and Partial Query-Reply Message. A Label
>      Edge Router (LER) sends a Query message when it needs information
>      about an established Label Switched Path (LSP). The Query message
>      can be used to request information about LDP LSPs as well as
>      Constraint-Based Label Switched Paths (CR-LSPs). The response to
>      the query is encoded into the Query-Reply and Partial Query-Reply
>      messages.

> The Introduction should be rewritten so that is does not depend on the
> Abstract to define terms.

AZ: OK, will work with the authors.

> In the security considerations, the document says:

>      The Query mechanism inherits the same security mechanism
>      described in Section 4.0 of [4].

> Section 4.0 of RFC 3036 is the IANA Considerations!  I assume that Section
> 5 should have been referenced.

AZ: Ditto

> Section 5 of RFC 3036 also said that the peers need to be trusted to label
> properly.  What are the impacts on these new protocol messages if this
> trust is misplaced?  This topic should be discussed in the security
> considerations section.

AZ: What do you mean by "trust is misplaced"? That we mistakenly trust a
compromised peer?

RH: If a peer does mislabel, what are the consequences?  Can an inappropriately
labeled message cause a bad state?  And, if so, will this bad state be
passed on to other peers.

SMB (DISCUSS):
> This text from Section 7 doesn't make sense to me:
>
>    If the
>    Reply message is full, TCP will take care of it by segmenting and
>    re-assembling the message.
>
> What does it mean for a Reply message to be full?  The obvious answer
> is that the reply is longer than the 2^16 bytes permitted by the
> Message Length field (btw, the definition of it should state explicitly
> whether the length field and the preceeding two bytes are counted in
> the length.  I suspect not, but it should be stated more clearly.).
> But if the message is too long for that, TCP can't possibly help.  If
> it's not a 2^16 bytes issue, what does the sentence mean?
>
> Why is a 1-byte hop count encoded as a TLV?  (Do we really need 2^15
> possible query types?  Perhaps the hop count should go there.)
>
> I'm sure I'm missing something obvious, but what is the ultimate
> destination of Query messages?  Is it in the Query TLV?  But the draft
> suggests that a new label is swapped in at each hop. 

TH (NO-OB with comments):
> In general I think the document is weak on how this will be used.
> I think it  would be very useful to describe what use these
> responses will be if some of the data is missing;  that is, if I
> have an LSP with 18 LSRs,  one of which honors the U bit,
> what can I make of the data from the ones which report?
> If 3 are configured not to return data?  If 5 return partial
> data?
>
> It looks like recommending setting the U bit to 0
> with this would be a reasonable thing to do, as at least then you know
> where the query crapped out.
>
> In 6.1, 7.1  and 8.1, "last-in-fist-out" should be "last-in-first-out".
>
> PHP is used without expansion (penultimate hop-popping, from the description).

HTA (NO-OB with question):

what are the possible interactions with MPLS load-balancing?