Hi, Toni, Although I'm not supporting the 'pure'(?) Loc/ID separation (LIS) having a separate ID and one or more Locators for a node, your arguments defending to have a 'overloaded' ID to refer to the node itself rather than the interface are well put, I'd think.
One confusion we still have is that different people mean different things by LIS. And classifying proposals of different technical flavor all as CEE is also sometimes confusing. I'm afraid we're not done clear cut with terminologies yet. Details of technical operation is more relevant than 'mal-defined' terminologies, I'd think. On Fri, Oct 1, 2010 at 11:36 PM, Toni Stoev <[email protected]> wrote: > 2010.9.30 четв 17:58:43 Robin Whittle: > > Hi Toni, > > you asked another question: > > > do you consent that nodes (instead of interfaces) have to be > > > referenced with locators(addresses)/identifiers? > > > > I do not support the change you are suggesting, which I understand > > involves changing the Internet protocols to coerce all nodes to > > communicate only in terms of themselves, irrespective of what > > interfaces they are using. > > The change is relevant to the general communication between nodes where > packet relaying occurs. > The distinction of nodes' interfaces is only adequate in physical > communication between neighbors. > > > One reason is that a node might not want incoming traffic to arrive on > > all its interfaces. Another is that it might not want to send traffic > > on all its interfaces. > > Should the node bother its overseas correspondents with that? Sending them > packets with interface reply-to addresses. > For traffic arriving on particular interfaces nodes shall make arrangements > with their linked gateways. For sending, each node's decision is its own > business. > > > Some interfaces may be slow, expensive or unreliable - or the node may > > want to avoid using them so they are ready to accept some other stream > > of packets. > > So if you are a node, make the choice for yourself. Don't make remote (more > than a hop away) nodes take the burden of your inner considerations. > > > Some interfaces might, for policy reasons, be unsuitable for > > particular types of communication. Some interfaces might use networks > > with too high a latency, or too high a packet loss, or too small an MTU. > > These are node's own regulations, so nodes shall apply them with internal > means. > > > So, to make your idea workable, I think a given physical computer > > would need to generate multiple Identities, with each such Identity > > assigned a set of its Interfaces suitable for particular kinds of > > communication. > > No. Particularization of those kinds of communication is the computer's own > affair. So the computer shall take care of identification of the various > kinds of communication internally. > > > This can already be done by any application which is suitably written, > > as I just described. > > This is a hand-over of the responsibility for communication policy to a > certain other layer. > OK, to easily jump among "layers" we just need Role-Based Architecture, > where each function is performed by a relevant actor - application, protocol > heap, driver. http://isi.edu/newarch/DOCUMENTS/hotrba.paper.pdf > And still the identification of a node's points of attachment to links is > its own matter, and we don't need it in the inter-node path selection > system. > > When a node communicates to its neighbor it just needs the data sent to and > received by the neighbor. If the node minds the links to its neighbor, it > shall take care fore that itself; it may arrange special link usage with the > neighbor. > When a node communicates to a distant node (more than a hop away) it still > just needs the data sent to and received by the distant node. The sending > node generally doesn't need to mind the links of the corresponding node; > it's the business of the correspondent and its neighboring gateways. > So, the address/locator a node needs to put in a packet to another node > just has to be of that entire node. > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > -- DY
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
