Re: BGP TE attr last call by softwires WG
"Adrian Farrel" <adrian@olddog.co.uk> Thu, 21 August 2008 10:07 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079953A6850 for <ietfarch-ccamp-archive@core3.amsl.com>; Thu, 21 Aug 2008 03:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.202
X-Spam-Level:
X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 5zMdjbns44iQ for <ietfarch-ccamp-archive@core3.amsl.com>; Thu, 21 Aug 2008 03:07:21 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DED943A6820 for <ccamp-archive@ietf.org>; Thu, 21 Aug 2008 03:07:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KW6vO-000Mx7-Bn for ccamp-data@psg.com; Thu, 21 Aug 2008 09:57:50 +0000
Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1KW6vK-000MwH-21 for ccamp@ops.ietf.org; Thu, 21 Aug 2008 09:57:48 +0000
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m7L9s9gT024922; Thu, 21 Aug 2008 10:54:09 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m7L9s4ID024841; Thu, 21 Aug 2008 10:54:08 +0100
Message-ID: <001f01c90373$da047f60$0300a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: softwires@ietf.org
Cc: dward@cisco.com, alain_durand@cable.comcast.com, ccamp@ops.ietf.org, Yakov Rekhter <yakov@juniper.net>, Don Fedyk <dwfedyk@nortel.com>, Hamid Ould-Brahim <hbrahim@nortel.com>
References: <200808130902.m7D929Xi030025@mta4.iomartmail.com>
Subject: Re: BGP TE attr last call by softwires WG
Date: Thu, 21 Aug 2008 10:53:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
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
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Hi, > From: David Ward <dward@cisco.com> > Sent: Tue Aug 12 23:48 > Subject: BGP TE attr last call by softwires WG > > The softwire WG has LC'ed > > http://www.ietf.org/internet-drafts/draft-ietf-softwire- > bgp-te-attribute-01.txt > > We will keep open an additional two-week period for wider > review before moving forward in the publication process. > Please have any comments to the authors and softwires WG > by Aug 26, 2008. I have no objection to the basic idea of distributing TE information about CE-PE links especially for use in VPNs. But I am worried by one aspect of the document. Hopefully this is just an editorial issue. The last call in Softwires appears to have generated some discussion about aggregation, and this led to the addition of section 4. | 4. Implication on aggregation | | Routes that carry the Traffic Engineering Attribute | have additional semantics that could affect traffic | forwarding behavior. Therefore, such routes SHALL NOT | be aggregated unless they share identical Traffic | Engineering Attributes. As far as it goes, this paragraph is great. It says "do not perform route aggregation unless it is sensible to do so." But it says nothing about TE aggregation. Notwithstanding the TE attribute is non-transitive, there is the potential for an implementation to believe that it should provide some form of TE aggregation. Consider two cases: 1. A CE is attached by parallel links to a single PE Suppose the links have the same switching types, but different bandwidths. Link-a has plenty of bandwidth available with an MTU size of x. Link-b has not much bandwidth available with an MTU size of y > x. Normally, we would expect the PE to advertise a single piece of reachability information for the CE leaving the actual choice of links to be made by the PE. What would the PE advertise in this case? - It cannot aggregate the TE information because that would imply that there was lots of bandwidth at the larger MTU size. - It could include duplicate Switching Capability Descriptors, but that would need some clarification as duplicate descriptors are intended for different switching caps in the IGP RFCs. - It could advertise two pieces of reachability information, but that would be a change to how the implementation currently works. 2. There is more than one AS Consider CE1--PE1...AS1...ASBR1--ASBR2...AS2...PE2--CE2 PE2 advertises reachability to CE2 and includes TE information. The TE attribute is non-transitive so it is not just passed on, but ASBR2 wants to announce reachability to CE2 (in the VPN case, we may want to support a multi-AS VPN). So ASBR2 can advertise reachability to CE2, but what TE parameters does it advertise? The parameters for the link PE2-CE2 are not so helpful because the TE reachability across AS2 may be different. Yet any attempt to perform a computation of the TE reachability across AS2 (i.e. TE aggregation) is complex and potentially unstable. (Of course, if a tunnel is pre-established between ASBR2 and PE2 this is a different matter.) I think that these two different scenarios need attention in the I-D. For the first one, it may just be a matter of indicating which approach is to be used. For the second one, I hope the answer is to recommend against any form of TE aggregation. This could easily be added to section 4, and I would be happy to provide text. BUT, it will still leave open the question about if and how TE information is propagated beyond the AS. Thanks for any clarifications. Adrian
- BGP TE attr last call by softwires WG Adrian Farrel
- Re: BGP TE attr last call by softwires WG Adrian Farrel
- RE: BGP TE attr last call by softwires WG Don Fedyk
- Re: BGP TE attr last call by softwires WG Adrian Farrel
- Re: BGP TE attr last call by softwires WG JP Vasseur
- Re: BGP TE attr last call by softwires WG Yakov Rekhter
- Re: BGP TE attr last call by softwires WG Yakov Rekhter
- Re: BGP TE attr last call by softwires WG Adrian Farrel
- Re: BGP TE attr last call by softwires WG (2nd qu… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: BGP TE attr last call by softwires WG Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Lou Berger