Application-Aware Targeted LDP
Note: This ballot was opened for revision 08 and is now closed.
Deborah Brungard Yes
(Alia Atlas) No Objection
Ben Campbell (was Discuss) No Objection
Comment (2017-06-22 for -08)
(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.
(Benoit Claise) No Objection
Comment (2017-06-22 for -08)
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.
Alissa Cooper No Objection
Spencer Dawkins No Objection
Suresh Krishnan No Objection
Warren Kumari No Objection
Comment (2017-06-21 for -08)
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 ..."
Mirja Kühlewind No Objection
Comment (2017-06-18 for -08)
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.
Terry Manderson No Objection
Alexey Melnikov No Objection
Comment (2017-06-18 for -08)
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".
(Kathleen Moriarty) No Objection
Eric Rescorla No Objection
Comment (2017-06-21 for -08)
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?
Alvaro Retana No Objection
Comment (2017-06-19 for -08)
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.
Adam Roach No Objection
Comment (2017-06-21 for -08)
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