Subject: I-D ACTION:draft-fletcher-bgp-inactive-path-00.txt

From: [email-masked]
Date: Tue, 14 Jan 2003 10:12:42 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Inactive Path Advertisement in BGP-4
	Author(s)	: J. Fletcher
	Filename	: draft-fletcher-bgp-inactive-path-00.txt
	Pages		: 4
	Date		: 2003-1-13
	
This document defines BGP capabilities and a path attribute to permit
advertisement of routes other than those selected during the BGP
decision process.  These extensions would provide additional routing
information for research, monitoring and policy decisions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fletcher-bgp-inactive-path-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-fletcher-bgp-inactive-path-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-fletcher-bgp-inactive-path-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 14 Jan 2003 17:19:46 +0100

Hi Justin,

Do you see anything not addressed already by: draft-walton-bgp-add-paths
which would support proceeding with your draft any further ?

Thx,
R.

PS URL:
http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-01.txt

> [email-masked] wrote:
> 
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: Justin Fletcher <[email-masked]>
Date: Tue, 14 Jan 2003 14:31:53 -0800 (PST)

> which would support proceeding with your draft any further ?

While we definitely have the same goals in mind, I think there are a few 
issues that merit further disucssion.

If in draft-walton-bgp-add-paths all nexthops are included with each route 
adertisement this may result in an increase in the volume of data to 
transferred and processed during normal operations.  If a change in 
availability of a single undertised nexthop is indicated by setting both
the FirstPath and LastPath bits, this isn't an issue.  The statement that 
"any paths received before this one MUST be removed by the receiver" leads
to some questions of interpretation.

The addition of configuration options and a receive capability allows 
additional flexibility in deployment.

Finally, it's a minimalist approach; there are no changes to the protocol 
format itself.
-- 
Justin Fletcher
Proficient Networks, Inc.

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 14 Jan 2003 18:24:53 -0500

Hi Justin,

Comments in line below.

At 2:31 PM -0800 1/14/03, Justin Fletcher wrote:
>transferred and processed during normal operations.

It was certainly not our intent that all routes ("paths") for a given 
NLRI be readvertised whenever one single path changes.  I take it 
this is what you're referring to when you say "nexthops"?

>If a change in

We should clean those up then.  Perhaps you can elaborate on the 
required clarification either on this list or off-line.  Just to 
clarify for now:

- Our draft (like yours) advertises multiple _routes_, not just nexthops.
- Any single route may be advertised or withdrawn without affecting the
   other routes for the same NLRI.
- The FirstPath flag provides implicit-withdraw semantics for the whole
   batch of paths for that NLRI.  Sounds like that's what you're concerned
   about?  Sending FirstPath is optional.

Also, note that we plan to remove the LastPath flag in a forthcoming 
revision.  You'll see this mentioned in the minutes of the last IDR 
WG meeting.

>additional flexibility in deployment.

I don't think there's a deep difference between the two proposals in 
terms of configurability, which is fundamentally an implementation 
issue.  Clearly an add-path implementation can (and perhaps should) 
default to working in plain-old-BGP mode.  Leaving this up to the 
implementor is more to my taste, though.

It's not clear to me what the deployment case is for splitting the 
capability's semantics into Tx/Rx.  If there is a need, however, we'd 
be happy to add it to add-path.

>Finally, it's a minimalist approach; there are no changes to the protocol

Here are a few concerns I have about your approach:

- I don't see a way to withdraw a path.  Lack of an easy way to withdraw
   paths is a key reason why we decided not to pursue a similar attribute-
   based approach when we were coming up with add-path.
- It doesn't appear to enable multiple active paths.  There may be some
   use for this in the future, notably for doing multipath in a clean way.

Regards,

--John

---

From: Justin Fletcher <[email-masked]>
Date: Tue, 14 Jan 2003 19:51:27 -0800 (PST)

On Tue, 14 Jan 2003, John G. Scudder wrote:

John, thank you; I'll embed a few as well.

> this is what you're referring to when you say "nexthops"?

Precisely, and thank you for the clarification.  Semantics can be a little 
tricky :-)

> - Our draft (like yours) advertises multiple _routes_, not just nexthops.

Right; just semantics.

>    about?  Sending FirstPath is optional.

Yes. I belive that ability is required to remove an entire prefix, to 
add or remove a single route for the same NLRI or to change that route 
to/from unadvertised to advertised.

> implementor is more to my taste, though.

I chose to formalize the "perhaps should" but can go either way.

> be happy to add it to add-path.

I believe that this may simplify both processing and implementation;
it would also allow a router to operate in a limited or test mode
where the additional information is received and processed without being 
required to advertise all paths.

>    based approach when we were coming up with add-path.

Tian noticed this issue as well, and I just realized I didn't send my 
response to the WG as well.

Rather than extending the format for withdrawn routes, this can be handled 
by adding an INACTIVE_WITHDRAW attribute to indicate removal of an 
unadvertised nexthop (path) and including the prefix and nexthop in the 
Network Layer Reachability Information.

>    use for this in the future, notably for doing multipath in a clean way.

True.  Perhaps this could also be addressed by an additional attribute.

> --John

Best,
Justin