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