Early Review of draft-ietf-mpls-app-aware-tldp-05
review-ietf-mpls-app-aware-tldp-05-rtgdir-early-decraene-2016-10-10-00
| Request | Review of | draft-ietf-mpls-app-aware-tldp |
|---|---|---|
| Requested rev. | no specific revision (document currently at 09) | |
| Type | Early Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2016-10-10 | |
| Requested | 2016-09-01 | |
| Authors | Santosh Esale, Raveendra Torvi, Luay Jalil, Uma Chunduri, Kamran Raza | |
| Draft last updated | 2016-10-10 | |
| Completed reviews |
Rtgdir Early review of -05 by Bruno Decraene
(diff)
Secdir Last Call review of -08 by Yoav Nir (diff) |
|
| Assignment | Reviewer | Bruno Decraene |
| State | Completed | |
| Review | review-ietf-mpls-app-aware-tldp-05-rtgdir-early-decraene-2016-10-10 | |
| Reviewed rev. | 05 (document currently at 09) | |
| Review result | Has Issues | |
| Review completed: | 2016-10-10 |
Review
review-ietf-mpls-app-aware-tldp-05-rtgdir-early-decraene-2016-10-10
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-app-aware-tldp-05.txt Reviewer: Bruno Decraene Review Date: 2016/10/10 IETF LC End Date: not started (AFAIK) Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: Draft is well readable. But I feel that it could be even more precise on normative behaviors (cf minor comments). Preliminary info: - I'm not a LDP expert. Unfortunately, this may become apparent in the below comments. So you are welcome to disagree and provide the information and reasoning that I may be missing. - Given that the required IANA code points have not been pre-allocated, I am assuming that no implementation of this document exists. Hence I'm not restricting my comments to minor comments. Major Issue: Abstract and Shepherd Write-Up defines the goal of the solution as advertising the purpose for sending this tLDP session request to the tLDP receiver, such that the receiver has enough information to decide to either accept or deny it. I don't feel that the solution perfectly matches this purpose. First the solution requires that both ends of the tLDP session negotiate the _same_ set of applications. I don't see why this is needed to achieve the above goal. Plus I find this problematic for some applications with asymmetric requirements (e.g. RLFA), in particular for incremental deployment of future asymmetric application. (more comments on this in the minor issues) In addition, I don't see how the additional FEC filtering helps fulfilling this goal. I also find it redundant with RFC 7473. I also don't think that this FEC filtering should be symmetrical (e.g. RLFA application). In short, I would have made the TAI advertisement asymmetric, and removed the FEC filtering. Finally, if the goal is to allow the receiver to limit incoming tLDP sessions, presumably for scalability purpose, if one application is allowed and hence the tLDP session is set up, what would be the reason to limit the applications exchanged over this session? IOW, why limiting the applications to the intersection of both advertised and received set of application? Note that §5.3 lightly refers to this problem, but in a very application specific way (and not really normative), while the consequences could probably be made general. Especially given the pre-existence of RFC 7473 which can be used to limit the FEC advertisements. Minor Issues: §6 "Security considerations" TAC negotiation seems to allow an entity to remotely discover the targeted LDP applications running on a remote node. This is a new security consideration which should probably be discussed. Also, given that multiple applications maps to the same FEC, two peers in different ASes could try to cheat, by successively trying multiple applications mapping to the same FEC. (e.g. if I want IPv4 FEC mapping, I would try with "LDPv4 Tunneling", then "LDPv4 Remote LFA", then "IPv4 intra-area FECs", then possibly "LDP session Protection"). This is also not discussed. ---- §7 "IANA Considerations" "0x0001 - 0x1FFF Available for assignment by IETF consensus" According to https://tools.ietf.org/html/rfc5226#section-4.1 "IETF Review" is the new name for "IETF consensus" "0x7FFF - 0xFFFE Available for vendor specific private use" - This look like a very large range for a private use (half of the registry) - "vendor specific private use" is not a Well-Known IANA Policy as defined in https://tools.ietf.org/html/rfc5226#section-4.1 . Is there any definition of this Policy or should you describe it? How is code-point collision supposed to be avoided in deployments? (I'm guessing that this is coming from RFC 5036 IANA section, but RFC5036 seems to have a "vendor-ID" field to differentiate vendors, which is not the case of this document.) On my side, I'd rather provision 2 very small pools for experimental and private-use. (i.e. private to the user/ the network provider.) ---- §1 "Introduction" "Applications such as Remote LFA and BGP auto discovered pseudowire automatically initiate asymmetric extended discovery to any LSR in a network based on local state only." I agree that Remote LFA is asymmetric. I've not been following the work on BGP auto-discovery, but I would have a priori assumed that both tLDP end points are running BGP autodiscovery and hence the discovery is symmetric. ---- §2.1 "Encoding" "Targeted Application Identifier (TA-Id): a 16 bit Targeted Application Identifier value." According to the figure just above, the field seems to only have 15 bits. (As bit 0 is used for the E-bit). If so the IANA registry would also need to be modified. Otherwise, the figure needs to be fixed. ---- §2.2 "Procedures" "The TAC TLV's Capability data MUST consists of none, one or more TAE" :s/MUST/MAY ? (otherwise, It's not clear to me what is the mandated behavior since all possible behaviors seems allowed) ---- §1 "For an application such as FEC 128 pseudowire, the remote LSR is configured with the source LSR address so that it can use that information to accept or ignore given tLDP Hello. Applications such as Remote LFA and BGP auto discovered pseudowire automatically initiate asymmetric extended discovery to any LSR in a network based on local state only. With these applications, the remote LSR is not explicitly configured with the source LSR address. So the remote LSR either responds or ignores all tLDP Hellos." The introduction seems to imply that this document would give a remote peer additional information in order to accept or ignore tLDP hello. My limited understanding of LDP capability is that they are exchanged in Initialization and Capability messages, i.e. not in Hello message. Hence it's not clear to me how this document helps the remote LDP speaker in deciding to accept or ignore tLDP hello. ---- §2.2 " 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]." I'm not sure this is “as per [RFC5036]” since this document defines additional rules to define which FEC mapping needs to be advertised, and whether or not to accept the session. --- §2.2 "The TAC TLV's Capability data MUST consists of none, one or more TAE" It's not clear to me what is the use case to advertise none TAE, given that in this case, the intersection of the received and sent TA-Id will be null and hence the tLDP session will be closed by any of the tLDP speakers. --- §2.2 "If the receiver LSR receives an unknown TA-Id in the TAE, it MUST silently ignore such a TAE and continue processing the rest of the TLV." Assuming the receiver (node A) supports Non Stop Routing and is upgraded to support a new TA-Id should it check for the previously received TAE that it has silently ignored or does the speaker (node B) supposed to re-send all it's TA-ID if it receive new TA-Id from node A? My reading of the end of section 2.2 is that in this case the receiver must checked from previously received TAE. May be :s/receives/received would be enough to address this case. Or preferably adding a sentence. --- §2.2 "In the last instance, suppose the initiating LSR advertises A, B and C as a TA-Ids and the responding LSR advertises D and E as TA-Ids, than the negotiated targeted applciations as per both the LSRs are none. The Responding LSR sends 'Session Rejected/Targeted Application Capability Mis-Match' Notification message to the initiating LSR and may close the session." I'd prefer having normative text stating the required behavior rather than having an example. i.e. I'm looking for a text similar to "If the intersection of the sets of received and sent TA-Id is null, then LSR MUST sends 'Session Rejected/Targeted Application Capability Mis-Match' Notification message to the initiating LSR and close the session." or :s/MUST/SHOULD or :s/MUST/MAY as you wish --- §2.2 "If it sets the session setup retry interval to maximum, the session MAY stay in a non-existent state." If this refers to the LDP FSM, RFC 5036 used the term "NON EXISTENT" rather than "non-existent" --- §2.1 This section mixes copy of previous specifications (e.g. RFC 5561) with the new specification. Personally, I'd prefer that the document be clear on the part which are reused unchanged and the part which are new specification. In general, I personally don't think that this is a good practice, as it becomes unclear which document is the normative definition. And in particular in this document, there is a copy/paste error during the copy from RFC 5561, so it my be unclear if the goal is to redefine RFC 5561 or not. ("Typ" field has been increased by 1 bit and the "Length" has been decreased by 1 bit) I would propose the following change: OLD: 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]. A new optional capability TLV is defined, 'Targeted Application Capability (TAC)'. Its encoding is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Targeted App. Cap.(IANA)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ | | | ~ Targeted App. Cap. data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As described in [RFC5561] U: set to 1. Ignore, if not known. F: Set to 0. Do not forward. S: MUST be set to 1 or 0 to advertise or withdraw the TAC TLV respectively. Targeted Application Capability data: A Targeted Applications Capability data consists of none, one or more 32 bit Targeted Application Elements. Its encoding is as follows: Targeted Application Element(TAE) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Targ. Appl. Id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Targeted Application Identifier (TA-Id): a 16 bit Targeted Application Identifier value. E-bit: The enable bit indicates whether the sender is advertising or withdrawing the TAE. The E-bit value is used as follows: 1 - The TAE is advertising the targeted application. 0 - The TAE is withdrawing the targeted application. The length of TAC depends on the number of TAEs. For instance, if two TAEs are added, the length is set to 9. NEW 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: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| TLV Code Point | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ Capability Data | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document defines a new optional capability TLV of type TBD1 called 'Targeted Application Capability (TAC)'. Flag "U" MUST be set to 1 to indicate that this capability must be silently ignored if unknown. It's encoded as follows: Targeted Application Element(TAE) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Targ. Appl. Id | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Targeted Application Identifier (TA-Id): a 16 bit Targeted Application Identifier value. E-bit: The enable bit indicates whether the sender is advertising or withdrawing the TAE. The E-bit value is used as follows: 1 - The TAE is advertising the targeted application. 0 - The TAE is withdrawing the targeted application. --- §2.2 "If the tLDP session changes to link session, a LSR should withdraw it"... :s/should/SHOULD ..."with S bit set to 0, which indicates wildcard withdrawal of all TAE elements." Where is this behavior defined? My reading of RFC5036 is that sending the capability with the S bit set to 0 means withdrawing the capability. In which case this documents states that "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]." i.e. the tLDP sessions stays up. This is not the same as "wildcard withdrawal of all TAE elements" which means that the TAC capability is advertised with no TA-Id, it the tLDP sessions will be closed. -- §2.2 OLD: "Also, currently the remote LSR accepts asymmetric extended Hellos by default or by appropriate configuration. With this document, the LSR MUST accept tLDP hellos in order to then accept or reject the tLDP session based on the application information." What is the goal of this paragraph? I'm reading that a LSR may not be configured anymore to reject tLDP hellos. Why not? I would propose NEW "By default, LSR SHOULD accept tLDP hellos in order to then accept or reject the tLDP session based on the application information." --- §2.3.1 " 1. The S-bit of the Targeted Application Capability TLV MUST be set to 1 to advertise Targeted Application Capability and SHOULD be ignored on the receipt." This behavior is defined in RFC 5561. I don't think that it's good practice to redefine it. I'd rather have this sentence deleted. Alternatively, it should be made non normative and refer to RFC 5561. --- §2.3.1 " 2. The E-bit of the Targeted Application Element MUST be set to 1 to enable Targeted application and SHOULD be ignored on the receipt. " I understand that you are mimicking the behavior of the S-bit. It looks debatable to ignore this direct protocol violation and accept the TAE while the speaker expressed its williness to withdraw it. I would personnaly be enclined to ignore the TAE advertise with the E-bit cleared. --- §2.3.2 " If the S-bit is set to 0, the TAC is disabled for the session. After that, the session may remain in established state or torn down based on [RFC5036] rules." IMO, if TAC is disabled, the session MUST behave as per RFC5036 rules. (in particular, I don't see a reason to tear down the session, but I do see a reason to advertise all FEc mappings which where previously filtered based on TA-Id negociation.) --- §2.3.2 "5. If the S-bit is set to 1, a LSR process a list of TAEs from TACs capability data with E-bit set to 1 or 0 to update the peers TAE. Also, it updates the negotiated TAE list over the tLDP session." What's new compared to the already defined points 1, 2 and 3? If this point 5 is kept: :s/peers/peer's What does the second sentence adds to the first one? --- §3 Personally, I would prefer that the array also include the normative code points (rather than requiring an indirection in the IANA section) --- §2.3 Why does the document mandates that TAE be symmetrically negotiated? Here we are not negotiated capabilities which requires both ends to support the capability before its usage. We are mostly advertising the willingness of one LSR to receive FEC mappings from its peer. e.g. let's take the RLFA application which has asymmetric needs. The PLR is willing to get the IP prefixes mapping from the merge point (PQ node). But its peer (the merge point) is not willing to get any mapping. So why would it need to receive mappings of no interest, and why would it need to advertise TAE which does not itself? The document could have chosen an asymmetric model, where the advertisement of a TAE means "I'd like to receive the corresponding FEC mappings" Coming back to the RLFA use case, this requires configuring the Merge Point with the willingness to advertise RLFA application, including when RLFA in not configured on this node. So this is additional configuration requirement. In addition, RLFA is designed to be asymmetric in nature, with feature requirement only on the local node. Such document would now require some support for RLFA awareness on the MP node which is undesirable. I guess that this is not too bad to RLFA which is a pre-existing application, but what about future applications which would also be asymetric? --- §4 "With the SAC, the responding LSR is not aware of targeted applications. Thus it may be unable to communicate its interest or disinterest to receive state information from the peer." Sorry but I fail to see the logic or the use case. One is a priori capable of communicate its (_own_) interest, independently of the ones of its peer. e.g., If I'd like a beer in a restaurant, I ask for a beer. (I don't need to wait for the menu, so see whether I wan't a beer) " Therefore, when the responding LSR is not aware of targeted applications such a remote LFA and BGP auto discovered pseudowires, TAC mechanism should be used and when the responding LSR is aware (with appropriate configuration) of targeted applications such as FEC 128 pseudowire, SAC mechanism should be used." Well, as already expressed, I don't feel that TAC is well suited for the RLFA application as it adds the requirement to configure both ends. (more specifically the Merge Point). In which case, as per your above text, SAC should be used instead of TAC. If LDP has already a way to control FEC/state advertisement (as per RFC 7473), I feel that adding the same functionality in TAC is redundant. --- §4 "The set of applications negotiated by the TAC mechanism is symmetric between the two LDP peers." ok. for the _negociated_ applications. "In the absence of further mechanisms, two LDP peers will both advertise state information for the same set of applications." What do you mean by "state information"? At first reading, I understood "TAE" but this would be incorrect. So now I guess that you mean "FEC mappings" --- Usage (new section) To allow for incremental deployment of new TAI as well as private usage by a network operator, I think the configuration SHOULD allow the configuration of any TAI (including the ones unknown from the implementation) on both the sending side and the receiving side. --- §4 "The TAC mechanism MUST take precedence over the SAC mechanism with respect to enabling applications for which state information will be advertised." Is this not a case where the document meta data should indicate that this document updates RFC 7473? --- §3 "IPv4 intra-area FECs" Is this just a name of application, or is there a specific behavior associated with it? (e.g. only advertising the IPv4 FEC from my an area.) If so, the behavior should be specified. And please clarify whether this is the area of the sender or of the receiver, as in the general case, they may be in a different area. And clarify the behavior for IS-IS level 2 nodes. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.