> > => I don't understand the comment. The definition implies that you
 > > can't forward from a non-routing interface. Perhaps you mean
 > > that you should be able to forward _to_ a non-routing interface?
 > 
 >      no.  by making "router" per-interface, you could have multiple
 >      set of interfaces which forward packet to/from.  for instance,
 >      your router has 10 interfaces, and #1 is host mode, 
 > #2-#4 exchange
 >      traffic as router, #5-#9 exchange traffic as router 
 > (it's separate
 >      from #2-#4), and #10 is host mode.  

=> So far I understand.

   once you go into 
 > "router/host is
 >      a per-interface thing" you need to describe such 
 > combinaions in full
 >      detail.  

=> Not really. This is just a definition. When it comes to
which interface forwards to which other interface this is 
a matter of policy/configuration. If we were writing a document
about VPNs I would understand your expectation, but this is 
just a definition which applies, regardless of which interface
is forwarding to any other interface.


    > >  >      i'm for simple "router or host" in document, and leave 
 > >  > per-interface
 > >  >         "router" as a exercise for reader ("virtual router" 
 > >  > concept is not new
 > >  >         so vendors will make such device anyways).
 > > 
 > > => The issue at hand is that the doc is not clear on 
 > > nodes that are both hosts and routers. Do you see any
 > > harm in making the definition per interface? 
 > 
 >      yes.  i see a big harm and disambiguity introduced by 
 > the change.
 >      again, keep the document simple, and let vendors do 
 > funny/complex
 >      things if they want to.

=> Please see above. The change is only intended to indicate
that the forwarding is on a per interface basis and is not
intended to explain to vendors/operators how to build VPNs.

For instance, the definition of a router is a node that forwards
packets, intended for other nodes, from one interface to another. 
This definition stands regardless of the type of interface
a router might use (physical, tunnel ...etc). 

Hesham


===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to