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

Jeff Tantsura <jeff.tantsura@ericsson.com> Mon, 26 October 2015 01:02 UTC

Return-Path: <jeff.tantsura@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAD41B3448 for <ospf@ietfa.amsl.com>; Sun, 25 Oct 2015 18:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIQNS0yZJpup for <ospf@ietfa.amsl.com>; Sun, 25 Oct 2015 18:01:57 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1741B3447 for <ospf@ietf.org>; Sun, 25 Oct 2015 18:01:56 -0700 (PDT)
X-AuditID: c6180641-f792c6d00000686a-46-562d0e901b23
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E4.92.26730.09E0D265; Sun, 25 Oct 2015 18:17:05 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Sun, 25 Oct 2015 21:01:55 -0400
From: Jeff Tantsura <jeff.tantsura@ericsson.com>
To: "Acee Lindem (acee)" <acee@cisco.com>
Thread-Topic: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00
Thread-Index: AQHRC/ZPFuY7qCnGR1+q4c+BrPcEhJ519m0AgACDwACAACLZAIAACueAgAE4FQCAACFwgIAAAigAgAT/mAD///iwhg==
Date: Mon, 26 Oct 2015 01:01:54 +0000
Message-ID: <E70EB200-09AE-464C-A0B2-38F480489F16@ericsson.com>
References: <D24CF2B7.37452%acee@cisco.com> <BLUPR05MB292E9628E4172C733C59BA8A9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627CDF6.605@cisco.com> <BLUPR05MB292B99DA8B1B9E253A0E83BA9380@BLUPR05MB292.namprd05.prod.outlook.com> <5627F457.8020701@cisco.com> <BLUPR05MB2927E888C41831AF2786280A9270@BLUPR05MB292.namprd05.prod.outlook.com> <CAG4d1rctdk6QcrhjEj2n-1VM2HTzQJvFxgamneis+fsiH0rcTw@mail.gmail.com> <562917FE.6070100@cisco.com>,<D252C136.384AC%acee@cisco.com>
In-Reply-To: <D252C136.384AC%acee@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonXHcin26YwYprAhaT385jtvj08BKz xY/1rhYt9+6xW+zY3c7mwOox5fdGVo+ds+6yeyxZ8pPJ43rTVfYAligum5TUnMyy1CJ9uwSu jKU3FrAULKyq+LFlKksD4/L4LkZODgkBE4lvT84xQdhiEhfurWfrYuTiEBI4wihx7+EsZghn OaNEw/pedpAqNgEDif/fjrN0MXJwiAhoSmx5zwJSwywwjVFiwsyTYDXCAm4S73dOYgWxRQTc JdZPn8QCYWdJHD37HWwbi4CqxOap2xlBbF4Be4n/k3pYIJbdY5ZY8L4NbBCngI7E148vmEFs RqDzvp9aA9bMLCAucevJfKizBSSW7DnPDGGLSrx8/I8V5DhmoEP/bWCGKNeWWLbwNTPELkGJ kzOfsExgFJ2FZNIshI5ZSDpmIelYwMiyipGjtDi1LDfdyHATIzB6jkmwOe5gXPDJ8hCjAAej Eg+vwTadMCHWxLLiytxDjBIczEoivKWZumFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeefNuB8q JJCeWJKanZpakFoEk2Xi4JRqYKxi2OrYG2Fzza836Mn8L2tYynSkA48HWqVfZIuf+1X+nTcH i6Wl0bzEP5Gyuft5PKNaN336WCVmve074/zyv+9Erlw/cs41ymvNt4vKfe6MbUaOnRdtupx/ PLPg3zE5qPebSWs3h0WlmuTZlxeVGSqPi96WUQvwNZpV2VMS+VDywpwXVaZFSizFGYmGWsxF xYkAywHIOZoCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/BUzSXtGvV7BQfSMkb0YxVbj6HDY>
Cc: OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] Regarding draft-ppsenak-ospf-te-link-attr-reuse-00
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2015 01:02:00 -0000

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