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

Peter Psenak <> Fri, 08 April 2016 08:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FE1512D19A for <>; Fri, 8 Apr 2016 01:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z_83yO6Iz8_y for <>; Fri, 8 Apr 2016 01:13:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F9A912D17E for <>; Fri, 8 Apr 2016 01:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2500; q=dns/txt; s=iport; t=1460103237; x=1461312837; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Yl/x7ljuuWgZuyknrW5AuwOmOJNrTcw3MTfBWxZbVG4=; b=N02FGEuLCOPklVupHEkLjlKC0IKFtrKGgX+p6S9WITgYAwzVG/j/fiNC Lw6ZzeYGHOI51pFUcfJJKeMv5xFk33yLHa245ZMcmlXbvFiU/r7if5nRh aAFVopjbcS/rzeRmua58y+RK7btqSUPEOlJiLXmaRsniqeJWjQY7nKuYN 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.24,449,1454976000"; d="scan'208";a="634041398"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Apr 2016 08:13:55 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id u388DsAR021376; Fri, 8 Apr 2016 08:13:54 GMT
Message-ID: <>
Date: Fri, 08 Apr 2016 10:13:54 +0200
From: Peter Psenak <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Paul Mattes (AZURE)" <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Apr 2016 08:13:59 -0000

Hi Paul,

please see inline:

On 4/7/16 22:09 , Paul Mattes (AZURE) wrote:
> I would like to amplify some of the comments made about this draft at
> today’s OSPF WG meeting.
> The draft refers generically to TE when it really means RSVP TE. The
> draft should use the more-specific term “RSVP TE” or “RSVP-based TE” in
> most (but not all) of the places where “TE” is used. The most unhelpful
> place this occurs in section 1:
>      Many of these link attributes are useful outside of the traditional
> MLPLS (sic) Traffic Engineering or GMPLS.
> This should read:
>      Many of these link attributes are useful outside of the traditional
> RSVP-based Traffic Engineering, or GMPLS.

ok, will change.

> Perhaps it would be helpful if SR-based Traffic Engineering were
> mentioned as a typical consumer of this new information, which would
> distinguish it from RSVP-TE as the primary consumer of the existing TLVs.

well, it's not just SR-based traffic engineering. LFA is another 
example, which is not related to SR TE.

> In Section 3.1, I also have issue with this statement:
>      Additionally, link attributes are only advertised once when both
> OSPF TE and other applications are deployed on the same link.  This is
> not expected to be a common deployment scenario.
> I don’t think that this is a desired result, and I believe this is what
> Chris Bowers was trying to emphasize with his earlier comments. If a
> router currently advertises the existing TE TLVs, it should continue to
> advertise them after it implements this draft. Turning off advertisement
> of the existing TE TLVs (if somehow they were being advertised without
> enabling RSVP-TE on the link) should not be the default behavior, though
> perhaps it could be made an option. I know this default would be less
> efficient, but I don’t think it is worth breaking backwards
> compatibility to have.

section 3.1 talks about the other approach, which is to only use TE 
Opaque LSA for advertising any link attributes. In such case the link 
attribute is only advertise once.

Section 3.2., which talks about the preferred option of using Extended 
Link LSA explicitly says "the same link attribute is advertised in both 
the TE Opaque and Extended Link Attribute LSAs".

> /pdm/
> _______________________________________________
> OSPF mailing list