Application-Aware Targeted LDP
draft-ietf-mpls-app-aware-tldp-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-08-28
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-08-09
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-08-02
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-08-01
|
09 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2017-07-03
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-06-30
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-06-30
|
09 | (System) | IANA Action state changed to Waiting on Authors |
2017-06-29
|
09 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2017-06-28
|
09 | (System) | RFC Editor state changed to EDIT |
2017-06-28
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-06-28
|
09 | (System) | Announcement was received by RFC Editor |
2017-06-28
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2017-06-28
|
09 | Cindy Morgan | IESG has approved the document |
2017-06-28
|
09 | Cindy Morgan | Closed "Approve" ballot |
2017-06-28
|
09 | Cindy Morgan | Ballot writeup was changed |
2017-06-28
|
09 | Deborah Brungard | Ballot approval text was changed |
2017-06-27
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2017-06-27
|
09 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-09.txt |
2017-06-27
|
09 | (System) | New version approved |
2017-06-27
|
09 | (System) | Request for posting confirmation emailed to previous authors: Raveendra Torvi , Uma Chunduri , Santosh Esale , Kamran Raza , Luay Jalil |
2017-06-27
|
09 | Santosh Esale | Uploaded new revision |
2017-06-27
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2017-06-22
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation |
2017-06-22
|
08 | Ben Campbell | [Ballot comment] (I cleared my discuss. Alexey pointed out that the registration policies for unassigned ranges are explicitly mentioned in the table itself. Apologies, I … [Ballot comment] (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. |
2017-06-22
|
08 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2017-06-22
|
08 | Benoît Claise | [Ballot comment] Close to a DISCUSS, but in the end a COMMENT, assuming I don't know enough about tLDP. Let's have a discussion regardless. … [Ballot comment] 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. |
2017-06-22
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-06-22
|
08 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from No Record |
2017-06-21
|
08 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-06-21
|
08 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from No Record |
2017-06-21
|
08 | Adam Roach | [Ballot comment] 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 - … [Ballot comment] 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 |
2017-06-21
|
08 | Adam Roach | Ballot comment text updated for Adam Roach |
2017-06-21
|
08 | Eric Rescorla | [Ballot 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 [ … [Ballot 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? |
2017-06-21
|
08 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2017-06-21
|
08 | Warren Kumari | [Ballot comment] 1: Does this document really need 6 front page authors? 2: The shepherd writeup says: "We are aware of several intentions to implement … [Ballot comment] 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 ..." |
2017-06-21
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-06-20
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-06-20
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-06-20
|
08 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-06-19
|
08 | Ben Campbell | [Ballot discuss] This should be easy to fix, but needs to be fixed before the draft progresses: Section 7 establishes a new IANA registry under … [Ballot discuss] This should be easy to fix, but needs to be fixed before the draft progresses: Section 7 establishes a new IANA registry under the Label Distribution Protocol (LDP) Parameters page. Unless I missed something (which happens) it doesn't specify the registration policy as required by BCP26. Please see RFC 5226 section 4.1 for details. |
2017-06-19
|
08 | Ben Campbell | [Ballot comment] -General: When you use the word "application", is a person skilled in MPLS automatically going to think in terms of the sort of … [Ballot comment] -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. |
2017-06-19
|
08 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2017-06-19
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-06-19
|
08 | Alvaro Retana | [Ballot comment] 1. A pointer to the applications mentioned in the Introduction would be nice (FEC 128, rLFA, etc.) in first mention. 2. In Section … [Ballot comment] 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. |
2017-06-19
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-06-18
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-06-18
|
08 | Alexey Melnikov | [Ballot comment] I have a small list of issues that I think you should look at: LSR -- needs expansion in the Abstract, as it … [Ballot comment] 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". |
2017-06-18
|
08 | Alexey Melnikov | Ballot comment text updated for Alexey Melnikov |
2017-06-18
|
08 | Mirja Kühlewind | [Ballot comment] nits regarding use of normative language: 1) sec 2.2.: „Therefore, if the intersection of the sets of received and sent TA-Id is … [Ballot comment] 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. |
2017-06-18
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-06-16
|
08 | Deborah Brungard | Changed consensus to Yes from Unknown |
2017-06-16
|
08 | Deborah Brungard | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-06-16
|
08 | Deborah Brungard | Ballot writeup was changed |
2017-06-16
|
08 | Deborah Brungard | Ballot has been issued |
2017-06-16
|
08 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2017-06-16
|
08 | Deborah Brungard | Created "Approve" ballot |
2017-06-16
|
08 | Deborah Brungard | Ballot writeup was changed |
2017-06-09
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-06-08
|
08 | Yoav Nir | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Yoav Nir. Sent review to list. |
2017-06-08
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2017-06-08
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mpls-app-aware-tldp-08.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-mpls-app-aware-tldp-08.txt. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the TLV Type Name Space registry located on the Label Distribution Protocol (LDP) Parameters registry page at: https://www.iana.org/assignments/ldp-namespaces/ a single, new entry is to be registered as follows: Value: [ TBD-at-registration ] Description: Targeted Applications capability Reference: [ RFC-to-be ] We note that the authors have requested that the value assigned by the lowest available value after 0x050B. Second, in the Status Code Name Space registry also located on the Label Distribution Protocol (LDP) Parameters registry page at: https://www.iana.org/assignments/ldp-namespaces/ a single, new entry is to be registered as follows: Range/Value: [ TBD-at-registration ] E: Description: Session Rejected/Targeted Application Capability Mis-Match Reference: [ RFC-to-be ] IANA Question -> What is the value of E for this new status code? Third, a new registry is to be created called the LDP Targeted Application Identifier registry. The new registry will be located on the Label Distribution Protocol (LDP) Parameters registry page at: https://www.iana.org/assignments/ldp-namespaces/ There are initial registrations in the new registry and the rules for maintenance in the registry are as follows: Value Description Reference -------- ------------------------- --------------- 0x0000 Reserved [ RFC-to-be ] 0x0001 LDPv4 Tunneling [ RFC-to-be ] 0x0002 LDPv6 Tunneling [ RFC-to-be ] 0x0003 mLDP Tunneling [ RFC-to-be ] 0x0004 LDPv4 Remote LFA [ RFC-to-be ] 0x0005 LDPv6 Remote LFA [ RFC-to-be ] 0x0006 LDP FEC 128 PW [ RFC-to-be ] 0x0007 LDP FEC 129 PW [ RFC-to-be ] 0x0008 LDP Session Protection [ RFC-to-be ] 0x0009 LDP ICCP [ RFC-to-be ] 0x000A LDP P2MP PW [ RFC-to-be ] 0x000B mLDP Node Protection [ RFC-to-be ] 0x000C LDPv4 Intra-area FECs [ RFC-to-be ] 0x000D LDPv6 Intra-area FECs [ RFC-to-be ] 0x0001 - 0x1FFF Available for assignment by IETF Review 0x2000 - 0F7FF Available for assignment as first come first served 0xF800 - 0xFBFF Available for private use 0xFC00 - 0xFFFE Available for experimental use 0xFFFF Reserved [ RFC-to-be ] The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-06-02
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2017-06-02
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Yoav Nir |
2017-05-30
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Fernando Gont |
2017-05-30
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Fernando Gont |
2017-05-30
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ignas Bagdonas |
2017-05-30
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Ignas Bagdonas |
2017-05-26
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-05-26
|
08 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: mpls@ietf.org, draft-ietf-mpls-app-aware-tldp@ietf.org, mpls-chairs@ietf.org, db3546@att.com, loa@pi.nu Reply-To: ietf@ietf.org … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: mpls@ietf.org, draft-ietf-mpls-app-aware-tldp@ietf.org, mpls-chairs@ietf.org, db3546@att.com, loa@pi.nu Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Application-aware Targeted LDP) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Application-aware Targeted LDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-06-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Recent targeted LDP (tLDP) applications such as remote loop-free alternate (LFA) and BGP auto discovered pseudowire may automatically establish a tLDP session to any LSR in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC- label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC-label bindings over the session. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-app-aware-tldp/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2507/ https://datatracker.ietf.org/ipr/2796/ |
2017-05-26
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-05-26
|
08 | Deborah Brungard | Placed on agenda for telechat - 2017-06-22 |
2017-05-26
|
08 | Deborah Brungard | Last call was requested |
2017-05-26
|
08 | Deborah Brungard | Ballot approval text was generated |
2017-05-26
|
08 | Deborah Brungard | Ballot writeup was generated |
2017-05-26
|
08 | Deborah Brungard | IESG state changed to Last Call Requested from Expert Review |
2017-05-26
|
08 | Deborah Brungard | Last call announcement was generated |
2017-05-24
|
08 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-08.txt |
2017-05-24
|
08 | (System) | New version approved |
2017-05-24
|
08 | (System) | Request for posting confirmation emailed to previous authors: Raveendra Torvi , Uma Chunduri , Santosh Esale , Kamran Raza , Luay Jalil |
2017-05-24
|
08 | Santosh Esale | Uploaded new revision |
2017-02-07
|
07 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-07.txt |
2017-02-07
|
07 | (System) | New version approved |
2017-02-07
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Raveendra Torvi" , "Santosh Esale" , "Uma Chunduri" , "Kamran Raza" , "Luay Jalil" |
2017-02-07
|
07 | Santosh Esale | Uploaded new revision |
2017-01-20
|
06 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-06.txt |
2017-01-20
|
06 | (System) | New version approved |
2017-01-20
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Raveendra Torvi" , mpls-chairs@ietf.org, "Santosh Esale" , "Uma Chunduri" , "Kamran Raza" , "Luay Jalil" |
2017-01-20
|
06 | Santosh Esale | Uploaded new revision |
2016-10-10
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Bruno Decraene. |
2016-09-19
|
05 | Jonathan Hardwick | Closed request for Early review by RTGDIR with state 'No Response' |
2016-09-19
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Bruno Decraene |
2016-09-19
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Bruno Decraene |
2016-09-19
|
05 | Deborah Brungard | IESG state changed to Expert Review from Publication Requested |
2016-09-01
|
05 | Jonathan Hardwick | Assignment of request for Early review by RTGDIR to Martin Vigoureux was rejected |
2016-09-01
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Nabil Bitar |
2016-09-01
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Nabil Bitar |
2016-08-24
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Martin Vigoureux |
2016-08-24
|
05 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to Martin Vigoureux |
2016-07-26
|
05 | Loa Andersson | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. The MPLS WG requests that … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. The MPLS WG requests that Application-aware Targeted LDP draft-ietf-mpls-app-aware-tldp is published as an RFC on the Standards Track (PS) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of document should be Proposed Standard - the title page says: Intended Status: Proposed Standard. The document specifies protocol, protocl elements and procedurtes, so it should be publsihed as a Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract Some tLDP applications e.g. remote loop-free alternate (LFA) and BGP auto discovered pseudowires may establish a tLDP session to any LSR in a network. The LSR that initializes such a session has enough information to administratively control initiation of the session. The targetted LSR normally does not have the information necessary to control acceptance of the requested session. This document defines a mechanism to advertise and negotiate Targeted Applications Capability (TAC) during LDP session initialization. The targetted LSR is made aware of targeted applications through the TAC information. When this happens it can establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) Elements to advertise only necessary LDP FEC-label bindings over the session. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The wg process for this document has been fairly normal, and the working agree that this is a necessary extension to LDP for some applications. Discussion has been targetted on resolving a small number of outstanding issues. The consensus in the working are good. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? 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. No expert review outside the working group is necessary. Personnel Loa Andersson is the Document Shepherd. Deborah Brungard is the Responsible Area Director. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewd the document fully three times: - when the -00 individual version was posted - as part of adopting the document as a working group document - as part of preparing the document for wglc - a scoped review (including IANA section) was done as part of preparing the publication request. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No such concerns, the document has been reviewed by the working group (at wgap and wglc), it has been reviewed by the mpls-rt and wg chair/shepherd. Each of the reviews have resulted on comments that depending on the nature been addressed on (technical) or off (editorial) the list (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No such conserns. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. All the authors have stated on the working group list that they are not aware of any IPRs other than those that has been disclosed through the IETF process. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. The IETF IPR pages lists two IPRs disclosed against this dcoument, in reality it is only IPR that has been updated as the dicument changed file-name when accepted as a wg doc. The MPLS WG makes the working group aware of existing IPRs at working group adoption and working group last call. We ask if there are any concerns about the IPR, i.e. silence is interpreted as accepting the conditions in the IPR disclosure. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? It is very solid, this is something that is needed in MPLS networks using LDP. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threats! (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document passes nits tool clean. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews neweded. (13) Have all references within this document been identified as either normative or informative? Yes, the references are correctly split into normative and informative refernces. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? All the normative refrences are to existing standard tracks RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No downwad references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. There will be no changes of status for any RFCs when this document is published. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The Document Shepherd has reviewed the IANA section several times, it is clear and well-written. There is one small issue that I'm currently clearing with IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No such registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No other automated reviewa than nits tool is necessary. |
2016-07-26
|
05 | Loa Andersson | Responsible AD changed to Deborah Brungard |
2016-07-26
|
05 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-07-26
|
05 | Loa Andersson | IESG state changed to Publication Requested |
2016-07-26
|
05 | Loa Andersson | IESG process started in state Publication Requested |
2016-07-17
|
05 | Loa Andersson | Changed document writeup |
2016-07-12
|
05 | Loa Andersson | Changed document writeup |
2016-06-02
|
05 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG cleared. |
2016-06-01
|
05 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-05.txt |
2016-05-31
|
04 | Loa Andersson | Tag Revised I-D Needed - Issue raised by WG set. |
2016-05-31
|
04 | Loa Andersson | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2016-05-16
|
Maddy Conner | Posted related IPR disclosure: Juniper Networks, Inc.'s Statement about IPR related to draft-ietf-mpls-app-aware-tldp | |
2016-05-06
|
04 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-04.txt |
2016-03-18
|
03 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-03.txt |
2016-02-17
|
02 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-02.txt |
2015-10-14
|
01 | (System) | Notify list changed from "Loa Andersson" to (None) |
2015-08-20
|
01 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-01.txt |
2015-03-02
|
00 | Loa Andersson | Notification list changed to "Loa Andersson" <loa@pi.nu> |
2015-03-02
|
00 | Loa Andersson | Document shepherd changed to Loa Andersson |
2015-02-22
|
00 | Tarek Saad | Intended Status changed to Proposed Standard from None |
2015-02-17
|
00 | Loa Andersson | This document now replaces draft-esale-mpls-app-aware-tldp instead of None |
2015-02-17
|
00 | Santosh Esale | New version available: draft-ietf-mpls-app-aware-tldp-00.txt |