IDRP for IPv6 RD path

Paul Traina <pst@cisco.com> Fri, 13 January 1995 16:42 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04320; 13 Jan 95 11:42 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04313; 13 Jan 95 11:42 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa08999; 13 Jan 95 11:42 EST
Received: by interlock.ans.net id AA26049 (InterLock SMTP Gateway 1.1 for iwg-out@ans.net); Fri, 13 Jan 1995 11:24:07 -0500
Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 13 Jan 1995 11:24:07 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 13 Jan 1995 11:24:07 -0500
X-Sender: pst@feta.cisco.com (Unverified)
Message-Id: <v0211010aab3a7c5d9975@[171.69.56.245]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 13 Jan 1995 08:24:02 -0800
To: bgp@ans.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Traina <pst@cisco.com>
Subject: IDRP for IPv6 RD path

As we've discussed in the working group, the plan was to revise IDRP for
IPv6 to use the same method for revising the RD (AS) PATH as BGP-4,  since
it seemed
more sensical and no-one could remember a good reason for changing it.

Since then, there's been some time spent trying to write the text that
would actually specify how to process non-nested RDC traversals, and in
fact, proper path modification requires information present at the entry of
the RD/RDC and exit,  so there in fact, IS, a good reason to do it the IDRP
way.

Unless someone can make an argument for simple path processing that doesn't
require additional attribute or configuration information to handle RDCs, the
draft text will keep things as they were done with IDRP.  This should present
no interaction problems with BGP4 as BGP4 has no concept of multiple levels
of RDCs so it's easy to fixup the path for an AS that's 1/2 IDRP and 1/2
BGP4.

Paul