Re: [Idr] draft on virtual aggregation

Daniel Ginsburg <dg@ot-e.biz> Wed, 09 July 2008 00:12 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BC903A6AB4; Tue, 8 Jul 2008 17:12:48 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566C43A6AB4 for <idr@core3.amsl.com>; Tue, 8 Jul 2008 17:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.571
X-Spam-Level:
X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_RU=0.875, J_CHICKENPOX_52=0.6]
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 jJ1ErSMglXdJ for <idr@core3.amsl.com>; Tue, 8 Jul 2008 17:12:46 -0700 (PDT)
Received: from iddater.nxceso.com (iddater.malpaso.ru [89.108.83.67]) by core3.amsl.com (Postfix) with ESMTP id 3F1603A6905 for <idr@ietf.org>; Tue, 8 Jul 2008 17:12:43 -0700 (PDT)
Received: from [83.167.114.17] (helo=[192.168.1.254]) by iddater.nxceso.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <dg@ot-e.biz>) id 1KGNIh-0003H3-19; Wed, 09 Jul 2008 04:12:51 +0400
Message-ID: <4874027B.8050800@ot-e.biz>
Date: Wed, 09 Jul 2008 04:12:43 +0400
From: Daniel Ginsburg <dg@ot-e.biz>
User-Agent: Icedove 1.5.0.10 (X11/20070328)
MIME-Version: 1.0
To: Paul Francis <francis@cs.cornell.edu>
References: <37BC8961A005144C8F5B8E4AD226DE1109D829@EXCHANGE2.cs.cornell.edu> <4873DA60.3010604@ot-e.biz> <37BC8961A005144C8F5B8E4AD226DE1109D838@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <37BC8961A005144C8F5B8E4AD226DE1109D838@EXCHANGE2.cs.cornell.edu>
Cc: idr@ietf.org
Subject: Re: [Idr] draft on virtual aggregation
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Paul Francis wrote:

> Ok, I'll dig back into RFC5036.  I was assuming that, since the external
> router is the target of the tunnel, but since the border router detunnels,
> then this meant PHP.  
> 

Since the border router is the first one which assigns a label to a 
prefix, I think it qualifies as ultimate hop. Just in case: I assume 
that the draft doesn't require speaking LDP to an external peer, right?

>> terminology). I.e. it means that a border VA router must not advertise
>> implicit (or explicit) null label for FECs corresponding to external
>> next-hops. 
> 
> I'm afraid that I'm not up enough on MPLS terminology to even know what the
> above means.  My bad.  I'll figure it out.

It simply means that a border router must assign a separate non null 
label for each external next-hop to be able avoid doing L3 lookup for 
any of egressing packets and switch the packets solely on that label. I 
think this is what you intended in your draft.

I think that there might be some implementation difficulties when 
there're multiple external next-hops on a multiple access link, but I'll 
leave this to others, who are far more knowledgeable than me about 
current implementations, to comment.

> 
>> Also section 3.2.3 implies that external next-hops must be
>> carried inside AS' IGP, and IMHO the draft should explicitly say so.
> 
> Good point---will add this in the next version.  BTW, of course another
> approach would be to use stacked labels, with the outer label targeting the
> border router, and the inner label identifying the external peer.  I'd love
> to hear what people think of this as an alternative (or additional) approach.
> 

Well, you might need to extend LDP to be able to do that. Probably, 
procedures outlined in Kireeti Kompella's presentation 
(http://www.isocore.com/mpls2007/cd/Presentations/132%20Kireeti%20Kompella.pdf) 
might help. Though I'm not sure about standardization status of this 
approach.

>> Another problem is mixing legacy hop-by-hop forwarding and VA. Consider
>> the following topology.
>>
>>      10
>> A--------B
>> |        |
>> |100     | 10
>> |        |
>> C--------D------E
>>     10       10
>>
>> A, B, D are VA routers. A is APR. B and E are legacy routers capable of
>> only hop-by-hop forwarding, i.e. not doing MPLS. Link metrics are
>> shown.
>>
>> Packets ingress the topology at A. They get forwarded to B as plain IP
>> since B is not an LSR. B forwards plain IP packets to D. D is a VA
>> router and has suppressed the specific routes, thus it sends the
>> packets
>> back to A.
> 
> Yes.  This is why the draft states (clearly, I hope!) that legacy routers
> must at least do MPLS.  If this is a problem (i.e., there are legacy routers
> that don't do MPLS), then I believe that there is a way around this problem,
> but it is a bit complex and I'd like to avoid it.
> 

As I read the draft you still reserve a possibility of throwing 
hop-by-hop forwarding routers into the mix (section 2.1 and 3.2.1). 
IMHO, it is the best to avoid complexities of such configuration and 
strictly require all the routers to do MPLS.


> PF
> 
>> --
>> dg

-- 
dg
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr