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

["Acee Lindem (acee)" <[e-mail]>]

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