Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document

[Richard Ogier <[e-mail]>]

Retana, Alvaro wrote:

[e-mail]" type="cite">

Richard:

 

You’re right to say that the MANET solution can handle the special case of a single-hop broadcast network, if one was encountered.  The deployment lesson that we’re taking from that scenario is that it is operationally simpler to work w/one type of interface: one neighbor discovery process, one interface description model, etc…specially in cases where the ability to configure and troubleshoot the network in the field is greatly reduced by both access to the nodes as well as the potential abilities of the operators, which is the case in some of the deployments of rfc5820.

 

IOW, in a mobile network that may include multi-hop and single-hop interfaces, it is operationally preferred to deploy just one type of interface model.

That may be true.  But you are specifying a number of changes for a single-hop interface, including not setting the A-bit (so there are no active ORs), enabling flooding for all unsynchronized adjacencies, a simplified reachability check for smart peering, etc.  So one could argue it is really a different interface type.  Since the hybrid-bcast-p2mp draft requires only a small number of changes to OSPF, another approach would be to use that method for single-hop interfaces (i.e., elect a DR/BDR for that interface, etc.) and include this in the spec for OSPF-OR.  This would be easy with OSPF-MDR because it already elects a DR (called MDR) in single-hop networks.  But it should also be possible to do this with OSPF-OR.

Another thing that would make it desirable to integrate the hybrid-bcast-p2mp into OSPF-OR is if it is found to perform better or to be more scalable than smart peering.  It would be interesting to run simulations to compare these two approaches.

Richard

[e-mail]" type="cite">

Thanks!

 

Alvaro.

 

From: Richard Ogier [mailto:[e-mail]]
Sent: Monday, May 09, 2011 4:19 PM
To: Retana, Alvaro
Cc: [e-mail]
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document

 

In my opinion, the hybrid-bcast-and-p2mp draft is a simple and perfect solution to this problem:
http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt" rel="nofollow">http://tools.ietf.org/id/draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.txt

This has been discussed and some of us agree with this.  For example, Jeffrey Zhang's post dated 4/11/2011 summarizes some of the arguments.

Although both RFC 5820 (OSPF-OR) and RFC 5614 (OSPF-MDR) can be applied to single-hop broadcast networks and thus solve the same problem as the hybrid-bcast-p2mp draft, the hybrid draft is clearly the simplest solution, involving minimal changes to OSPF.

If the network is definitely a single-hop network, so that each router is one hop from all other routers, then there is no need for a MANET solution.  Otherwise, we need a MANET solution, which will also handle the special case of a single-hop network if by chance the network is single-hop (and this can be mentioned in the MANET draft).

But I would never apply a MANET solution if the network is definitely a single-hop network; I would go with the simpler solution in the hybrid draft.  For this reason, I don't think it makes sense to propose applying an OSPF-MANET extension to the case of a single-hop broadcast network.  But if someone can describe a situation where it makes sense to do this, please do so.

Richard


Retana, Alvaro wrote:

Hi!

 

Following up on the WG meeting in Prague…

 

http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop" rel="nofollow">http://tools.ietf.org/html/draft-retana-ospf-manet-single-hop

 

A brief poll at the meeting found no objection to this update to rfc 5820.

 

This e-mail is the formal request for adoption as a WG document.  Just like rfc 5820, the intended status is Experimental.

 

Thoughts/comments?

 

Thanks!

 

Alvaro.

 

_______________________________________________

OSPF mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ospf" rel="nofollow">https://www.ietf.org/mailman/listinfo/ospf