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

From: "Retana, Alvaro" <[email-masked]>
Date: Mon, 9 May 2011 19:12:00 +0000

Hi!

Following up on the WG meeting in Prague...

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.

---

From: Richard Ogier <[email-masked]>
Date: Mon, 09 May 2011 13:19:12 -0700

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

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…

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: "Retana, Alvaro" <[email-masked]>
Date: Mon, 9 May 2011 20:58:54 +0000

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.

Thanks!

Alvaro.

From: Richard Ogier [mailto:[email-masked]]
Sent: Monday, May 09, 2011 4:19 PM
To: Retana, Alvaro
Cc: [email-masked]
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

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!

Thoughts/comments?

Thanks!

Alvaro.

________________________________

OSPF mailing list

[email-masked]<mailto:[email-masked]>

---

From: Richard Ogier <[email-masked]>
Date: Mon, 09 May 2011 17:11:22 -0700

Retana, Alvaro wrote:

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

Thanks!

Alvaro.

From:
Richard Ogier [mailto:[email-masked]]

To: Retana, Alvaro

Cc: [email-masked]

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:

Richard

Retana, Alvaro wrote:

Hi!

Thoughts/comments?

Thanks!

Alvaro.

OSPF mailing list

[email-masked]

---

From: Richard Ogier <[email-masked]>
Date: Mon, 09 May 2011 22:25:37 -0700

Alvaro,

One more point. If your network includes standard OSPF broadcast
interfaces (which don't require a different cost for each pair of
routers), then since RFC 5820 only specifies extensions for MANET
interfaces, I assume you will not apply RFC 5820 to such broadcast
networks, even though you could.

Similarly, if OSPF were already extended to the hybrid-bcast-p2mp
interface type, then you would not need to apply RFC 5820 to such
interfaces, even though you could, since a good solution would already
exist.

My point is that we only need one solution for the hybrid broadcast
interface type.  In fact, if we want to standardize OSPF extensions for
both the hybrid broadcast and MANET interface types, we should decide
on a SINGLE solution.  There is no reason not to have a single solution.

In fact, with the Router Priority heuristic described in draft-retana,
this method becomes closer (but not the same) as hybrid-bcast-p2mp.
And I already mentioned the similarity of hybrid-bcast-p2mp to OSPF-MDR
applied to a single-hop networks.  Therefore, the three approaches are
already somewhat similar, so we should be able to agree on one of
these.  In my opinion hybrid-bcast-p2mp is the simplest and involves
the fewest changes to OSPF, so I propose that we all adopt that method
for the hybrid broadcast interface type.

If you want to argue that it is not a new interface type, but is just a
special case of the MANET interface, then you should not need to
specify any changes to the MANET extension, and an Informational draft
should be sufficient.  But you are proposing changes based on
identifying the interface to be single-hop, so this can be considered a
new interface type.  We have three similar solutions for this interface
type, and we should be able to agree on one of these.

Richard

Retana, Alvaro wrote:

Richard:

You’re

IOW, in a

Thanks!

Alvaro.

From:

To: Retana, Alvaro

Cc: [email-masked]

Richard

Retana, Alvaro wrote:

Hi!

Thoughts/comments?

Thanks!

Alvaro.

OSPF mailing list

[email-masked]

---

From: Richard Ogier <[email-masked]>
Date: Tue, 10 May 2011 09:23:40 -0700

Alvaro,

I did some more thinking and can summarize our disagreement as
follows:  I think we should agree on a single method for single-hop
broadcast interfaces, and you think the method should depend on whether
or not the network also contains MANET interfaces.  Even if the network
contains MANET interfaces, I am not sure that treating a single-hop
broadcast interface as a modified/simplified MANET interface makes
things much easier, compared to using a somewhat similar solution
(hybrid-bcast-p2mp) that is a simple modification of OSPF.  I don't
think either of us is wrong.  Just different opinions.

Richard

Retana, Alvaro wrote:

Hi!

Thoughts/comments?

Thanks!

Alvaro.

---

From: Richard Ogier <[email-masked]>
Date: Wed, 11 May 2011 10:07:59 -0700

Note that I plan to submit an analogous draft that describes how 
OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks.  If 
draft-retana-ospf-manet-single-hop is accepted as a WG document, then it 
would also be fair to accept the analogous draft for OSPF-MDR as a WG 
document.

Regards,
Richard

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2011 13:22:56 -0700

Richard,

Don't you think you are being a bit presumptuous?  I think this decision is the prerogative of the working group and I don't necessarily think 'fairness' has anything to do with it.  Further, having multiple drafts in a given subject area is generally considered a bad idea.

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Ogier
> Sent: Wednesday, May 11, 2011 10:08 AM
> To: [email-masked]

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 11 May 2011 14:58:32 -0700

> John E Drake
> Sent: Wednesday, May 11, 2011 1:23 PM
> To: Richard Ogier; [email-masked]
> Don't you think you are being a bit presumptuous?  I think this
> decision is the prerogative of the working group and I don't
> necessarily think 'fairness' has anything to do with it.  Further,
> having multiple drafts in a given subject area is generally considered
> a bad idea.
> 
> Thanks,
> 
> John
> 

John, it has been on the OSPF WG charter to develop multiple OSPFv3 MANET Experimental RFCs.

- Tom

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2011 15:10:35 -0700

Tom,

The primary point of my email was Richard's presumptuousness.

The comment about having multiple protocols to do the same thing being a bad idea was simply a comment in passing.  And it is a bad idea - this was the rationale given by the IETF in taking a position against multiple OAM protocols for MPLS-TP.

Thanks,

John

Sent from my iPhone

> From: Henderson, Thomas R [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2011 2:59 PM
> To: John E Drake; Richard Ogier; [email-masked]
> Subject: RE: [OSPF] Adoption of "Single Hop MANET Interface" as WG
> Document
> 
> 
>

---

From: Richard Ogier <[email-masked]>
Date: Wed, 11 May 2011 15:17:14 -0700

John,

A few years ago, we had three drafts dealing with the same problem of
OSPF-MANET, and now we have three Experimental RFCs providing different
solutions to this problem.  All of these RFCs can be applied just as
easily to solve the special case of a single-hop broadcast network.  If
we want to choose one of these solutions over the other two, there
needs to be a reason and a formal decision, which I have not seen.  One
nice thing about having two drafts showing how both OSPF-OR and
OSPF-MDR can be applied to single-hop broadcast networks, is that it
will help people to understand and compare these different solutions.

Assuming OSPF-MDR is at least as good a solution as OSPF-OR in solving
this problem, which I believe, then I don't think it is presumptuous to
think it is fair to give both solutions an equal chance.  But it is
true that people will need to read both drafts before they can come to
that same conclusion.  Therefore, my point is to let people know there
will soon be another draft describing how another OSPF-MANET extension
can be applied to this case.

Thanks,

Richard

John E Drake wrote:

Richard,

Thanks,

John

Sent from my iPhone

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Ogier
Sent: Wednesday, May 11, 2011 10:08 AM
To: [email-masked]
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG
Document

Note that I plan to submit an analogous draft that describes how
OSPF-MDR (RFC 5614) can be applied to single-hop broadcast networks.
If
draft-retana-ospf-manet-single-hop is accepted as a WG document, then
it
would also be fair to accept the analogous draft for OSPF-MDR as a WG
document.

Regards,
Richard

---

From: John E Drake <[email-masked]>
Date: Wed, 11 May 2011 15:28:08 -0700

Comments inline

Sent from my iPhone

From: Richard Ogier [mailto:[email-masked]]
Sent: Wednesday, May 11, 2011 3:17 PM
To: John E Drake
Cc: [email-masked]
Subject: Re: [OSPF] Adoption of "Single Hop MANET Interface" as WG Document

John,

A few years ago, we had three drafts dealing with the same problem of OSPF-MANET, and now we have three Experimental RFCs providing different solutions to this problem.  All of these RFCs can be applied just as easily to solve the special case of a single-hop broadcast network.  If we want to choose one of these solutions over the other two, there needs to be a reason and a formal decision, which I have not seen.  One nice thing about having two drafts showing how both OSPF-OR and OSPF-MDR can be applied to single-hop broadcast networks, is that it will help people to understand and compare these different solutions.

JD:  That is not the statement you made in your email.  You said if one became a working group draft the other should also.  That is not your prerogative.

Assuming OSPF-MDR is at least as good a solution as OSPF-OR in solving this problem, which I believe, then I don't think it is presumptuous to think it is fair to give both solutions an equal chance

JD:  Why?  Years of this stuff has yet to show one protocol to have a demonstrable superiority over any other.

  But it is true that people will need to read both drafts before they can come to that same conclusion.  Therefore, my point is to let people know there will soon be another draft describing how another OSPF-MANET extension can be applied to this case.

JD:   Again, that is not what you said.  And it isn't clear to me that the world needs yet another protocol choice.

Thanks,
Richard

John E Drake wrote:

Richard,

Thanks,

John

Sent from my iPhone

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

Richard Ogier

To: [email-masked]<mailto:[email-masked]>

Document

If

it

document.

Regards,

Richard

OSPF mailing list

---

From: Richard Ogier <[email-masked]>
Date: Wed, 11 May 2011 15:40:31 -0700

But it is true that people will need to read
both drafts before they can come to that same conclusion.  Therefore,
my point is to let people know there will soon be another draft
describing how another OSPF-MANET extension can be applied to this case.

JD:
Again, that is not what you said.  And it isn’t clear to me that the
world needs yet another protocol choice.

The fact is that both RFCs already solve the problem.  Therefore, we
are not talking about another protocol choice.

Anyway, Acee's recent post shows that he is being fair.

Richard

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 11 May 2011 15:59:13 -0700

John, some replies are inline below.

> From: John E Drake [mailto:[email-masked]]
> Sent: Wednesday, May 11, 2011 3:11 PM
> To: Henderson, Thomas R; Richard Ogier; [email-masked]

I agree that it may be presumptuous to ask a WG to adopt an as-yet-unpublished draft.  However, I for one would like to understand better the decision that is being taken in adopting an update of RFC 5820 to solve the use case of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.  Would similar future updates of the other MANET RFCs be precluded by such a decision?  Does this mean that ospf-hybrid-bcast-and-p2mp-01 will not be considered further as a WG document?

Perhaps we could try to clarify whether the WG intention is to update the Experimental RFCs along these lines or rather to work on a single specification for the use case introduced by draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.

> The comment about having multiple protocols to do the same thing being
> a bad idea was simply a comment in passing.  And it is a bad idea -
> this was the rationale given by the IETF in taking a position against
> multiple OAM protocols for MPLS-TP.
> 

I understand, but this is one rationale for the experimental track; see for example 
http://www.ietf.org/iesg/informational-vs-experimental.html (Section 3 item 4)

- Tom

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 12 May 2011 10:53:45 +0200

John,
I agree with Tom. It's not totally obvious which way to choose to go forward
with this.
I think a discussion needs to take place before deciding anything.
This thread may be the start of such a discussion?
Regards,
Emmanuel

On Thu, May 12, 2011 at 12:59 AM, Henderson, Thomas R <
[email-masked]> wrote:

> I agree that it may be presumptuous to ask a WG to adopt an
> as-yet-unpublished draft.  However, I for one would like to understand
> better the decision that is being taken in adopting an update of RFC 5820 to
> solve the use case of draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.  Would
> similar future updates of the other MANET RFCs be precluded by such a
> decision?  Does this mean that ospf-hybrid-bcast-and-p2mp-01 will not be
> considered further as a WG document?
>
> Perhaps we could try to clarify whether the WG intention is to update the
> Experimental RFCs along these lines or rather to work on a single
> specification for the use case introduced by
> draft-nsheth-ospf-hybrid-bcast-and-p2mp-01.
>