Subject: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

From: Jiazi Yi <[email-masked]>
Date: Mon, 17 Feb 2014 17:50:13 +0100

Dear all, 

I had a review of draft-dearlove-manet-olsrv2-multitopology-02. 

Without going into details for the moment, my main concern is its interoperability between OLSRv2 (without MT), and routers using different set of metrics. 

Although it is mentioned that 

" a bad
   collective choice (of metric types) will make the MANET anywhere from inefficient to
   non-functional, so care will be needed in selecting supported link
   metric types across the MANET."

and there some discussions in the Management Considerations section, I still feel this issues should be more elaborated. 
What I understood is that:

	o If an OLSR router uses a metric type not supported by other MT-OLSR routers, then it's unlikely that it can participate in the network. 

	o If MT-OLSR routers uses metric types without intersection (for example, Router 1 uses metric types A,B, and Router 2 uses C, D), then they can't be interconnected either. 

I think the compatibility issues should be raised in the applicability statement. 

It would be even better if it can be addressed in certain ways. I'm thinking about some possibilities like:

	o A metric is set to MAX value, if a metric type is unknown, or
	
	o Define a "default" metric such as hop-count, which should be supported by all routers. 

best

Jiazi

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 18:03:13 +0100

How is that problem any different than, say, a network running OLSRv2 (not -MT), but wherein half the routers use metric type FOO and the other half the routers use metric type BAR?

Thomas

On 17 Feb 2014, at 17:50, Jiazi Yi <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Jiazi YI <[email-masked]>
Date: Mon, 17 Feb 2014 18:44:32 +0100

I won't say that they are different.
However, in OLSRv2, only a single metric is used. But as long as multiple
metrics are discussed in this context, I think it worth to paying more
attention (maybe I missed some previous discussions on this issue)?

Jiazi

On Mon, Feb 17, 2014 at 6:03 PM, Thomas Clausen <[email-masked]>wrote:

> How is that problem any different than, say, a network running OLSRv2 (not
> -MT), but wherein half the routers use metric type FOO and the other half
> the routers use metric type BAR?
>
> Thomas
>
> > Without going into details for the moment, my main concern is its
> interoperability between OLSRv2 (without MT), and routers using different
> set of metrics.
> >
> > and there some discussions in the Management Considerations section, I
> still feel this issues should be more elaborated.
> >       o If an OLSR router uses a metric type not supported by other
> MT-OLSR routers, then it's unlikely that it can participate in the network.
> >
> >       o If MT-OLSR routers uses metric types without intersection (for
> example, Router 1 uses metric types A,B, and Router 2 uses C, D), then they
> can't be interconnected either.
> >

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 18:52:20 +0100

On 17 Feb 2014, at 18:44, Jiazi YI <[email-masked]> wrote:

> However, in OLSRv2, only a single metric is used. But as long as multiple metrics are discussed in this context, I think it worth to paying more attention (maybe I missed some previous discussions on this issue)? 
> 

Fair enough, we can discuss this. I just wanted to make very sure that you didn't think that they were different problems.

In the general sense, I think that there's nothing much (short of mandating "thou shall always support metric XXX" - which, alas, has its own set of problems) that a protocol can do to guard against a deployment where the network operators are going through extraordinary lengths to shoot themselves in the foot (an example: define "C" differently in OLSRv2 routers).

I'd not object personally to a clearer caveat, but going back to the text that you quote, I think that it's pretty clear already.

Thomas

> Jiazi
> 
> 
> On Mon, Feb 17, 2014 at 6:03 PM, Thomas Clausen <[email-masked]> wrote:

---

From: Jiazi YI <[email-masked]>
Date: Mon, 17 Feb 2014 22:04:13 +0100

Hi,

On Mon, Feb 17, 2014 at 6:52 PM, Thomas Clausen <[email-masked]>wrote:

> Fair enough, we can discuss this. I just wanted to make very sure that you
> didn't think that they were different problems.
>
> In the general sense, I think that there's nothing much (short of
> mandating "thou shall always support metric XXX" - which, alas, has its own
> set of problems) that a protocol can do to guard against a deployment where
> the network operators are going through extraordinary lengths to shoot
> themselves in the foot (an example: define "C" differently in OLSRv2
> routers).
>

I think for MANET, as we might face different kind of interfaces/mediums,
it's reasonable to consider that different metrics are used.
Given such heterogeneous environment, it's expected that the protocol is as
robust as possible.

For example,

 If such a router (OLSR without MT) is the destination, then the
packet will never reach its destination, as the source will not have a
suitable
      routing table entry for the destination.

In such case, we would expect the packet can reach the destination, even it
doesn't use the same metric as others.

best

Jiazi

>
> I'd not object personally to a clearer caveat, but going back to the text
> that you quote, I think that it's pretty clear already.
>
> Thomas
>
> Jiazi
>
>
>> How is that problem any different than, say, a network running OLSRv2
>> (not -MT), but wherein half the routers use metric type FOO and the other
>> half the routers use metric type BAR?
>>
>> Thomas
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 17 Feb 2014 21:48:05 +0000

The issues about what is and is not acceptable (or inevitable) are among the things to be discussed. I'll just make two points:
- First, that (for example) routing using more than one metric to deliver a packet is a bad idea, it can loop. Better to fail to deliver. Failure to deliver is not something to try to prevent at all costs.
- Second, there is no reason why all topologies should be complete (include all routers). in fact it's not hard to think of examples why not.

On 17 Feb 2014, at 21:04, Jiazi YI wrote:

> Hi, 
> 
> 
> On Mon, Feb 17, 2014 at 6:52 PM, Thomas Clausen <[email-masked]> wrote:
> 
> I think for MANET, as we might face different kind of interfaces/mediums, it's reasonable to consider that different metrics are used. 
> Given such heterogeneous environment, it's expected that the protocol is as robust as possible. 
> 
> For example, 
> 
>  If such a router (OLSR without MT) is the destination, then the packet will never reach its destination, as the source will not have a suitable
> In such case, we would expect the packet can reach the destination, even it doesn't use the same metric as others. 
> 
> best
> 
> Jiazi
>  
>

---

From: Jiazi YI <[email-masked]>
Date: Mon, 17 Feb 2014 23:56:53 +0100

Hi,

On Mon, Feb 17, 2014 at 10:48 PM, Christopher Dearlove <
[email-masked]> wrote:

> The issues about what is and is not acceptable (or inevitable) are among
> the things to be discussed. I'll just make two points:
> - First, that (for example) routing using more than one metric to deliver
> a packet is a bad idea, it can loop. Better to fail to deliver. Failure to
> deliver is not something to try to prevent at all costs.
>

I agree that we shouldn't use more than one metric for a packet. I believe
that I didn't mention it in my previous posts.

>  - Second, there is no reason why all topologies should be complete
> (include all routers). in fact it's not hard to think of examples why not.
>

It's true that not all topologies should be complete. However, sometimes we
probably want "best effort" services.

best

Jiazi

>> Fair enough, we can discuss this. I just wanted to make very sure that
>> you didn't think that they were different problems.
>>
> In such case, we would expect the packet can reach the destination, even
> it doesn't use the same metric as others.
>
> best
>
> Jiazi
>
>
>>
>> On Mon, Feb 17, 2014 at 6:03 PM, Thomas Clausen <[email-masked]
>> > wrote:
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 17 Feb 2014 23:27:25 +0000

No, you didn't mention it. However it's important to establish. (And it provides, as I indicated by the words for example, an instance of where the best thing to do is to drop a packet.)

The question then is what do you mean by "best effort"? If you require single metric routes, and you don't have all the metrics (and it's undesirable to require that you do, my second point) then there is no best effort that will get you there.

You can't decide at the origin to use a metric that gets you to the destination, based on what routing information for different metrics you have, because unless you do something like modify the packet DSCP - if that's your usual way to choose metric, if not similar comments would apply to an alternative - you can't let other routers know which metric you are using. And that may mean you end up using more than one metric, which we've agreed is unacceptable. And modifying packets in transit - even just to change a DSCP - may also be unacceptable.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 17 Feb 2014, at 22:56, Jiazi YI <[email-masked]> wrote:
> 
> Hi, 
> 
> 
>> On Mon, Feb 17, 2014 at 10:48 PM, Christopher Dearlove <[email-masked]> wrote:
> I agree that we shouldn't use more than one metric for a packet. I believe that I didn't mention it in my previous posts. 
>  
> It's true that not all topologies should be complete. However, sometimes we probably want "best effort" services. 
> 
> best
> 
> Jiazi
>  
>> 
>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Feb 2014 00:40:24 +0100

Please note that the subject draft has been adopted and it is WG draft.
Comments below,

> deliver is not something to try to prevent at all costs.

Do you mean the draft is not doing multi metric (as OLSRv2 without MT)? I
was answered that the protocol will consider it as said in (1) and (2)
below. I reviewed the draft with comments before adoption (3).

 I still think my comments (3) and Jiazi's comments are to be taken in
discussion. Please see (1) and (2) as reasons to adopt the document.

> (include all routers). in fact it's not hard to think of examples why not.

Yes. That is ok.

AB

(1) http://www.ietf.org/mail-archive/web/manet/current/msg15837.html

(2) http://www.ietf.org/mail-archive/web/manet/current/msg15839.html

(3) http://www.ietf.org/mail-archive/web/manet/current/msg15850.html

(4) http://www.ietf.org/mail-archive/web/manet/current/msg15853.html

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 17 Feb 2014 23:59:37 +0000

As the author of quite a few WG drafts, I really have no need for your "Please note" comment.

As for your next point, well, you could read the draft. But it routes different packets by different metrics, but each packet by a single metric.

On 17 Feb 2014, at 23:40, Abdussalam Baryun wrote:

> Please note that the subject draft has been adopted and it is WG draft. Comments below, 
> 
> Do you mean the draft is not doing multi metric (as OLSRv2 without MT)? I was answered that the protocol will consider it as said in (1) and (2) below. I reviewed the draft with comments before adoption (3). 
> 
>  I still think my comments (3) and Jiazi's comments are to be taken in discussion. Please see (1) and (2) as reasons to adopt the document. 
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Feb 2014 01:20:12 +0100

>> deliver is not something to try to prevent at all costs.
So you mean, more than one metric to route a packet is bad idea.

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 18 Feb 2014 01:40:20 +0100

Yes. 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

> On 18 févr. 2014, at 01:20, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
>>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 18 Feb 2014 07:55:54 +0100

On 02/17/2014 10:48 PM, Christopher Dearlove wrote:
> - First, that (for example) routing using more than one metric to
> deliver a packet is a bad idea, it can loop. Better to fail to deliver.
> Failure to deliver is not something to try to prevent at all costs.

I don't think the packet would ever loop, even if every router choose a
metric of its own to route the packet. Loops only happen if the change
rate of the metric exceeds the rate of TC distribution.

The Dijkstra Algorithm does not care what kind of costs you attach to
the links, it will always give you a consistent path towards the
destination.

> (include all routers). in fact it's not hard to think of examples why not.

I completely agree with this, incomplete topologies are very important
for QoS aware routing.

If I have a "low delay" topology, I do not want my real time control
traffic go over a geostationary satellite link. Better the application
tells me "sorry, no connectivity" than to pretend everything is fine.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Henning Rogge <[email-masked]>
Date: Tue, 18 Feb 2014 07:58:04 +0100

On 02/18/2014 01:20 AM, Abdussalam Baryun wrote:
>         The issues about what is and is not acceptable (or inevitable)
>         are among the things to be discussed. I'll just make two points:
>         - First, that (for example) routing using more than one metric
>         to deliver a packet is a bad idea, it can loop. Better to fail
>         to deliver. Failure to deliver is not something to try to
>         prevent at all costs.
> 
> 

Normally you don't use MT routing just for fun, you use it to achieve a
goal. I would guess that the routes you get with using different metrics
for the same packet on each hop will not be what you had in mind when
setting up the MT routing.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 18 Feb 2014 07:56:32 +0000

That's easily seen not to be so, looping is quite possible when different routers are allowed to use different metrics to route the same packet. (Which of course we don't permit, this is one reason why.) Here's an example.

Put A, B, C in a triangle. Metric type 1 has values AB = 1, BC = 1, AC = 3. Metric type 2 has values BA = 1, BC = 3, AC = 1. There's a packet at A intended for C. A routes by metric 1 and sends to B. B routes by metric 2 and sends back to A.

> On 18 Feb 2014, at 06:55, Henning Rogge <[email-masked]> wrote:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 18 Feb 2014 07:58:10 +0000

No, this is just plain prohibited. It doesn't work. See example in other posting.

> On 18 Feb 2014, at 06:58, Henning Rogge <[email-masked]> wrote:
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Feb 2014 09:25:43 +0100

On Tuesday, February 18, 2014, Christopher Dearlove wrote:

> That's easily seen not to be so, looping is quite possible when different
> routers are allowed to use different metrics to route the same packet.
> (Which of course we don't permit, this is one reason why.) Here's an
> example.

May be Henning is thinking of new method of routing feature that can be
added to the new protocol, as why you have packets sent without containing
information of possible metrics (and other needed info) used for router
awareness.

>
> Put A, B, C in a triangle. Metric type 1 has values AB = 1, BC = 1, AC =
> 3. Metric type 2 has values BA = 1, BC = 3, AC = 1. There's a packet at A
> intended for C. A routes by metric 1 and sends to B. B routes by metric 2
> and sends back to A.

If B knows that A forwarded the packet by metric 1 it will not send to any
with metric 2 only if it has both metric topologies complete. Could that be
a condition that prevents loops?

AB

>
> --
> Christopher Dearlove
> [email-masked] <javascript:;> (iPhone)
> [email-masked] <javascript:;> (home)
>
> > On 18 Feb 2014, at 06:55, Henning Rogge <
> [email-masked] <javascript:;>> wrote:
> >
> > mailto:[email-masked] <javascript:;>
> http://www.fkie.fraunhofer.de
> >
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Feb 2014 09:21:09 +0000

The intent, as usual (we're not discussing source routing) is to route packets unchanged.

Preventing an immediate reversal would stop this simple 3 node loop (though it might not be trivial). But I could construct a bigger example that had the same problem where there is no direct reversal. (In fact I can do it with 4 nodes.)

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 18 February 2014 08:26
To: Christopher Dearlove
Cc: <[email-masked]>
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

May be Henning is thinking of new method of routing feature that can be added to the new protocol, as why you have packets sent without containing information of possible metrics (and other needed info) used for router awareness.

If B knows that A forwarded the packet by metric 1 it will not send to any with metric 2 only if it has both metric topologies complete. Could that be a condition that prevents loops?

AB

--
Christopher Dearlove
[email-masked]<javascript:;> (iPhone)
[email-masked]<javascript:;> (home)

> On 18 Feb 2014, at 06:55, Henning Rogge <[email-masked]<javascript:;>> wrote:
>
> mailto:[email-masked]<javascript:;> http://www.fkie.fraunhofer.de
>
> [email-masked]<javascript:;>

_______________________________________________
manet mailing list
[email-masked]<javascript:;>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Tue, 18 Feb 2014 10:38:56 +0100

Maybe we talk about different things but I disagree...

each nodes applies costs to the incoming links with a metric (whatever
it is) and publishes this in Hellos and TCs. It doesn't matter if node
A use a different metric for its incoming links than node B, because
each directional link is only measured by a single node.

In your example A cannot have a different value for the cost "B to C"
than B, because these values are decided by node C, not node A and B.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Feb 2014 09:54:41 +0000

These are different metric _types_. With different type extensions. Both nodes have both of them, just in this (disallowed, this is pointing out why) scenario each node is just using one type, just different ones. So the scenario (in terms of what the metrics are) is quite possible.

I think you are failing to see what's being discussed, possibly because you are discounting something stupid. The point here is to make that this is stupid clear.

[email-masked] | http://www.baesystems.com

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 18 February 2014 09:39
To: Christopher Dearlove
Cc: <[email-masked]>
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

each nodes applies costs to the incoming links with a metric (whatever it is) and publishes this in Hellos and TCs. It doesn't matter if node A use a different metric for its incoming links than node B, because each directional link is only measured by a single node.

Henning Rogge

On Tue, Feb 18, 2014 at 8:56 AM, Christopher Dearlove <[email-masked]> wrote:
> [email-masked] (iPhone) [email-masked] 
> (home)
>
>>> The issues about what is and is not acceptable (or inevitable) are 
>>> among the things to be discussed. I'll just make two points:
>> I don't think the packet would ever loop, even if every router choose 
>> a metric of its own to route the packet. Loops only happen if the 
>> change rate of the metric exceeds the rate of TC distribution.
>>
>> I completely agree with this, incomplete topologies are very 
>> important for QoS aware routing.
>>
>> traffic go over a geostationary satellite link. Better the 
>> application tells me "sorry, no connectivity" than to pretend everything is fine.
>>
>> Henning Rogge
>>
>> --
>> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
>> Germany

---

From: Henning Rogge <[email-masked]>
Date: Tue, 18 Feb 2014 10:57:24 +0100

Ahh,

that explains my trouble...

Yes, routing the same packet once with metric extension A and on the
next with metric extension B is stupid.

packets jumping between different dijkstra topologies is definitely a
source of routing loops.

Sorry for the noise.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Feb 2014 10:24:41 +0000

OK, so we're clear on that.

Just to recap, the points I wanted to make are
- Any one packet is only routed by one metric/topology. (That's just to establish an underlying point.)
- Topologies may not be complete. This could happen due to circumstances, but it can also happen by design.
- Some packets may not be deliverable, the best thing you can do is throw them away.

Not the end of the story of course. Some networks may be managed to make the throwing away very uncommon. In others it may be routine.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 18 February 2014 09:57
To: Dearlove, Christopher (UK)
Cc: Christopher Dearlove; <[email-masked]>
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

Ahh,

Yes, routing the same packet once with metric extension A and on the next with metric extension B is stupid.

packets jumping between different dijkstra topologies is definitely a source of routing loops.

Sorry for the noise.

Henning Rogge

On Tue, Feb 18, 2014 at 10:54 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
> Senior Principal Engineer, Communications Group Communications, 
> Networks and Image Analysis Capability BAE Systems Advanced Technology 
> Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> No: 1996687
>
>
> Subject: Re: [manet] comments on 
> draft-dearlove-manet-olsrv2-multitopology-02
>
>>> I don't think the packet would ever loop, even if every router 
>>> choose a metric of its own to route the packet. Loops only happen if 
>>> the change rate of the metric exceeds the rate of TC distribution.
>>>
>>> The Dijkstra Algorithm does not care what kind of costs you attach 
>>> to the links, it will always give you a consistent path towards the 
>>> destination.
>>>

---

From: Jiazi YI <[email-masked]>
Date: Tue, 18 Feb 2014 16:37:02 +0100

Hi,

On Tue, Feb 18, 2014 at 12:27 AM, Christopher Dearlove <
[email-masked]> wrote:

> No, you didn't mention it. However it's important to establish. (And it
> provides, as I indicated by the words for example, an instance of where the
> best thing to do is to drop a packet.)
>

agree.

>
> The question then is what do you mean by "best effort"? If you require
> single metric routes, and you don't have all the metrics (and it's
> undesirable to require that you do, my second point) then there is no best
> effort that will get you there.
>

I think depending on the applications, there are two possibilities:

  -   If the routers couldn't support the designated metric, then it's not
considered - because it probably won't be able to provide desired QoS.

  -   It's preferred to build routes using the metric required - but if
not, we still want to have the packet delivered in certain other way (best
effort).

Personally, I think we should provide the second possibility.
But if the WG believes that the second is not desired, I'll respect the
decision of the WG.

best

Jiazi

>
> You can't decide at the origin to use a metric that gets you to the
> destination, based on what routing information for different metrics you
> have, because unless you do something like modify the packet DSCP - if
> that's your usual way to choose metric, if not similar comments would apply
> to an alternative - you can't let other routers know which metric you are
> using. And that may mean you end up using more than one metric, which we've
> agreed is unacceptable. And modifying packets in transit - even just to
> change a DSCP - may also be unacceptable.
>
> --
> Christopher Dearlove
>> On Mon, Feb 17, 2014 at 6:52 PM, Thomas Clausen <[email-masked]
>> > wrote:
>>
>>>
>>> However, in OLSRv2, only a single metric is used. But as long as
>>> multiple metrics are discussed in this context, I think it worth to paying
>>> more attention (maybe I missed some previous discussions on this issue)?
>>>
>>>
>>> I'd not object personally to a clearer caveat, but going back to the
>>> text that you quote, I think that it's pretty clear already.
>>>
>>> Thomas
>>>
>>> Jiazi
>>>
>>>
>>>> > and there some discussions in the Management Considerations section,
>>>> I still feel this issues should be more elaborated.
>>>> >       o If MT-OLSR routers uses metric types without intersection
>>>> (for example, Router 1 uses metric types A,B, and Router 2 uses C, D), then
>>>> they can't be interconnected either.
>>>> >

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 18 Feb 2014 16:57:52 +0100

On 18 Feb 2014, at 16:37, Jiazi YI <[email-masked]> wrote:

> Hi, 
> 
> 
> On Tue, Feb 18, 2014 at 12:27 AM, Christopher Dearlove <[email-masked]> wrote:
>   -   If the routers couldn't support the designated metric, then it's not considered - because it probably won't be able to provide desired QoS. 
> 
>   -   It's preferred to build routes using the metric required - but if not, we still want to have the packet delivered in certain other way (best effort). 
> 
> But if the WG believes that the second is not desired, I'll respect the decision of the WG. 
> 

I think that we should be careful not to restrict unnecessarily.

If we do *not* stipulate in the spec "you MUST support metric X always" (where "X" may be "hop count"), that doesn't preclude that you deploy a network, wherein the requirement for participation is for all devices to be "provisioned with hop-count metrics", but it is also encouraged - and even expected - for a router to support some better metrics also. Ensuring that such a requirement is met would be part of the same provisioning process that you go through to get cryptographic material to the routers for message authentication, for example, and could even be made a prerequisite for a router to get such material ;)

If we *do* stipulate in the spec "you MUST support metric X always" (where "X" may be "hop count"), then it'd technically be non-conformant to build a network which doesn't -- and I want to be able to build such a network, since (in some cases) a hop-count-path will be worse than no path. 

For example: it'll be a futile waste of battery to try to send data through the path discovered using the X-metric -- and, the pathological example here will be the well-known situation wherein broadcast is sent at a lower datarate than unicast -- and I'd much rather get a "No Route to Host" immediately, than wait for the inevitable timeout..

Now, some might say "then make default metric X to be something different from hop-count". There's a veritable smørrebrødsbord ("smorgadsbord" for those into deforming good Danish words ;) ) of metrics to choose from "out there", and choosing one would be a rathole worth (at least) a decade of discussions...discussions, that won't bring us any closer to reaching any agreement: different deployments have different requirements, and different media exhibit different characteristics.

So, in summary 

	o	Specifying a mandatory-to-implement/mandatory-to-use metric will actually restrict some scenarios that I consider to be important. 

	o	Not specifying a mandatory-to-implement/mandatory-to-use metric (the current approach) does not prevent anyone from making 
		that an additional requirement in a deployment.

	o	Agreeing on a "good default metric" is a rat-hole I don't think we should drag ourselves into - it's deployment specific.

Bottom line:

	o	Restrictions of that sort should not be imposed: they will hurt, but they won't help.

Cheerios,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 18 Feb 2014 17:06:41 +0100

I should add two things here....

> 	o	Restrictions of that sort should not be imposed: they will hurt, but they won't help.

As it turns out that specific metrics is found to be particularly beneficial, in practice, then the right approach is to:

	o	Write up a specification, documenting that metric, making the necessary IANA reservations, 
		stipulating how it is calculated, etc. - like Henning is doing with the ETT-metric - for publication
		as an RFC

If it turns out that for a specific class of deployments, a specific set of metrics are preferred/recommended/found to be perfect, then the right approach is to:

	o	Write up a specification documenting exactly that - a sort of "profile" - which can (IIRC) attain even
		std. track and therefore be normative in the "if you deploy a network of this class, then you MUST 
		use these metrics (and, presumably, other things). Of course, caveating that by a sufficiently precise
		description of the class of deployments where it applies.

Best,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Feb 2014 17:38:14 +0000

If you have a packet due to be delivered by topology X, and you don't have a route by Topology X, there is no best effort. Any attempt to use another route, which means another metric, can loop. (Not its only problem, but a bad one.)

So there is no "best effort". Best is to drop the packet.

There is a possible exception, you are the packet source. But the packet source may be outside the MANET. OK, add or the ingress gateway.

But now, what are you going to substitute for topology X. Topology Y? How can you have any idea that topology Y is acceptable? Throwing it away may be better than trying topology Y. As a mere router, and just seeing a packet, you don't know. (Was the topology bandwidth dependent? I'd rather not clog topology Y. Was it security related?)

And how do you make it clear to intermediate router that this packet, that looks like a topology X packet, is being routed by topology Y? Depends how topologies are indicated. But to take a typical means, DSCP, that means changing the DSCP. Sorry, there are networks that's not allowed in.

So I don't believe in best effort. It's often worse than discarding a packet. If topology X isn't supported by a router, it will have had a good reason for that. (Or is legacy OLSRv2.) Discarding a packet may also leave the endpoint application to try something else.

From: manet [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 18 February 2014 15:37
To: Christopher Dearlove
Cc: [email-masked] List; Thomas Clausen
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

*** WARNING ***

On Tue, Feb 18, 2014 at 12:27 AM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
No, you didn't mention it. However it's important to establish. (And it provides, as I indicated by the words for example, an instance of where the best thing to do is to drop a packet.)

agree.

best

Jiazi

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)

On 17 Feb 2014, at 22:56, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On Mon, Feb 17, 2014 at 10:48 PM, Christopher Dearlove <[email-masked]<mailto:[email-masked]>> wrote:
The issues about what is and is not acceptable (or inevitable) are among the things to be discussed. I'll just make two points:
- First, that (for example) routing using more than one metric to deliver a packet is a bad idea, it can loop. Better to fail to deliver. Failure to deliver is not something to try to prevent at all costs.

best

Jiazi

Hi,

On Mon, Feb 17, 2014 at 6:52 PM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

On 17 Feb 2014, at 18:44, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:

For example,

best

Jiazi

Thomas

Jiazi

On Mon, Feb 17, 2014 at 6:03 PM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:
How is that problem any different than, say, a network running OLSRv2 (not -MT), but wherein half the routers use metric type FOO and the other half the routers use metric type BAR?

Thomas

On 17 Feb 2014, at 17:50, Jiazi Yi <[email-masked]<mailto:[email-masked]>> wrote:

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

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 18 Feb 2014 17:40:31 +0000

Agree with those points, which overlap with mine, but aren't identical. (I agree with Thomas's non-overlapping details too).

From: manet [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: 18 February 2014 15:58
To: Jiazi YI
Cc: Christopher Dearlove; [email-masked] List
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

*** WARNING ***

On 18 Feb 2014, at 16:37, Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

agree.

So, in summary

Bottom line:

Cheerios,

Thomas

best

Jiazi

best

Jiazi

Hi,

For example,

best

Jiazi

Thomas

Jiazi

Thomas

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 18 Feb 2014 17:48:17 +0000

On Feb 18, 2014, at 11:06 AM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

On 18 Feb 2014, at 16:57, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

agree.

So, in summary

Bottom line:

The only quibble I would have about the specification is that I think it should probably be aimed at Informational, as a type of "best practices" kind of doc.

Regards,
Stan

Best,

Thomas

Cheerios,

Thomas

best

Jiazi

Hi,

best

Jiazi

Hi,

For example,

best

Jiazi

Thomas

Jiazi

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 18 Feb 2014 18:52:44 +0100

On 18 Feb 2014, at 18:48, Stan Ratliff (sratliff) <[email-masked]> wrote:

<SNIP>

>> o
>> Write up a specification, documenting that metric, making the necessary IANA reservations, 
>> o
>> Write up a specification documenting exactly that - a sort of "profile" - which can (IIRC) attain even

Let's cross that bridge when we get to it - that's not something it's worth quibbling over until there's text....

At this juncture I am not sure that we have identified sufficiently large classes of sufficiently large deployments to start writing (although others may disagree).

I'll say this, though, I've seen such documents as both BCPs and PS from other WGs  - and IETF process has had a tendency to evolve even faster than the Internet itself, these past years, so who knows what's in fashion tomorrow.....

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 18 Feb 2014 10:08:20 -0800

I agree with Chris and Thomas. I wonder if these explanations (translated
into a formal text) are useful to be added to the draft in the introduction?

Regards
Ulrich

On Tue, Feb 18, 2014 at 9:38 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  If you have a packet due to be delivered by topology X, and you don't
> have a route by Topology X, there is no best effort. Any attempt to use
> another route, which means another metric, can loop. (Not its only problem,
> but a bad one.)
>
>
>
> There is a possible exception, you are the packet source. But the packet
> source may be outside the MANET. OK, add or the ingress gateway.
>
>
>
> But now, what are you going to substitute for topology X. Topology Y? How
> can you have any idea that topology Y is acceptable? Throwing it away may
> be better than trying topology Y. As a mere router, and just seeing a
> packet, you don't know. (Was the topology bandwidth dependent? I'd rather
> not clog topology Y. Was it security related?)
>
>
>
> And how do you make it clear to intermediate router that this packet, that
> looks like a topology X packet, is being routed by topology Y? Depends how
> topologies are indicated. But to take a typical means, DSCP, that means
> changing the DSCP. Sorry, there are networks that's not allowed in.
>
>
>
> So I don't believe in best effort. It's often worse than discarding a
> packet. If topology X isn't supported by a router, it will have had a good
> reason for that. (Or is legacy OLSRv2.) Discarding a packet may also leave
> the endpoint application to try something else.
>
>
>
> --
>
> Christopher Dearlove
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Jiazi YI
> *Sent:* 18 February 2014 15:37
> *To:* Christopher Dearlove
> *Cc:* [email-masked] List; Thomas Clausen
>
> *Subject:* Re: [manet] comments on
> **** WARNING ****
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. *
> *For information regarding **Red Flags** that you can look out for in
> emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
>
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
>   Hi,
>
>
>

---

From: Jiazi YI <[email-masked]>
Date: Tue, 18 Feb 2014 22:41:53 +0100

Thank you all for your detailed explanation.

It's clear to me what's the preference of most WG participants.

I think it would be helpful to include some of the points in the draft, to
clarify the issue.

cheers

Jiazi

On Tue, Feb 18, 2014 at 6:40 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  Agree with those points, which overlap with mine, but aren't identical.
> (I agree with Thomas's non-overlapping details too).
>
>
>
> --
>
> Christopher Dearlove
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Thomas
> Clausen
> *Sent:* 18 February 2014 15:58
> *To:* Jiazi YI
> *Cc:* Christopher Dearlove; [email-masked] List
>
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> If we do *not* stipulate in the spec "you MUST support metric X always"
> (where "X" may be "hop count"), that doesn't preclude that you deploy a
> network, wherein the requirement for participation is for all devices to be
> "provisioned with hop-count metrics", but it is also encouraged - and even
> expected - for a router to support some better metrics also. Ensuring that
> such a requirement is met would be part of the same provisioning process
> that you go through to get cryptographic material to the routers for
> message authentication, for example, and could even be made a prerequisite
> for a router to get such material ;)
>
>
>
> If we *do* stipulate in the spec "you MUST support metric X always" (where
> "X" may be "hop count"), then it'd technically be non-conformant to build a
> network which doesn't -- and I want to be able to build such a network,
> since (in some cases) a hop-count-path will be worse than no path.
>
>
>
> For example: it'll be a futile waste of battery to try to send data
> through the path discovered using the X-metric -- and, the pathological
> example here will be the well-known situation wherein broadcast is sent at
> a lower datarate than unicast -- and I'd much rather get a "No Route to
> Host" immediately, than wait for the inevitable timeout..
>
>
>
> Now, some might say "then make default metric X to be something different
> from hop-count". There's a veritable smørrebrødsbord ("smorgadsbord" for
> those into deforming good Danish words ;) ) of metrics to choose from "out
> there", and choosing one would be a rathole worth (at least) a decade of
> discussions...discussions, that won't bring us any closer to reaching any
> agreement: different deployments have different requirements, and different
> media exhibit different characteristics.
>
>
>
> So, in summary
>
>
>
>             o          Specifying a
> mandatory-to-implement/mandatory-to-use metric will actually restrict some
> scenarios that I consider to be important.
>
>
>
>             o          Not specifying a
> mandatory-to-implement/mandatory-to-use metric (the current approach) does
> not prevent anyone from making
>
>             o          Agreeing on a "good default metric" is a rat-hole
> I don't think we should drag ourselves into - it's deployment specific.
>
>
>
> Bottom line:
>
>
>