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

Alia Atlas <akatlas@gmail.com> Thu, 22 October 2015 17:00 UTC

Return-Path: <akatlas@gmail.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 EA4781B399C for <ospf@ietfa.amsl.com>; Thu, 22 Oct 2015 10:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 oSHMz-b9GWSP for <ospf@ietfa.amsl.com>; Thu, 22 Oct 2015 10:00:32 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BE9E1B398A for <ospf@ietf.org>; Thu, 22 Oct 2015 10:00:32 -0700 (PDT)
Received: by oiad129 with SMTP id d129so51211071oia.0 for <ospf@ietf.org>; Thu, 22 Oct 2015 10:00:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a4c7QdK6yoJMNc+OTuSPgFpbA+xY7Urw11YY46JbYIA=; b=umeuKtPXyEYq+CDxnawf9gjMBSUChcHONDztModXRNfulIyZvUlLRKOYvzkBrpsz0H F/RMtJV92cc9msxVUIGZPcAET/eSfEhBdbk7YSbg6Wzt7wbvbvtaFSLarXJ7TPA0qsYA bnctEmBXtvqssXlHgG4bnypeHR+7Vysn+axteZKj6jheSSe4bIAL922Mz7TM43HmrRSo 2+32GcyvpdqIdIcHfiuma6naQyoQ1O2PEVanQTbtBEvWmcbuqL1FGLHhSBrY4zU7Wjnu I8EE4YiStOLCzKMahDRF2iKrpTOsEk7LzwMtGn+0rOgUIpACpxTCWdpbHbNNtR17BEdL prWQ==
MIME-Version: 1.0
X-Received: by 10.202.175.129 with SMTP id y123mr11077863oie.22.1445533231713; Thu, 22 Oct 2015 10:00:31 -0700 (PDT)
Received: by 10.60.121.74 with HTTP; Thu, 22 Oct 2015 10:00:31 -0700 (PDT)
In-Reply-To: <BLUPR05MB2927E888C41831AF2786280A9270@BLUPR05MB292.namprd05.prod.outlook.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>
Date: Thu, 22 Oct 2015 13:00:31 -0400
Message-ID: <CAG4d1rctdk6QcrhjEj2n-1VM2HTzQJvFxgamneis+fsiH0rcTw@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Chris Bowers <cbowers@juniper.net>
Content-Type: multipart/alternative; boundary="001a113ce9d8c994a40522b46ea0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/_w-J2GaWDTRtfNJqdqgjuJn1SXw>
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: Thu, 22 Oct 2015 17:00:38 -0000

<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 <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]
> Sent: Wednesday, October 21, 2015 3:24 PM
> To: Chris Bowers <cbowers@juniper.net>; Acee Lindem (acee) <acee@cisco.com>;
> Shraddha Hegde <shraddha@juniper.net>; OSPF WG List <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]
> > Sent: Wednesday, October 21, 2015 12:40 PM
> > To: Chris Bowers <cbowers@juniper.net>; Acee Lindem (acee) <
> acee@cisco.com>; Shraddha Hegde <shraddha@juniper.net>; OSPF WG List <
> 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] *On Behalf Of *Acee Lindem
> >> (acee)
> >> *Sent:* Wednesday, October 21, 2015 6:48 AM
> >> *To:* Shraddha Hegde <shraddha@juniper.net>; OSPF WG List
> >> <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>> on
> >> behalf of Shraddha Hegde <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>>
> >> *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
> >> https://www.ietf.org/mailman/listinfo/ospf
> >>
> >
> > .
> >
>
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf
>