Application-Aware Targeted LDP
draft-ietf-mpls-app-aware-tldp-09

1: Does this document really need 6 front page authors? 

2: The shepherd writeup says: "We are aware of several intentions to implement this secification. An implementation poll has been sent to the working group and as further information is received, the write-up will be updated." -- was any further info received? 

3: The shepherd writeup also says: "There is one small issue that I'm currently clearing with IANA." -- is this the value of the status code E bit? Or some other issue?

Nits:
1: There are are a number of unexpanded acronyms -- e.g: LSP is no "well known" - https://www.rfc-editor.org/materials/abbrev.expansion.txt

2: Sec 1  Introduction
"LDP uses extended discovery mechanism to establish..." - "LDP uses *the* extended discovery mechanism" (or discovery *mechanisms*)

3: Sec 1  Introduction
 "An LSR initiates extended discovery... " - "A LSR..." ("An Label Switch" wouldn't make much sense)

4: Sec 1  Introduction
"In addition, since the session is initiated and established after adjacency formation, the responding LSR has no targeted applications information to choose the targeted application" - "has no targeted applications information available to choose which targeted application".

5: Sec 1  Introduction
"Also, targeted LDP application is mapped .." - "Also, the targeted LDP application is mapped"

6: Sec 1.2 Terminology
"This document uses terminology discussed in [RFC7473] along with others defined in this document." feels clumsy. How about:
"In addition to the terminology defined in [RFC7473], this document uses the following terms: "

7: Sec 2.1 Encoding
"An LSR MAY advertise that it is capable to negotiate a targeted LDP ..." - "An LSR MAY advertise that it is capable of negotiating a targeted LDP ..."

Please expand the following acronyms upon first use and in the title;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

 - LSR - Label Switching Router
 - mLDP - Multipoint LDP
 - PQ - Unknown
 - TAI - Unknown
 - RSVP-TE - RSVP - Traffic Engineering
 - P2MP - Point-to-Multipoint
 - PW - pseudowire
 - P2P-PW - Peer-to-peer Psuedowire (presumably?)
 - MP2MP - Multipoint-to-Multipoint
 - HSMP - Unknown
 - LSP - Label Switched Path
 - MP2P - Unknown (should this be P2MP?)
 - MPT - Unknown

I have a small list of issues that I think you should look at:

LSR -- needs expansion in the Abstract, as it is not an abbreviation recognized by RFC Editor.

In 2.2

  If the receiver LSR does not receive the TAC TLV 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].

Firstly, you can't have requirements on any implementation that doesn't support this specification. Secondly, the last MUST is already the default. So I think use of RFC 2119 lange here is not appropriate, you should just use "is considered" and "proceeds".

The following text:

If it sets the session setup retry interval to maximum, the session MAY stay in a non-existent state. When this LSR detects a change in the responding LSR configuration or its own configuration pertaining to TAC TLV, it MUST clear the session setup back off delay associated with the session in order to re-attempt the session establishment.

is repeated twice in the same section.

What is "TAI"?

In 5.2: the section is titled "Use Cases", so I didn't expect any normative RFC 2119 language in there. Some MAY seem not to be specifying implementation choices, so they should be "may".

1. A pointer to the applications mentioned in the Introduction would be nice (FEC 128, rLFA, etc.) in first mention.

2. In Section 2.2 (Procedures):

2.1. "The TAC TLV's Capability data MAY consists of none, one or more TAE each pertaining to a unique TA-Id that a LSR supports over the session." If there is no TAE, how can it be related to a TA-Id?  Also, I think that the "MAY" in this case is just stating a fact, so it should be "may".

2.2. "For instance, if the tLDP session is established for BGP auto discovered pseudowire, only FEC 129 label bindings MUST be distributed over the session."  That "MUST" shouldn't be in caps because it is part of an example.

2.3. TAI is used instead of TA-Id twice at the end of the section.

(I cleared my discuss. Alexey pointed out that the registration policies for unassigned ranges are explicitly mentioned in the table itself. Apologies, I missed that.)

-General:  When you use the word "application", is a person skilled in MPLS automatically going to think in terms of the sort of "applications" listed here? If not, it would be good to have a paragraph early in the introduction that describes what you mean by "applications". As an application-layer person, I tend to think of it in terms of application-layer applications. Am I correct to assume that it would not make sense to register, for example, HTTP in the the LDP Targeted Application Identifier registry?

- 1.1: I noticed a number instances of at least "may" in lower case. If your intent is that lower case words not be treated as keywords, please consider using the new boilerplate from RFC 8174

Nits:

-1, first paragraph: "LDP uses extended discovery mechanism..."
Missing article before "discovery".

-2.2, paragraph 4 and 5, "... a maximum value, as 0xffff.": should "as" be "such as"?

-2.2, paragraphs 6 and 7: the "it" in the opening sentence of each paragraph has an unclear antecedent.

Close to a DISCUSS, but in the end a COMMENT, assuming I don't know enough about tLDP.
Let's have a discussion regardless.

   This document
   defines a mechanism to advertise and negotiate Targeted Applications
   Capability (TAC) during LDP session initialization.

...
   This document proposes and describes a solution to advertise Targeted
   Application Capability (TAC), consisting of a targeted application
   list, during initialization of a tLDP session. 

...
   An LSR MAY advertise that it is capable to negotiate a targeted LDP
   application list over a tLDP session by using the Capability
   Advertisement as defined in [RFC5561] and encoded as follows:

...
   At tLDP session establishment time, a LSR MAY include a new
   capability TLV, TAC TLV, as an optional TLV in the LDP Initialization
   message.


Reading the doc., I've been wondering for many pages now. Do we speak negotation ...
From the initiating LSR: these are the Targeted Application (Identifier(s)) for which I would like to initializate a tLDP
	Answer from the responding LSR: yes, possible. No, not possible
	Question: is the tLDP session established.
	
From the initiating LSR: from this list, tell me which Targeted Application (Identifiers) you support 
	Answer from the responding LSR: here are the Targeted Application (Identifiers) I support

From the receiving LSR: here are the Targeted Application (Identifiers) I support
 
Throughout the doc, clarify if the LSR is the initiating or receiving party.
As a starting point, this text should be updated:

       At tLDP session establishment time, a LSR MAY include a new
       capability TLV, TAC TLV, as an optional TLV in the LDP Initialization
       message.

LSR => initiating LSR.

Oh, wait, then I've been confused with: "If both the peers advertise TAC TLV,"
So both can start the negotiation? 

Then you speak about "the responding LSR playing the active role in LDP session"
So it's not about initiating/responding LSR any longer.

A small diagram with arrows, at least for the most common case, would go a long way.

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?

nits regarding use of normative language:

1) sec 2.2.: „Therefore, if
   the intersection of the sets of received and sent TA-Id is null, then
   LSR MUST send 'Session Rejected/Targeted Application Capability Mis-
   Match' Notification message to the initiating LSR and close the
   session.“
Probably no need to make this normative MUST again in the example text
-> s/MUST send/sends/

2) Similar the use of normative language in the use case section (5) does not seem to be appropriate, or at least not consistent. Maybe just convert all upper cases MAYs to lower case in that section.