Hi, We agreed during the OSPF meeting that a use case/requirement draft should be written before progressing with any solution. I propose to take the point to initiate the work and I will first try to list the possible situations and then we can really agree on the use cases that are relevant. We have some in Orange but there may be additional as well.
Brgds, Stephane -----Original Message----- From: OSPF [mailto:[email protected]] On Behalf Of Peter Psenak Sent: Tuesday, November 08, 2016 18:26 To: DECRAENE Bruno IMT/OLN Cc: OSPF WG List; [email protected] Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-03 Hi Bruno, please see inline (##PP): On 07/11/16 15:35 , [email protected] wrote: > 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. ##PP encoding is one thing, what I would like to hear from you is whether you support the idea of per application link-attribute values. > > > > > 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? ##PP as all existing link attributes have been defined for RSVP TE, almost any implementation interpret the presence of these link attributes as an indication that RSVP TE is enabled on the link. draft-hegde-isis-advertising-te-protocols in chapter 1 lists the behavior of three different implementations. > > 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. ##PP RFC3630 also says: "The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPF area. This topology does not necessarily match the regular routed topology," > > >> - 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. ##PP problem is not specific to OSPF, applies the same way to ISIS. > > > > > > > > > > 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. ##PP right. Which ones are eligible for app specific values is something we can work on. We have few that we know would be eligible. > > > > > > > 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. ##PP that is correct. > 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.) ##PP As far as we keep the link attributes for non RSVP-TE apps in TE Opaque LSA we have a problem (as described above). To solution is to move them to Extended Link LSA. If some implementation uses TE Opaque LSA for no RSVP-TE purposes, it may continue to do so during transition, but eventually all routers would move to the new behavior. thanks, Peter > > 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 _________________________________________________________________________________________________________________________ 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
