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
- IDRP for IPv6 RD path Paul Traina