Subject: RE: additional requirements: capneg and policy discovery

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Nov 2001 09:08:39 -0800

> - - capabilities negotiation - Multihoming solutions must provide a
> means for peers to communicate capabilities to each other, in order
> to support new capabilities that may or may not be included in all
> implementations.

I think this is putting the car before the horse. Let's say there are
multiple multihoming solutions in service. Within each solution, the
capability negotiation (or the lack of one) should be left to the choice
of that solution.

In case more than one solution is available simultaneously, the
capabilities negotiation is a good idea because it would eventually
allow choosing the "best" one, but requires some understanding of each
solution pros and cons, and we are far from that point.

I think this could be changed to having a version number within each
packet. The behavior when two different versions are present should be
defined for each solution, when the next version is available.

> - - policy - Multihoming solutions should provide a means for peers
> to discover the routing policies applied to their routes by peer
networks.

I missed the email thread on that one; can we have it again? I am not
sure everyone would agree to do that.

---

From: Joe Abley <[email-masked]>
Date: Mon, 12 Nov 2001 12:59:06 -0500

> sure everyone would agree to do that.

It was a private message, which I am copying below, since it contains
some elaboration on that point (I should have included it before).

----- Forwarded message from Tony_Hiller <[email-masked]> -----

Delivered-To: [email-masked]
Date: Tue, 26 Jun 2001 17:49:41 -0500
From: Tony_Hiller <[email-masked]>
To: [email-masked]
Subject: suggestions for multi6 draft
User-Agent: Mutt/1.2.5i

Hi jabley,

I'd like to make some suggestions for your multihoming draft. They're probably pretty specific, and may be beyond the scope of your doc, but here goes:

- - capabilities negotiation - Multihoming solutions must provide a means for peers to communicate capabilities to each other, in order to support new capabilities that may or may not be included in all implementations. 

- - policy - Multihoming solutions should provide a means for peers to discover the routing policies applied to their routes by peer networks.

Uh, I don't like the way that sounds. Suffice it to say, I want some way to tell what filters my peers have in place at any given time. I realize this is asking for denial of service attacks, but it seems that such things could be minimized through proper authentication of peers. There are similiar drafts in idr right now - but I have no idea how close they are to running code. 

I'm not sure if these are outside your scope, but I'd see both (especially the first) as valuable capabilities. Just my thoughts...

hiller 

----- End forwarded message -----