Speaking with no hats on… I just want to add that we have a separate OSPF metric and OSPF TE Metric so the mere fact that there is a similar object in GMPLS doesn’t imply that it automatically is applicable to IP applications as well.
Thanks, Acee On 10/22/15, 1:08 PM, "Peter Psenak (ppsenak)" <[email protected]> wrote: >Hi Alia, > >please see inline: > >On 10/22/15 19:00 , Alia Atlas wrote: >> <no-hat> >> >> The LFA and RLFA work both have the ability to use SRLG information, >>which >> has only been available in the TE Opaque LSA. That's not been >>considered a >> problem. > >it is a problem if the user does not want to use the link for MPLS >traffic engineering. The reason is that any router receiving such TE >Opaque LSA would automatically make the link part of the traffic >engineering topology. RFC3630 clearly says that traffic engineering >topology is described by TE Opaque LSAs and that such topology does not >necessarily match the regular routed topology. > >> >> The TE Opaque LSA would be, presumably, required if SPRING is supported >> which has no implications on whether RSVP-TE is enabled. > >SPRING does not use TE Opaque LSA. > >> >> My question is what does an assumption about being "TE-enabled" mean? > >means that the link is part of the traffic engineering topology. > >> What are the benefits of trying to change interpretations that have >> existed for >> at least 5+ years? > >not sure what interpretation are you referring to, but RFC3630 is clear >on what the TE Opaque LSAs are used for. > >thanks, >Peter > >> >> Regards, >> Alia >> </no-hat> >> >> On Thu, Oct 22, 2015 at 11:00 AM, Chris Bowers <[email protected] >> <mailto:[email protected]>> wrote: >> >> Peter, >> >> I would suggest making the text of the draft more explicit about the >> conditions under which a given link and set of attributes should be >> included in the TE Opaque LSA or the Extended Link Opaque LSA. >> RFC3630 is subject to interpretation on its own, and since it was >> written before the existence of the Extended Link Opaque LSA, it is >> not self-evident how to interpret it with respect to using this new >> LSA. Clarifying the proposed rules for use of the TE Opaque LSA or >> the Extended Link Opaque LSA without relying on interpretations of >> 3630 will be helpful. It will help the WG evaluate the proposal >> overall and determine what, if any, backwards compatibility issues >> this proposal may cause with existing implementations. It may also >> help future implementers avoid interoperability and backwards >> compatibility issues. >> >> As a concrete example, I think it would be useful to explicitly >> address the case of how to advertise a link that only supports LDP >> in the text of the draft. Below is an example of a format that >> would clarify this. From the response to my question below >> regarding LDP, I assume that a link that only supports LDP signaling >> and not RSVP-signaling would not be advertised in the TE Opaque >> LSA. However, I am honestly not positive that this is what is >>intended. >> >> Format of proposed clarifying text: >> ------------------ >> >> A link MUST NOT be advertised in the TE Opaque LSA under the >> following conditions: >> >> 1) The link does not support RSVP-TE signaling. >> >> 2) Another condition... >> >> A link MAY be advertised in the TE Opaque LSA under the following >> conditions: >> >> 1) Another condition ... >> >> A link MUST NOT be advertised in the Extended Link Opaque LSA under >> the following conditions: >> >> 1) Some other condition .... >> >> Thanks, >> Chris >> >> >> >> -----Original Message----- >> From: Peter Psenak [mailto:[email protected] >><mailto:[email protected]>] >> Sent: Wednesday, October 21, 2015 3:24 PM >> To: Chris Bowers <[email protected] <mailto:[email protected]>>; >> Acee Lindem (acee) <[email protected] <mailto:[email protected]>>; >> Shraddha Hegde <[email protected] <mailto:[email protected]>>; >> OSPF WG List <[email protected] <mailto:[email protected]>> >> Subject: Re: [OSPF] Regarding >>draft-ppsenak-ospf-te-link-attr-reuse-00 >> >> Hi Chris, >> >> On 10/21/15 21:44 , Chris Bowers wrote: >> > Peter, >> > >> > RFC3630 does not appear to restrict the use of the attributes it >> defines. The term "TE extensions" may seem to imply some >> restriction, but the Applicability section of RFC3630 explicitly >> addresses this potential interpretation by saying that a more >> accurate designation is "extended link attributes". >> > >> > 1.1. Applicability >> > >> > Many of the extensions specified in this document are in >> response to >> > the requirements stated in [5], and thus are referred to as >> "traffic >> > engineering extensions", and are also commonly associated >> with MPLS >> > Traffic Engineering. A more accurate (albeit bland) >> designation is >> > "extended link attributes", as the proposal is to simply add >>more >> > attributes to links in OSPF advertisements. >> >> RFC3630 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, >> >> above clearly indicates that if the link is advertised in TE Opaque >> LSA, it is part of the TE topology, otherwise it is not. That >> restricts the usage of the TE Opaque LSA to the links that are part >> of the TE topology. >> >> > >> > ------- >> > Also, the response below uses the term "TE-enabled" which along >> with "TE-application" does not appear to have a precise definition >> in draft-ppsenak-ospf-te-link-attr-reuse-00. Based on RFC 3630, it >> seems reasonable to say that a link is "TE-enabled" if the link is >> advertised in the TE Opaque LSA. I don't think this is the meaning >> you intend, so to avoid confusion, I will use the term >> "RFC-3630-TE-enabled" to mean that the link is advertised in the TE >> Opaque LSA defined in RFC 3630. >> > >> > So can you clarify what "TE-enabled" or a "TE-application" means >> in your document? I assume that it should mean that MPLS is >> enabled, but it is actually not clear to me if just having >> LDP-enabled on a link would qualify as being "TE-enabled" or not. >> >> TE-enabled means the link is part of the traffic engineering >>topology as >> described by RFC3630. >> >> thanks, >> Peter >> >> > >> > Thanks, >> > Chris >> > >> > >> > -----Original Message----- >> > From: Peter Psenak [mailto:[email protected] >> <mailto:[email protected]>] >> > Sent: Wednesday, October 21, 2015 12:40 PM >> > To: Chris Bowers <[email protected] >> <mailto:[email protected]>>; Acee Lindem (acee) <[email protected] >> <mailto:[email protected]>>; Shraddha Hegde <[email protected] >> <mailto:[email protected]>>; OSPF WG List <[email protected] >> <mailto:[email protected]>> >> > Subject: Re: [OSPF] Regarding >> draft-ppsenak-ospf-te-link-attr-reuse-00 >> > >> > Hi Chris, >> > >> > On 10/21/15 19:20 , Chris Bowers wrote: >> >> In my opinion the backwards compatibility problems introduced by >> this >> >> proposal outweigh potential gains. >> > >> > there is no backwards compatibility problem with the draft. >> > >> >> >> >> As a concrete example, there is at least one existing >>implementation >> >> of remote LFA where policy is used to select a backup tunnel >> that does >> >> not share an SRLG with the failed link. This SRLG information >>is >> >> carried in the TE Opaque LSA. >> > >> > that is fine, you are free to do that if the link is TE enabled, >> there is no problem. If the link is not TE enabled and you use TE >> Opaque LSA to flood the SRLG data for such link, you are going >> against the current specification. There is no way to do that today, >> because any router that would receive such TE Opaque LSA must assume >> such link is TE enabled. >> > >> >> >> >> As it currently reads, I think the proposal in >> >> draft-ppsenak-ospf-te-link-attr-reuse has the potential to >>break >> >> existing standards-compliant implementations. >> > >> > I don't believe so. >> > >> >> >> >> I might be OK with having the proposal only apply to sub-TLVs >>that >> >> get defined in the future. However, I think that taking TLVs >> that were >> >> standardized over ten years ago, and selectively moving them >>or >> >> copying them to a different LSA based on a set of rules that is >> >> subject to interpretation is going to create confusion and >> >> interoperability headaches. >> > >> > What we propose is the way to advertise link attributes without >> making the link part of TE topology. We simply do not have a way to >> do that today. I do not see any problem in doing so, because we do >> not change anything on the TE Opaque LSA side, we are defining >> something new. >> > >> > thanks, >> > Peter >> > >> >> >> >> Chris >> >> >> >> *From:*OSPF [mailto:[email protected] >> <mailto:[email protected]>] *On Behalf Of *Acee Lindem >> >> (acee) >> >> *Sent:* Wednesday, October 21, 2015 6:48 AM >> >> *To:* Shraddha Hegde <[email protected] >> <mailto:[email protected]>>; OSPF WG List >> >> <[email protected] <mailto:[email protected]>> >> >> *Subject:* Re: [OSPF] Regarding >> >> draft-ppsenak-ospf-te-link-attr-reuse-00 >> >> >> >> Hi Shraddha, >> >> >> >> *From: *OSPF <[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>>> on >> >> behalf of Shraddha Hegde <[email protected] >> <mailto:[email protected]> >> >> <mailto:[email protected] <mailto:[email protected]>>> >> >> *Date: *Wednesday, October 21, 2015 at 1:20 AM >> >> *To: *OSPF WG List <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> >> *Subject: *[OSPF] Regarding >>draft-ppsenak-ospf-te-link-attr-reuse-00 >> >> >> >> Hi All, >> >> >> >> draft-ppsenak-ospf-te-link-attr-reuse-00 proposes moving >>and/or >> >> copying TLVs from the TE Opaque LSA to the Extended Link >> Opaque LSA. >> >> The draft lists the problems that the draft is trying to >> solve. I >> >> have reproduced that list of problems below, with each >>problem >> >> followed by what I believe to be a better and simpler >>solution. >> >> >> >> 1. Whenever the link is advertised in a TE Opaque >>LSA, the >> >> link >> >> >> >> becomes a part of the TE topology, which may not >> match IP >> >> routed >> >> >> >> topology. By making the link part of the TE >>topology, >> >> remote >> >> >> >> nodes may mistakenly believe that the link is >>available >> >> for MPLS >> >> >> >> TE or GMPLS, when, in fact, MPLS is not enabled on >> the link. >> >> >> >> To address this issue, we simply need to define a new >> sub-TLV in the >> >> TE Link LSAto say whether MPLS/GMPLS/RSVP is enabled on the >> link >> >> instead of moving the TLVs around into different LSAs. >> >> >> >> 2. The TE Opaque LSA carries link attributes that are >>not >> >> used or >> >> >> >> required by MPLS TE or GMPLS. There is no >> mechanism in TE >> >> Opaque >> >> >> >> LSA to indicate which of the link attributes >>should be >> >> passed to >> >> >> >> MPLS TE application and which should be used by >> OSPFv2 and >> >> other >> >> >> >> applications. >> >> >> >> OSPF database is a container and OSPF can use any of the >> LSAS for >> >> its own use including the TE LSAs.As far as the TE database >> goes, it >> >> contains data from TE LSAs as well as non-TE LSAs (Network >>LSA) >> >> today so thereasoning described here doesn't make sense. >> >> >> >> 3. Link attributes used for non-TE purposes is >>partitioned >> >> across >> >> >> >> multiple LSAs - the TE Opaque LSA and the Extended >>Link >> >> Opaque >> >> >> >> LSA. This partitioning will require >>implementations to >> >> lookup >> >> >> >> multiple LSAs to extract link attributes for a >>single >> >> link, >> >> >> >> bringing needless complexity to the OSPFv2 >> implementations. >> >> >> >> There will be nodes in the network which will run older >> software >> >> which send these attributes via TE LSAs so the problem of >> looking >> >> into the TE LSAs for TE relatedinformation doesn't get >> solved with >> >> this draft. Rather it makes it more complicated. With this >> draft, >> >> the multiple LSA lookup will only increase.An >> implementation will >> >> first have to find if Extended link LSA contains the >> required info, >> >> if not it will need to lookup the info in TE.LSA. >> >> >> >> The applications using the TE parameters for non-TE use-cases >> will use >> >> the OSPF Prefix/Link attributes for these use cases. Hence, >>there is >> >> no requirement to lookup the LSAs in multiple places. Backward >> >> compatibility will be covered in the specifications of these >> applications. >> >> >> >> Thanks, >> >> >> >> Acee >> >> >> >> Looking up multiple LSAs for information is an >> implementation issue >> >> and I am sure there will be implementations that will >> handle this >> >> gracefully so that it doesn't cause >> >> >> >> delays in critical paths. It doesn't seem reasonable to >> come up with >> >> protocol extensions to solve implementation issues. >> >> >> >> Rgds >> >> >> >> Shraddha >> >> >> >> >> >> >> >> _______________________________________________ >> >> OSPF mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://www.ietf.org/mailman/listinfo/ospf >> >> >> > >> > . >> > >> >> _______________________________________________ >> OSPF mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ospf >> >> > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
