RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt

["Teco Boot" <[e-mail]>]

> > I think it is easy to understand that a MANET Interface is an
> interface that
> > may suffer from certain link characteristics. We have similar kind of
> > interface types, like NBMA and P2MP.
> 
> No. NBMA is a link type, not an interface type. IPoverATM, for
> example, looks to IP just like a traditional IP-friendly link. There
> is a layer of software between IP and ATM that emulates the necessary
> services that IP needs (like ARP/broadcast). The ATM "interface",
> however, is just a normal interface. The IP layer does not know about
> the quirks of ATM and doesn't need to worry about the "challenges" in
> semantics in order for IP to work.
> 
> Another way to view things. Stuff that is "interface-specific" is
> normally implemented by a device driver (for the specific link layer),
> and not by IP.

OK, now we have something as "IP-friendly". Fully meshed, full broadcast. If
this is the case, we can use IP protocols as is.

In reality, some links are not that friendly. I think this is explained in
the MANET Architecture document quite well, but using some wrong terms. 
On wrong terms: For example section 4 "MANET Interface Characteristics" is
about the links. It should be "MANET Link Characteristics".

I think it is useful keeping the term MANET Interface, being used as "a
MANET Router's attachment to a MANET link". 
I am not sure if we should use MANET Interfaces for hosts.

I would like to use the RFC4861 based definition:
      interface       - a node's attachment to a link.
Any objection to:
      MANET Interface - a MANET Router's attachment to a MANET link
?


> > Now we want to define another.
> > Term MANET Interface is well known, e.g. it is used in MANET Routing
> > Protocol documents, including the OSPF ones.
> 
> The term "interface" is also well-known outside of MANET. If you look
> at RFC1122, for example, interface is about the interface beween
> layers (e.g, between IP and the link layer). The more general term
> "interface" (in terms of network software) is the data abstraction
> used to access the facilities of a particular network.
> > >    MANET Router (MNR)
> > >       A MANET router is distinguished by having one or more MANET
> > >       interfaces.  A MANET router may also have zero or more non-
> MANET
> > >       interfaces.  A MANET router is responsible for hiding MANETs'
> > >       challenging characteristics from nodes that are not MANET-
> aware.
> > >       A MANET router with a single MANET interface is illustrated
> in
> > >       Figure 1.
> > >
> > > No. the "interface/link" hides the challenging characteristics from
> > > IP. Not the BR itself. This is a critical point (architecturally)
> to
> > > get right.
> > >
> 
> > If this is true, we do not have to do anything special.
> 
> Well, I'm trying to understand whether this is the case or not.

I think it is obvious that if MANET is sub-IP, IP is not aware and all
protocols run well.

If you mean you want to know why this is a bad idea in some cases, I agree
that this should be described. It is, in the bottom of Section 6: MANETs'
Place in the Network Stack.

This is also described in RFC2501 5. IP-Layer Mobile Routing.
Maybe a reference to this section would help.


> 
> > > You really (I think) need to define an abstraction that defines an
> > > link type of "manet" that handles all the "interesting"
> > > characteristics of MANETs (like non-transitive connectivity) but
> that
> > > also presents itself to IP as a single IP subnet that has the
> normal
> > > properties.
> 
> > I think there are two MANET implementation models.
> 
> > One is hiding MANET form IP, e.g. a sub-IP MANET model. This is more
> or less
> > out-of-scope for IETF.
> 
> This could be done in the IETF, and maybe this is  a direction the WG
> may want to pursue. But is this even a model the WG is currently
> considering?
> 
> IMO, this is the _obvious_ model to implement, or rather, if any other
> model is needed, the case first needs to be made why the above model
> is not good enough (or better).

I think there are multiple models and there are valid reasons for this.


> 
> > The other model is described in this document.
> 
> And what model is that? 

L3 MANET.
I agree the readability of the document would be improved if both MANET
models are introduced very early in the document.


> The problem I have currently is I don't
> understand the scope of the problem. What is the abstraction. Where is
> the MANET-specific stuff implemented, and what is the boundary between
> this and what IP sees?
> 
> E.g., the MR model suggests that I can have an ethernet interface and
> two manet interfaces. Where does the MANET stuff sit (just above the
> two MANET interfaces?) What part is visible to IP (and why?) Does the
> MANET specific stuff get exported across the Ethernet? Why or why not?
> 
> Very basic questions, but the document doesn't make this clear at all.
> 
> > Now we have to face the reachability issues. I think the MANET
> > Router shall hide this for IP hosts and non-MANET routers.
> 
> Hide it from whom? What is the scope of where this information is
> supposed to be exported? 

Discussed in 5.3.  Routers and Hosts in a MANET.

Maybe we shall update RFC4294 IPv6 Node Requirements one day and add a
section on MANET.


> It's not good enough to say "within the
> MR". Where within the MANET router?  What part of the MR code is
> "normal, unmodified IP" and what part has to be MANET-aware?

Good questions, but more related to a Router Architecture. Do we work on
this or is it up to the implementers?


Teco.


> 
> Thomas



_______________________________________________
Autoconf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/autoconf