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

"Les Ginsberg (ginsberg)" <> Fri, 31 March 2017 04:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28CAD1270A0 for <>; Thu, 30 Mar 2017 21:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 9Vep3KSR4jTn for <>; Thu, 30 Mar 2017 21:36:47 -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 75C5D12420B for <>; Thu, 30 Mar 2017 21:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=25370; q=dns/txt; s=iport; t=1490935007; x=1492144607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bf1ZpIgUh6LpWKiboTZUzm7qLvcqP4sm6yxROrWpHyc=; b=R2MKF9ASwVHjzNqH6zoh/VUSpDLMY+W7zjPgu51tsWLng1/6kD56+4GX DZN6c9Ojx6dyJPMf/BJydKSc7ToIdNFoCwsSSm0rAWtZOL+MxOILSybGn hemyApfTbUUOJwyAAVy+RUgCzs06s5RMr7yu+33MRIDgH0SVtyCNRw9Ow Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.36,250,1486425600"; d="scan'208,217";a="405501796"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 04:36:46 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2V4akYF016154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 04:36:46 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Mar 2017 23:36:45 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 30 Mar 2017 23:36:45 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Alia Atlas <>, Robert Raszuk <>
CC: OSPF List <>
Thread-Topic: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse
Thread-Index: AQHSqYoFv72V/WfUrUiKznA2CtTATaGuFfWAgAAJ23A=
Date: Fri, 31 Mar 2017 04:36:45 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_b5852b927e8448139d4d42ca924fcca3XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse
X-Mailman-Version: 2.1.22
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, 31 Mar 2017 04:36:50 -0000

Alia (and everyone) –

Let’s focus on the relevant questions.

1)Disruption to existing deployments

draft-ppsenak-ospf-te-link-attr-reuse is non-disruptive i.e. legacy systems are not impacted

draft-hegde-ospf-advertising-te-protocols is disruptive – all legacy routers have to have additional configuration in order to avoid misinterpreting non RSVP-TE advertisements as if they are RSVP-TE related

So if the primary concern is impact on existing deployments we have a clear choice.

2)Support for per application advertisements

Only draft-ppsenak-ospf-te-link-attr-reuse supports this.

Again we have a clear choice.

3)The question has been raised as to use case for application specific attributes– here are a few:

·         Using TE metric/bandwidth to influence LFA selection.

·         Use different attributes for SR-TE vs RSVP-TE engineered paths.

·         Defining a separate set of SRLGs in support of rerouting around a non-local catastrophic event e.g. a natural disaster affecting all traffic through a particular geographic area.

Both drafts agree that supporting multiple applications utilizing link attributes is a problem which needs to be solved. However, only draft-ppsenak-ospf-te-link-attr-reuse provides support for both sharing common attributes without duplicate advertisements and advertising application specific attributes when necessary.

The proponents of draft-hegde-ospf-advertising-te-protocols would have us believe that there is no need for per application attributes – but as we have examples of when it is necessary – and the recognition that all future use cases cannot be imagined now (just as the original TE support never anticipated multiple applications) this isn’t a credible position.

The more apt question to ask is why we would want to constrain multiple application support when we have the opportunity to define a more flexible framework which also provides efficient encoding whenever possible. Given that we have agreed to support multiple applications I think the onus should be on why we should NOT provide per application value support rather than why we should.


From: OSPF [] On Behalf Of Alia Atlas
Sent: Thursday, March 30, 2017 12:20 PM
To: Robert Raszuk
Cc: OSPF List
Subject: Re: [OSPF] draft-ppsenak-ospf-te-link-attr-reuse


Take a read through RFC 7282.  Consensus calls aren't about majority rules.
It is about hearing technical objections and understanding and responding to them.
It is quite quite clear that there are technical objections to either solution.


On Thu, Mar 30, 2017 at 3:15 PM, Robert Raszuk <<>> wrote:

Based on the discussion so far I see that:

A) producing use case document will only delay things further as each use case presented will be questioned as possible already today via MTR, MI, building new separate network etc ...

B) WG members in majority support adoption of draft-ppsenak-ospf-te-link-attr-reuse. Can we get at least sense in the room who is in support of which draft ?


OSPF mailing list<>