Re: [Idr] draft on virtual aggregation

Paul Francis <francis@cs.cornell.edu> Tue, 08 July 2008 23:02 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 2037828C2FD; Tue, 8 Jul 2008 16:02:00 -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 DBD8128C2FD for <idr@core3.amsl.com>; Tue, 8 Jul 2008 16:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.842
X-Spam-Level:
X-Spam-Status: No, score=-5.842 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, J_CHICKENPOX_52=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 0PKqyIkNahjJ for <idr@core3.amsl.com>; Tue, 8 Jul 2008 16:01:50 -0700 (PDT)
Received: from exch-hub2.cs.cornell.edu (mail-hub-2.cs.cornell.edu [128.84.103.139]) by core3.amsl.com (Postfix) with ESMTP id 0BE1C3A6880 for <idr@ietf.org>; Tue, 8 Jul 2008 16:01:27 -0700 (PDT)
Received: from EXCHANGE1.cs.cornell.edu (128.84.96.42) by mail-hub.cs.cornell.edu (128.84.96.245) with Microsoft SMTP Server id 8.0.783.2; Tue, 8 Jul 2008 19:01:36 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 19:01:36 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 08 Jul 2008 19:01:35 -0400
Message-ID: <37BC8961A005144C8F5B8E4AD226DE1109D838@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <4873DA60.3010604@ot-e.biz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft on virtual aggregation
Thread-Index: AcjhQKbBKqLrzVnQRRCAhyv6hNKYjQACdUaw
References: <37BC8961A005144C8F5B8E4AD226DE1109D829@EXCHANGE2.cs.cornell.edu> <4873DA60.3010604@ot-e.biz>
From: Paul Francis <francis@cs.cornell.edu>
To: Daniel Ginsburg <dg@ot-e.biz>
X-OriginalArrivalTime: 08 Jul 2008 23:01:36.0432 (UTC) FILETIME=[92A93300:01C8E14E]
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Thanks for your comments Dan.  Replies inline.  

> -----Original Message-----
> From: Daniel Ginsburg [mailto:dg@ot-e.biz]
> Sent: Tuesday, July 08, 2008 5:22 PM
> To: Paul Francis
> Cc: idr@ietf.org
> Subject: Re: [Idr] draft on virtual aggregation
> 
> Paul Francis wrote:
> > Its posted by IETF now.  At
> > http://www.ietf.org/internet-drafts/draft-francis-idr-intra-va-00.txt
> >
> 
> Paul,
> 
> I think that there're few problems with the draft.
> 
> One is with PHP. If a router is a border VA router, it must perform
> *ultimate*-hop-popping, not penultimate as section 3.2.3 of the draft
> states, since the router is egress for an LSP (as per RFC5036

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.  

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

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

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

PF

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