Re: [Softwires] BGP TE attr last call by softwires WG
Yakov Rekhter <yakov@juniper.net> Tue, 26 August 2008 12:59 UTC
Return-Path: <softwires-bounces@ietf.org>
X-Original-To: softwires-archive@megatron.ietf.org
Delivered-To: ietfarch-softwires-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4976C3A6AD8; Tue, 26 Aug 2008 05:59:30 -0700 (PDT)
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AAA928C1A4 for <softwires@core3.amsl.com>; Tue, 26 Aug 2008 05:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.811
X-Spam-Level:
X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
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 NSBP0fY-pacx for <softwires@core3.amsl.com>; Tue, 26 Aug 2008 05:59:28 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id A9FBF3A69CA for <softwires@ietf.org>; Tue, 26 Aug 2008 05:59:22 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Tue, 26 Aug 2008 05:58:07 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:20 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:20 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Aug 2008 05:54:19 -0700
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m7QCsJu33149; Tue, 26 Aug 2008 05:54:19 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200808261254.m7QCsJu33149@magenta.juniper.net>
To: Adrian Farrel <adrian@olddog.co.uk>
In-reply-to: <001f01c90373$da047f60$0300a8c0@your029b8cecfe>
References: <200808130902.m7D929Xi030025@mta4.iomartmail.com> <001f01c90373$da047f60$0300a8c0@your029b8cecfe>
X-MH-In-Reply-To: "Adrian Farrel" <adrian@olddog.co.uk> message dated "Thu, 21 Aug 2008 10:53:59 +0100."
MIME-Version: 1.0
Content-ID: <46141.1219755259.1@juniper.net>
Date: Tue, 26 Aug 2008 05:54:19 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-OriginalArrivalTime: 26 Aug 2008 12:54:19.0715 (UTC) FILETIME=[DAED2930:01C9077A]
Cc: ccamp@ops.ietf.org, softwires@ietf.org
Subject: Re: [Softwires] BGP TE attr last call by softwires WG
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: softwires-bounces@ietf.org
Errors-To: softwires-bounces@ietf.org
Adrian, > 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. I already answered this in my other e-mail yesterday. > 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. For the second one the answer is in rfc5251: Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document. Yakov. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
- Re: [Softwires] BGP TE attr last call by softwire… David Ward
- [Softwires] BGP TE attr last call by softwires WG David Ward
- [Softwires] BGP TE attr last call by softwires WG Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Samita Chakrabarti
- Re: [Softwires] BGP TE attr last call by softwire… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Samita Chakrabarti
- Re: [Softwires] BGP TE attr last call by softwire… Don Fedyk
- Re: [Softwires] BGP TE attr last call by softwire… Samita Chakrabarti
- Re: [Softwires] BGP TE attr last call by softwire… Don Fedyk
- Re: [Softwires] BGP TE attr last call by softwire… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Yakov Rekhter
- Re: [Softwires] BGP TE attr last call by softwire… Adrian Farrel
- Re: [Softwires] BGP TE attr last call by softwire… 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… 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… 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