Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00

[Alia Atlas <[e-mail]>]

<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 <[e-mail]> 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:[e-mail]]
> Sent: Wednesday, October 21, 2015 3:24 PM
> To: Chris Bowers <[e-mail]>; Acee Lindem (acee) <[e-mail]>;
> Shraddha Hegde <[e-mail]>; OSPF WG List <[e-mail]>
> 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:[e-mail]]
> > Sent: Wednesday, October 21, 2015 12:40 PM
> > To: Chris Bowers <[e-mail]>; Acee Lindem (acee) <
> [e-mail]>; Shraddha Hegde <[e-mail]>; OSPF WG List <
> [e-mail]>
> > 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:[e-mail]] *On Behalf Of *Acee Lindem
> >> (acee)
> >> *Sent:* Wednesday, October 21, 2015 6:48 AM
> >> *To:* Shraddha Hegde <[e-mail]>; OSPF WG List
> >> <[e-mail]>
> >> *Subject:* Re: [OSPF] Regarding
> >> draft-ppsenak-ospf-te-link-attr-reuse-00
> >>
> >> Hi Shraddha,
> >>
> >> *From: *OSPF <[e-mail] <mailto:[e-mail]>> on
> >> behalf of Shraddha Hegde <[e-mail]
> >> <mailto:[e-mail]>>
> >> *Date: *Wednesday, October 21, 2015 at 1:20 AM
> >> *To: *OSPF WG List <[e-mail] <mailto:[e-mail]>>
> >> *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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ospf
> >>
> >
> > .
> >
>
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf
>