Re: [Idr] draft on virtual aggregation

Daniel Ginsburg <> Wed, 09 July 2008 00:12 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 3BC903A6AB4; Tue, 8 Jul 2008 17:12:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 566C43A6AB4 for <>; Tue, 8 Jul 2008 17:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.571
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jJ1ErSMglXdJ for <>; Tue, 8 Jul 2008 17:12:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3F1603A6905 for <>; Tue, 8 Jul 2008 17:12:43 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1KGNIh-0003H3-19; Wed, 09 Jul 2008 04:12:51 +0400
Message-ID: <>
Date: Wed, 09 Jul 2008 04:12:43 +0400
From: Daniel Ginsburg <>
User-Agent: Icedove (X11/20070328)
MIME-Version: 1.0
To: Paul Francis <>
References: <> <> <>
In-Reply-To: <>
Subject: Re: [Idr] draft on virtual aggregation
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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 
might help. Though I'm not sure about standardization status of this 

>> 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

Idr mailing list