Hi Peter, Many thanks for your replies. Please see inline [Bruno]
> From: Peter Psenak [mailto:[email protected]] > Sent: Monday, November 07, > 2016 1:23 PM > > Hi Bruno, > > thanks for your comments, please see responses inline. > > We can work on details as we progress the draft in the WG. [Bruno] Sure. We can also work on these details independently of the WG adoption (question). This was purpose of this thread (even though it was at the same time of the WG adoption thread) > What I would like to hear from you at this point is whether you support > the idea described in the draft. [Bruno] - I support the problem statement and the need for a solution. - Regarding the encoding (type of LSA/TLV), if the question is specific to the OSPF WG, and the IS-IS WG will be free to make a fully independent decision/solution, I'd rather leave this choice to OSPF users/implementers/experts (rather than adding noise on the mailing list). If the OSPF choice is likely to influence the IS-IS choice, I'd prefer waiting for the IS-IS document to express my comments/support. > On 04/11/16 16:50 , [email protected] wrote: > > 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? > > TE in the context of the draft means RSVP based TE. [Bruno] Thanks for the crystal clear clarification. Looks good to me. > > > > 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" > > sure, we can make that clarification. > > > > > 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. > > In a long run, we would like the SRTE to use the Extended Link Opaque > LSA ([RFC7684]. > > > > > 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? > > both are opaque to OSPF. What is important is that SRTE advertisements > would not cause any node in the network to believe that RSVP TE is > available on the link [Bruno] Agreed. Here comes a naïve question: What (signaling) would "cause a node in the network to believe that RSVP TE is available on the link"? Is this standardized or implementation specific? e.g. reading RFC 7471, I'm not seeing that advertising "OSPF Traffic Engineering (TE) Metric Extensions" is limited to RSVP-TE " The data distributed by OSPF TE Metric Extensions is meant to be used as part of the operation of the routing protocol (e.g., by replacing cost with link propagation delay or considering bandwidth as well as cost), by enhancing Constrained Shortest Path First (CSPF), or for use by a PCE [RFC4655] or an Application-Layer Traffic Optimization (ALTO) server [RFC7285]." Even reading RFC 3630 applicability " A more accurate (albeit bland) designation is "extended link attributes", as the proposal is to simply add more attributes to links in OSPF advertisements." [..] "Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering." I could read the second item as applicable to (written for? ;-) ) Segment Routing... And the first item applicable to regular IP Shortest Path routing. > - that's why we need to separate the two advertisements. [Bruno] At this point, I'm not seeing the causality, but this is due to my lack of OSPF knowledge. cf my first point. > > > > > > 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)... > > any type of LFA. These is detail though and subject to changes if required. > > > > > 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. > > sure, this is a small detail. No problem to change to MUST. > > > > > 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. > > the short answer is that these are bandwidth minus the bandwidth > allocated/used by RSVP TE. > > > > > 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? > > we can debate which attributes make sense to be application specific. > I'm open for that discussion. [Bruno] Sure. Thanks. Unfortunately, this is partly related to the interest in duplicating the TLV advertisement or not: if by design their value is application un-specific, advertising the TLV multiple times will just increase the configuration/code/interop/error handling complexity. However, I agree that some TLV may/could be application specific, in which case it is/would be a feature to be able to advertise it on a per application basis. > > > > 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. > > new routers would always understand the old advertisements. [Bruno] Sure. > 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". [Bruno] Yes, that's the point I had in mind. Thanks for reading my mind when my emails are not clear enough. > absolutely, that is the idea. I will make sure the text is clear on that. [Bruno] Thanks. 1 more point/question: "When an OSPF routing domain includes routers using link attributes from TE Opaque LSAs for Non-RSVP TE applications such as LFA, OSPF routers in that domain should continue to advertise such TE Opaque LSAs. " If there are drawbacks, they should probably be mentioned. e.g. some RSVP-TE routers will assume that RSVP-TE is enabled on a link, even if this not the case. Which will cause RSVP-TE to return an error, and hence a new RSVP-TE signaling. If there are no drawbacks, what would be the motivation to implement and deploy this new behavior (TE advertisement in Extended Link Opaque LSA [RFC7684])? E.g. as a network operator, if I ask for RFC 7471 TLV to be implemented inside TE Opaque LSA, it will work for both current/old and new routers. If I ask it inside Extended Link Opaque LSA it will only work for new/future implementations. Based on this, it seems safer for me to ask for TE Opaque LSA and don't bother with Extended Link Opaque LSA. (cf IPv4 vs IPv6 at the "beginning" of IPv6.) Thanks again for your clear clarifications. --Bruno > thanks, > Peter > > (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. > > > > . > > _________________________________________________________________________________________________________________________ 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
