<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.
The TE Opaque LSA would be, presumably, required if SPRING is supported which has no implications on whether RSVP-TE is enabled. My question is what does an assumption about being "TE-enabled" mean? What are the benefits of trying to change interpretations that have existed for at least 5+ years? Regards, Alia </no-hat> On Thu, Oct 22, 2015 at 11:00 AM, Chris Bowers <[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]] > Sent: Wednesday, October 21, 2015 3:24 PM > To: Chris Bowers <[email protected]>; Acee Lindem (acee) <[email protected]>; > Shraddha Hegde <[email protected]>; OSPF WG List <[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]] > > Sent: Wednesday, October 21, 2015 12:40 PM > > To: Chris Bowers <[email protected]>; Acee Lindem (acee) < > [email protected]>; Shraddha Hegde <[email protected]>; OSPF WG List < > [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]] *On Behalf Of *Acee Lindem > >> (acee) > >> *Sent:* Wednesday, October 21, 2015 6:48 AM > >> *To:* Shraddha Hegde <[email protected]>; OSPF WG List > >> <[email protected]> > >> *Subject:* Re: [OSPF] Regarding > >> draft-ppsenak-ospf-te-link-attr-reuse-00 > >> > >> Hi Shraddha, > >> > >> *From: *OSPF <[email protected] <mailto:[email protected]>> on > >> behalf of Shraddha Hegde <[email protected] > >> <mailto:[email protected]>> > >> *Date: *Wednesday, October 21, 2015 at 1:20 AM > >> *To: *OSPF WG List <[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] > >> https://www.ietf.org/mailman/listinfo/ospf > >> > > > > . > > > > _______________________________________________ > OSPF mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ospf >
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
