Hi, No hats I'm familiar with at least 2 implementations which have this issue, this draft solves real problem.
Regards, Jeff > On Oct 25, 2015, at 2:28 PM, Acee Lindem (acee) <[email protected]> wrote: > > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
