[manet] Re: [EXTERNAL] Re: Proposed tweaks to charter text

Thank you - your response seems consistent with my perception that a badly needed extension
to the charter is to include a work item for an autoconfiguration and Internetworking service that
can connect MANETs up to the global public Internet and/or other Internetworks.

Fred 

> -----Original Message-----
> From: Christopher Dearlove <[email protected]>
> Sent: Monday, November 04, 2024 11:03 AM
> To: Templin (US), Fred L <[email protected]>
> Cc: Velt, R. (Ronald) in 't <[email protected]>; Juliusz Chroboczek <[email protected]>; [email protected] List <[email protected]>; manet-
> [email protected]
> Subject: [EXTERNAL] Re: [manet] Proposed tweaks to charter text
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> 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]