[Softwires] Meanwhile, back on topic (BGP-TE)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Softwires] Meanwhile, back on topic (BGP-TE)



Hi Yakov et al.,

Thanks for the 02 revision

The new text in the Abstract and Introduction goes a long way to addressing 
my concerns.

   The scope and applicability of this attribute currently excludes its
   use for non-VPN deployment scenarios.

But it doesn't answer my multi-AS question. What will an ASBR advertise 
onwards?

The TE parameters that it receives from the source PE are the TE parameters 
of the PE-CE link to a specific port. If it advertises those parameters it 
is clearly not advertising the TE parameters of the route, but I am not 
clear how a BGP speaker down the line can tell that this is just the PE-CE 
link that is being described. But to do otherwise would imply that the ASBR 
is making some assessment of the TE route available from the ASBR to the PE.

This is the question I was trying to raise about "TE aggregation" (which is 
*not* route aggregation).

It seems to me that this whole question is either out of scope of requiring 
significant future study.

Probably the solution that can get us to closure most quickly is one where 
we update your new text to say...

   The scope and applicability of this attribute is currently limited to
   single-AS VPN deployment scenarios.

I would also like to see a something added From softwires-bounces at ietf.org  Mon Sep  8 16:02:02 2008
Return-Path: <softwires-bounces at ietf.org>
X-Original-To: softwires-web-archive at megatron.ietf.org
Delivered-To: ietfarch-softwires-web-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E31BB3A680A;
	Mon,  8 Sep 2008 16:02:02 -0700 (PDT)
X-Original-To: softwires at core3.amsl.com
Delivered-To: softwires at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7FC753A69B5
	for <softwires at core3.amsl.com>; Mon,  8 Sep 2008 16:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.281
X-Spam-Level: 
X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5
	tests=[AWL=-0.283, BAYES_50=0.001, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ZqSssKtMreRe for <softwires at core3.amsl.com>;
	Mon,  8 Sep 2008 16:02:00 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248])
	by core3.amsl.com (Postfix) with ESMTP id D59B93A67F3
	for <softwires at ietf.org>; Mon,  8 Sep 2008 16:01:58 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1])
	by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id
	m88N1fZc005863; Tue, 9 Sep 2008 00:01:41 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com
	[81.140.15.32]) (authenticated bits=0)
	by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id
	m88N1dHp005851; Tue, 9 Sep 2008 00:01:40 +0100
Message-ID: <012c01c91206$d953eeb0$0200a8c0 at your029b8cecfe>
From: "Adrian Farrel" <adrian at olddog.co.uk>
To: "Yakov Rekhter" <yakov at juniper.net>
Date: Tue, 9 Sep 2008 00:01:32 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Cc: softwires at ietf.org, ccamp at ops.ietf.org
Subject: [Softwires] Meanwhile, back on topic (BGP-TE)
X-BeenThere: softwires at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian at olddog.co.uk>
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>,
	<mailto:softwires-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/softwires>
List-Post: <mailto:softwires at ietf.org>
List-Help: <mailto:softwires-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>,
	<mailto:softwires-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: softwires-bounces at ietf.org
Errors-To: softwires-bounces at ietf.org

Hi Yakov et al.,

Thanks for the 02 revision

The new text in the Abstract and Introduction goes a long way to addressing 
my concerns.

   The scope and applicability of this attribute currently excludes its
   use for non-VPN deployment scenarios.

But it doesn't answer my multi-AS question. What will an ASBR advertise 
onwards?

The TE parameters that it receives from the source PE are the TE parameters 
of the PE-CE link to a specific port. If it advertises those parameters it 
is clearly not advertising the TE parameters of the route, but I am not 
clear how a BGP speaker down the line can tell that this is just the PE-CE 
link that is being described. But to do otherwise would imply that the ASBR 
is making some assessment of the TE route available from the ASBR to the PE.

This is the question I was trying to raise about "TE aggregation" (which is 
*not* route aggregation).

It seems to me that this whole question is either out of scope of requiring 
significant future study.

Probably the solution that can get us to closure most quickly is one where 
we update your new text to say...

   The scope and applicability of this attribute is currently limited to
   single-AS VPN deployment scenarios.

I would also like to see a somethinto Section 4 along the lines 
of...

   Traffic engineering aggregation is the process of reporting a set of TE
   parameters for a single route where multiple paths exist across the
   domain. The results of TE aggregation MUST NOT be advertised
   using the Traffic Engineering Attribute.

Cheers,
Adrian


_______________________________________________
Softwires mailing list
Softwires at ietf.org
https://www.ietf.org/mailman/listinfo/softwires


g added to Section 4 along the lines 
of...

   Traffic engineering aggregation is the process of reporting a set of TE
   parameters for a single route where multiple paths exist across the
   domain. The results of TE aggregation MUST NOT be advertised
   using the Traffic Engineering Attribute.

Cheers,
Adrian


_______________________________________________
Softwires mailing list
Softwires at ietf.org
https://www.ietf.org/mailman/listinfo/softwires



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.