[mpls] Eric Rescorla's No Objection on draft-ietf-mpls-app-aware-tldp-08: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-mpls-app-aware-tldp-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-mpls-app-aware-tldp-00.txt

   LDP can use the extended discovery mechanism to establish a tLDP
   adjacency and subsequent session as described in [RFC5036]. An LSR

Please expand LDP and tLDP on first use. Also, I don't see tLDP in
RFC 5037 despite the citation


S 2.1.
       A Targeted Applications Capability data consists of none, one
       or more 32 bit Targeted Application Elements. Its encoding is
       as follows:

This is ungrammatical. Is it intended to say "zero or more"?

S 2.2.
   If the receiver LSR does not receive the TAC in the Initialization
   message or it does not understand the TAC TLV, the TAC negotiation
   MUST be considered unsuccessful and the session establishment MUST
   proceed as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR
   MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids
   that it supports over the tLDP session. If there is at least one TAE
   common between the TAC TLV it has received and its own, the session
   MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST
   send a 'Session Rejected/Targeted Application Capability Mis-Match'
   Notification message to the peer and close the session. The
   initiating LSR SHOULD tear down the corresponding tLDP adjacency
   after send or receipt of a 'Session Rejected/Targeted Application
   Capability Mis-Match' Notification message to or from the responding
   LSR respectively.

This seems like odd semantic: if I don't understand the TLV, I continue
with session establishment, but if I understand it but there's no overlap
I close the session?


   instance, suppose a initiating LSR advertises A, B and C as TA-Ids.
   Further, suppose the responding LSR advertises C, D and E as TA-Ids.
   Than the negotiated TA-Id, as per both the LSRs is C. In the second
   instance, suppose a initiating LSR advertises A, B and C as TA-Ids
   and the responding LSR, which acts as a passive LSR, advertises all
   the applications - A, B, C, D and E that it supports over this
   session. Than the negotiated targeted application as per both the

Should this say "applications"? It seems like you're just computing
intersection.

   If the Targeted Application Capability and Dynamic Capability, as
   described in [RFC5561], are negotiated during session initialization,
   TAC MAY be re-negotiated after session establishment by sending an
   updated TAC TLV in LDP Capability message. The updated TAC TLV
   carries TA-Ids with incremental update only. The updated TLV MUST
   consist of one or more TAEs with E-bit set or E-bit off to advertise
   or withdraw the new and old application respectively. This may lead
   to advertisements or withdrawals of certain types of FEC-Label
   bindings over the session or tear down of the tLDP adjacency and
   subsequently the session.

So, advertisements are cumulative? If I advertise A, B and then C,
that means I do A, B, C?