Hi authors, Although I'm more familiar with IS-IS (nobody's perfect ;-) ), please find below some proposed comments
1) meaning of "TE" As already expressed in a meeting, I'd like the document to clarify the meaning of "TE". I suspect that in this document it is used to mean "RSVP-TE" while some readers could understand it as "Traffic Engineering application". IOW, is SR-TE part of "TE" or not? In particular, this needs to be crystal clear in the recommended approach. Current text is: "3.3. Selected Approach It is RECOMMENDED to use the Extended Link Opaque LSA ([RFC7684] to advertise any link attributes used for non-TE purposes in OSPFv2" IMHO, I would interpret this text as SR-TE must not use the Extended Link Opaque LSA ([RFC7684], hence presumably must use the TE Opaque TSA. But I suspect that this is not the intent of the authors. 2) As a minor comment, I'm not that convinced with (or don't understand well) the argument 2 in section 3.2 "The TE Opaque LSA remains truly opaque to OSPFv2 as originally defined in [RFC3630]. Its content is not inspected by OSPFv2 and OSPFv2 acts as a pure transport." Why should RSVP-TE info be truly opaque to OPSFv2 while SR-TE or LFA info should not be opaque? 3) §5 " Bit-1: LFA" Could you please clarify what you mean by "LFA"? Do you mean "LFA" ie RFC 5286? Or *LFA to include LFA, RLFA, DLFA, TI-LFA? (but this would not cover some possibly future solution) Or "FRR" in which case this would include RSVP-TE FRR? or "IP FRR"? (but I'm afraid this term is loosely defined)... 4) §5 "If, however, another advertisement of the same link attribute includes Application Bit-Mask in the Extended Link Attribute sub-TLV, applications that are listed in the Application Bit-Mask of such Extended Link Attribute sub-TLV SHOULD use the attribute advertisement which has the application specific bit set in the Application Bit-Mask." Why SHOULD rather than MUST? A priori the principle is that the most specific information prevails. i.e the attribute advertisement which has the application specific bit set in the Application Bit-Mask is to be used. 5) §5 I have a clarification question with regards to the use of "Unidirectionnal Residual Bandwidth" for non TE applications (i.e. for OSPFv2 Extended Link TLV). What would be the meaning of this sub-TLV for non-TE application, given that RFC 7471 seems to have defined a meaning which is RSVP-TE specific "For a link or forwarding adjacency, residual bandwidth is defined to be Maximum Bandwidth [RFC3630] minus the bandwidth currently allocated to RSVP-TE LSPs." Same question for "Available Bandwidth" which definition is also RSVP-TE specific. Related question for "Utilized Bandwidth", and * "Unidirectional Link Delay" which seems to measure a specific physical property, which does not seem to be possibly different on a per application basis. e.g. " The delay advertised by this sub-TLV MUST be the delay from the advertising node to its neighbor (i.e., the forward path delay)." How could this value be application specific? 6) §6 backward compatibility Thanks for considering the backward compatibility. I fell that one case is missing. "If there are also OSPF routers using the link attributes described herein for Non-RSVP applications, OSPF routers in the routing domain will also need to advertise these attributes in OSPF Extended Link Attributes LSAs [RFC7684]." At the beginning, some OSPF routers not (yet) upgraded to be compliant with this spec, won't be capable of advertising these attributes in OSPF Extended Link Attributes LSAs. So "new" routers won't be able to understand "old" routers. A more graceful way to introduce this change, would be to ask "new" routers also listen to "old" routers. i.e. if no "TE attributes" is advertised in Extended Link Attributes LSAs, then look for this attributes in TE Opaque LSAs, and use that information for "non-TE applications". (Using a node capability would a priori seems easier, but this is a detail) Thanks, Regards, -- Bruno _________________________________________________________________________________________________________________________ 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. _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
