[manet] Re: Proposed tweaks to charter text
Christopher Dearlove <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <[email protected]> |
We would not have got OLSRv2 accepted as Standards Track were it intended only for isolated MANETs. In fact even OLSRv1 had associated networks. These allow the MANET to be at least an edge network, though a transit network might be tricky, as might be a multi-homed network - and if you want address autoconfiguration, that too. I think probably most people always had that as an intended use case. So I would characterise the situation not quite as you describe it, but more that while non-isolated MANETs have always been an intended use case, there’s more work needed for full flexibility (although some basic cases work). I also don’t think what’s needed is part of, for example, OLSRv2 but rather something, or things, working at a gateway - and if more than one, maybe communicating. That would then feed into OLSRv2 through the existing gateway (associated network) mechanism (noting that OLSRv2, unlike OLSRv1 has metrics available to help). But what’s really need for that is someone who has tried and can say on the basis of experience, this works already, out of the box, this we know how to make work, but it needs formalising, and this we don’t yet know how to make work. And has motivation to do those things. > On 4 Nov 2024, at 18:44, Templin (US), Fred L <[email protected]> wrote: > > Ronald, I was going to hold this comment until the wg meets tomorrow, but since you are > accepting charter updates on the list I would like to propose the following. Up to now, the > MANET working group has been focused on routing protocols and DLEP services for isolated > MANETs that might never connect to the global public Internet. But, the new charter should > include a work item for an autoconfiguration and Internetworking service for connecting > MANETs up to the Internet. I am short on time and unable to draft significant text to > propose for the charter at this time, but I wanted to float the idea prior to the session > tomorrow. > > Thank you - Fred > >> -----Original Message----- >> From: Velt, R. (Ronald) in 't <[email protected]> >> Sent: Monday, November 04, 2024 10:08 AM >> To: Juliusz Chroboczek <[email protected]>; manet <[email protected]> >> Cc: [email protected] >> Subject: [manet] Re: Proposed tweaks to charter text >> >> Hi Juliusz, >> >>> >>> Hi, and sorry for the delay. >> >> My turn to apologize for delay, times fifty. >> >>> >>> qHere are a few proposed tweaks to the charter text. Most are fairly >> minor, >>> the only one I feel strongly about is the removal of the sentence about >> the >>> overhead of proactive protocols. I also feel it's important to mention >> that the >>> reliance of PIM-SM on RPF disqualifies it from (most) MANETs, lest >> somebody >>> be misled into thinking that PIM-SM can be easily tweaked. >> >> Many thanks for these. I have updated the draft charter text, incorporating >> all of your proposed changes: see attachment. However, I have comments on a >> few of them, which you will find below. >> >>> >>> >>> OLD: the protocol for exchange for link-related information >>> >>> NEW: the protocol for exchange of link-related information >> >> Fixed. >> >>> >>> >>> OLD: (mixtures of fixed and mobile routers) >>> >>> NEW: (mixtures of fixed and mobile routers, and of wired and wireless >> links) >> >> Applied. >> >>> >>> >>> OLD: Babel and OLSRv2 meet this requirement >>> >>> NEW: Babel and OLSRv2 meet these requirements >> >> Fixed. >> >>> >>> >>> OLD: manual configurations or the inference of state through routing or >>> transport protocols does not allow the router to make the best >>> decisions. >>> >>> NEW: manual configurations or the inference of state through routing or >>> transport protocols is not practical. >> >> Well, depending on how dynamic the network and its environment are (in terms >> of node movement, propagation conditions, etc.), an ad hoc network may or >> may not be able to function based on exchanged layer 3 routing protocol >> information alone. Applied anyway. >> >>> >>> >>> OLD: The main advantage of reactive solutions is low protocol overhead. >>> >>> NEW: (remove this sentence) >> >> Sentence removed. However, does this mean that you are of the opinion that >> reactive ad hoc routing protocols will under no circumstances have an >> advantage over pro-active ad hoc routing protocols? >> >>> >>> >>> OLD: Traditional multicast routing solutions (e.g., PIM SM) tend to >> perform >>> poorly in mobile ad hoc network environments, due to high churn of >>> maintaining group membership state in the nodes in frequently >> changing >>> network topologies. >>> >>> NEW: Traditional multicast routing solutions, such as PIM-SM, are not >>> applicable to the MANET environment due to their reliance on RPF as >>> well as to the high churn of maintaining group membership state in >>> frequently changing network topologies. >> >> Applied. >> >>> >>> >>> OLD: homogeneous link layer / physical layer technologies. >>> >>> NEW: homogeneous link and physical layer technologies. >> >> Fixed. >> >>> >>> >>> OLD: The WG will explore multicast routing solutions in support of >>> heterogeneous wireless technology configurations and federated mobile >>> ad hoc networks. >>> >>> NEW: The WG will explore multicast routing solutions that are applicable >>> in mobile ad-hoc networks and heterogeneous network topologies. >>> >> >> Applied, although I was rather attached to the "federated mobile ad hoc >> networks" formulation. >> >>> >>> OLD: Multicast solutions for mobile ad hoc networks based on heterogeneous >>> wireless technologies >>> >>> NEW: Multicast solutions for mobile ad hoc networks based on >>> heterogeneous, >>> wired and wireless technologies >> >> Applied. >> >>> >>> >>> OLD: Exploring feasibility of Standards Track reactive routing solution >>> based on AODVv2 >>> >>> NEW: Exploring feasibility of Standards Track reactive routing solutions, >>> possibly based on AODVv2 >>> >> >> Yes, that's better. Let's not constrain ourselves unnecessarily here. >> Perhaps the paragraph on reactive routing protocols in the main body of the >> charter text needs to be changed accordingly. Applied. >> >>> >>> OLD: Progressing DAT-metric specification >>> >>> NEW: Progressing DAT metric specification >> >> Fixed. >> >>> >>> >>> OLD: Babel extensions >>> >>> NEW: Babel extensions and maintenance >> >> Fixed. (Should the order be: "maintenance and extensions" ?) >> >>> >>> >>> OLD: OLSRv2 extensions >>> >>> NEW: OLSRv2 extensions and maintenance >> >> Fixed. >> >>> >>> >>> OLD: DLEP extensions, DLEP corrections & clarifications document >>> >>> NEW: DLEP extensions and maintenance >> >> Yes, "maintenance" is more general and would cover a C & C document. (See >> meeting materials from MANET session at IETF 110 for a discussion on the >> need for such a document) >> >> Thanks again, >> Ronald > > _______________________________________________ > manet mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]