Re: [RRG] RRG process clarification

In einer eMail vom 02.05.2008 17:55:18 Westeuropäische Normalzeit schreibt lixia@CS.UCLA.EDU:

Folks,

it's been exactly 2 weeks since the above msg was posted. There was an
initial exchange of msgs on this thread, mainly expressing agreement
with the proposed direction together with clarifications on several
specific issues. However that exchange stopped shortly after, as
opposed to continue on to articulate and propose what should be our
decision on that very highest level branches in the decision tree. In
fact the list has been uncharacteristically quiet this week:)

On this thread I suggested to relax the IPv4 depletion issue by replacing the Multicast addresses with a new "Multicast" Protocol Type combined with the sender's Unicast address. Indeed, the reaction was absolute silence. I expected at least opposition by referring to backward compatability (what is taken, is taken) and that it may need some flag day, announced well in advance. IMO, who can check for class D, may as well check for a new protocol type. But the reaction was a storm of unsent messages.

I also meant it architecturally: I think the type of operation (or should I say TOS ?) is worth to be indicated in the header. It could be p2p-Unicast as well as p2p-Anycast, p2mp-Multicast, p2mp-Broadcast, mp2mp-Multicast, mp2mp-Broadcast, and (who knows ) mp2p. Indicating the type of operation by means of different address ranges is a bad design.

Imagine, at some point in time in the future, there were some desire for multiple address families.

Should then each AFI be combined with a respectively special address range as to indicate the type of processing? It would even be worse -architecturally.

Heiner