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

[Jeff Tantsura <[e-mail]>]

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) <[e-mail]> 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)" <[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
> 
> _______________________________________________
> OSPF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ospf