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

From: Christoph Barz <[email-masked]>
Date: Wed, 2 Apr 2014 13:00:39 +0200

Hello Christoper,
hello Thomas,

While taking a first look at the current
draft-ietf-manet-olsrv2-multitopology-00 I noticed the following:

1) The introduction and applicability statement identify the requirement to
use different routing metrics as the reason for Multi-Topology OLSRv2. I
would suggest extending this with a second motivation for MTR, the ability
to define sub-topologies as an administrative means. Motivations for doing
this include technology heterogeneity (excluding certain types of traffic
from unsuitable links) or policy based routing (not wanting certain traffic
to be routed via a special subset of nodes or links).

2) If we accept the second motivation for MTR, we should really drop the
limitation in the applicability statement that each topology is
characterized by a different choice of link metric type. Thus, we would
have the many to relationship between topologies and metrics you mentioned
in one of your previous mails:

          N       1
 Topology ---------> Metric

You also mentioned, that this would be more complicated and probably break
the compatibility with non-MT OLSRv2. However, regarding the draft, it will
probably be sufficient to substitute the term "metric type" with "topology"
as a first step. It comes with the cost of potentially having transmit the
same metric values several times. In fact this will be kind of a 1:1
relationship while dropping the requirement for the metrics to be different.
To be more efficient, we could also work on additional ways to transmit a
single metric value for multiple topologies (if possible without breaking
compliance with the basic draft).

3) Should we have a special topology 0 as default topology? This aspect was
already mentioned by Jiazi. OSPF-MT uses the notion of default topology to
be compliant with non-MT capable routers.  Non-MT capable routers will be
limited to topology 0.

4) Is there a way to go beyond 16 possible topologies at the cost of
efficiency at least as an optional feature?

Best regards
Christoph

2014-03-31 19:48 GMT+02:00 Christopher Dearlove <
[email-masked]>:

>
> On 31 Mar 2014, at 18:02, Charles E. Perkins wrote:
>
> > Hello Chris,
> >
> > On 3/31/2014 2:07 AM, Dearlove, Christopher (UK) wrote:
> >> - I understand the point to be that connectivity and thus
> >>    topology is determined by existence of a link where the
> >>    routers are "willing" and can satisfy the desired metric (say,
> >>    to have sufficient bandwidth).  One could imagine a topology
> >>    where only links of > 10kb/sec were allowed, and another
> >>    topology where only links of > 10Mb/sec were allowed.  Does
> >>    the draft intend to enable this?
> >>
> >> CMD: Each link may or may not have a specific type of metric assigned,
> and therefor that link may or may not be part of the corresponding
> topology. It is thus straightforward to implement the example you describe.
> >
> > How would you describe the metric type for the two examples
> > as shown above?
>
> I'd pick two metric types from those available to be allocated
> administratively (which is missing from the IANA considerations section,
> but mentioned somewhere else) and define them that way in that network. (As
> something that specialised, it's not going to have a universal definition.)
>
> >> - I have always understood a metric to be a function that assigns
> >>    a metric value to a routing path.  Then, a metric type defines
> >>    the way that the function associates a value to a routing path.
> >>    Using typical functional notation, we would have:
> >>      v = f(path), where f is the metric and v is the value that f
> >>             assigns to the path.
> >>    Going a step further, we can consider the space of all routing
> >>    metrics, and have a "big" function F that assigns a metric value
> >>    to a path given two parameters -- namely, metric_type, and path.
> >>    Using typical functional notation, we would have:
> >>    v = F(type, path)
> >>
> >> The metrics are all (as in OLSRv2) assigned to links, path metrics are
> the sum of link metrics.
> >
> > This is natural; one can consider a "link" to be a path with only one
> > path component...
>
> That's putting the cart and the horse the wrong way round. This is a link
> state protocol. Metric are defined for links. Metrics for routes are
> defined as the sum of the link metrics, they have no separate existence
> from that. See RFC 7181 (as it will be in a few days).
>
> >>    Using this notation, then, the domain of f is "paths" and the
> >>    range is some set of allowable values.  Let's say that the domain
> >>    of f is D(f) and the range is R(f).  Then, as for any function,
> >>    we have f(D(f)) "is a subset" of R(f).
> >>
> >> Actually, that's not the mathematical notation I would use. Range is an
> overloaded term, some use it for R(f), some use it for f(D(f)). My
> lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is the
> image, range was banished.
> >
> > I reckon the word is not banished worldwide...  and, as you point out,
> > the word "codomain" is commonly defined differently than "range".
>
> Of course it's not banished worldwide. But I wouldn't use it anything
> precise, because of the ambiguity., and the availability of image and
> codomain to be precise. (And actually, there's a third option I could point
> to, where image and codomain are, of necessity, the same.) But it's all
> irrelevant. I agree the usage of range as it current is, is confusing
> because range is often used as a "right hand" thing, whether image or
> codomain is irrelevant.
>
> >>    The terminology in the draft should not be at odds with these
> >>    conventional mathematical notations.
> >>    map[range -> type]  seems to say that the "range" is the domain.
> >>
> >> Range is an overloaded word, and this isn't using it in that way.
> Though it's not a great usage even if we ignore the functional usage. I
> take your point, we should reconsider this terminology.
> >
> > Thanks -- I think that would be very helpful to avoid confusion. Usually,
> > even for words with overloaded meaning, either the meanings are not
> > contradictory, or the context can help disambiguate.  Usually, but not
> > always in colloquial English.  I think it's rare or even nonexistent when
> > using mathematical notation to have contradictory meanings for the same
> > word...
>
> Definitely not nonexistent.
>
> Range is one. If you want another, trapezium and trapezoid switch meanings
> when you cross the Atlantic.
>
> But I'm not going to get further stuck into that discussion. It's
> irrelevant to this draft - and this list.
>
> >>    It is confusing in multiple ways to say that "metric types" are
> >>    either:
> >>          boolean,
> >>          a willingness (a 4 bit unsigned integer from 0 to 15),
> >>          a number of hops (an 8 bit unsigned integer ..),
> >>          or a metric-value (as defined somewhere else).
> >>
> >> No, you've inserted the metric in your quote. This is saying that the
> type of the codomain of the map is always one of those three things.
> Generic type, not metric type.
> >
> > I guess "generic type" means "data type".  "boolean" and the others can
> > indeed be considered data types.  Since this effort is going to be
> closely
> > associated with managing metric types, maybe the draft has to be careful
> > about always using either "data type" or "metric type".  By the way, why
> > did you say "three things" instead of "four things"?
>
> Simple error (to the three/four). Consistently using the qualification you
> suggest for type is, I think (but co-authors can have opinions) a useful
> one. (And there are other types too, related to 5444, but I think those are
> already all qualified.)
>
> >>  The domain is an ordered set of metric types.
> >
> > Is it *really* an ordered set??  What is the ordering?  I would have
> > thought the only important thing here is that the correspondence
> > is a function.
>
> Is it ordered? Actually in this context, or a map, it doesn't need an
> order. But it does need an order when included in a message in TLVs.
> Personally I'd therefore implement it ordered so as to not have to sort
> those that needed to be ordered to include in TLVs. And then might as well
> do the same for all. But in an abstract model, it doesn't always (possibly
> never) need ordering. But I would need to read with care relating to
> parameter usage.
>
> >>  Those three things are things assigned to a topology (indexed by
> metric type).
> >
> > I think you mean something different, because the same topology
> > can very definitely be delineated by two different metrics.  Thus, you
> > would have to define some sort of multi-valued correspondence.
> > Yes, this can be done, but it is considerably more complicated.
>
> No, I mean what I said. This model of multi-topology has a one to one
> correspondence between metric type and topology. So the topologies are
> conveniently indexed by metric type. (Yes, many to one is considerably more
> complicated, especially with backward compatibility.)
>
> >> - The draft restricts applicability to "managed" MANETs. That is
> >>     probably appropriate, but could stand to have somewhat better
> >>     definition.  For the purposes of the draft, I imagine that
> >>     "manageability" means "running a specific predetermined set of
> >>     applications".
> >>
> >> CMD: No, I wouldn't make that definition, there's no reason to be that
> limited. What's critical is that routers will make a consistent judgement
> when forwarding a packet, which metric type should be used to forward that
> packet. What's important is that routers have a consistent approach to each
> metric type. (Critical means will do unpleasant things, like maybe looping,
> if not so. Important means will behave poorly, and may find bad routes, or
> no routes, if not so.) If it's agreed that (say) metric type X means fast
> reliable delivery, that X corresponds to DHCP type Y, and that packets
> should not be labelled Y without a very good reason, then we don't need to
> specify exactly what applications might create packets of that type.
> >
> > Sure.  It's almost tautological to limit the definition by your
> condition.
> > However, one has to wonder why the condition would be imposed.
> > When I start wondering that, the answer I get is that one wants to do
> > this because some application needs to be presented with a strictly
> > delimited set of routing choices, as defined by the metric (for example,
> > the "Cap-GT-10Mbps" metric).
>
> We need this to avoid any possibility of looping. That really is the
> reason. We had this discussion a while back on the list. And I wouldn't
> want to couple the network layer to applications.
>
> > --
> > Regards,
> > Charlie P.
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Apr 2014 12:37:35 +0000

The largest problem with topology other than as metric is the design aim to be interoperable with non-MT-OLSRv2. So far the only way to achieve both that we’ve come up with is thoroughly nasty, and significantly increases management requirements. The devil is in the details, it’s easy to come up with a partial idea, it’s the whole design that’s hard.

Once you are transmitting the same metric value more than once, you might as well call it a metric type. Which is the only backwardly compatible option we have anyway. And then type 0 as special in the way you indicate isn’t an option, because non-MT-OLSRv2 is not limited to type 0.

I’m afraid “first step” isn’t what’s needed, we have a constrained design space, and any proposal needs detailed design. As I said, the authors have so far tried and not found anything pleasant.

The 16 is a proposal for an administratively specified number. To be honest, this is a MANET, not a a heavy-duty network, and I’m not really expecting anyone to use quite that many, let alone more.

My greatest fear is that in the pursuit of the ideal, we give up on something useful that is good enough for most purposes.

(Incidentally, backwardly compatible can be with two disjoint networks. We could have two non-MT-OLSRv2 networks using types 42 and 57, and some MT-OLSRv2 using types 42 and 57. Routing would be within the 42 and 57 domains, the MT-OLSRv2 routers being in both.)

--
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 Christoph Barz
Sent: 02 April 2014 12:01
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>.
Hello Christoper,
hello Thomas,

While taking a first look at the current draft-ietf-manet-olsrv2-multitopology-00 I noticed the following:

1) The introduction and applicability statement identify the requirement to use different routing metrics as the reason for Multi-Topology OLSRv2. I would suggest extending this with a second motivation for MTR, the ability to define sub-topologies as an administrative means. Motivations for doing this include technology heterogeneity (excluding certain types of traffic from unsuitable links) or policy based routing (not wanting certain traffic to be routed via a special subset of nodes or links).

2) If we accept the second motivation for MTR, we should really drop the limitation in the applicability statement that each topology is characterized by a different choice of link metric type. Thus, we would have the many to relationship between topologies and metrics you mentioned in one of your previous mails:

          N       1

You also mentioned, that this would be more complicated and probably break the compatibility with non-MT OLSRv2. However, regarding the draft, it will probably be sufficient to substitute the term "metric type" with "topology" as a first step. It comes with the cost of potentially having transmit the same metric values several times. In fact this will be kind of a 1:1 relationship while dropping the requirement for the metrics to be different.
To be more efficient, we could also work on additional ways to transmit a single metric value for multiple topologies (if possible without breaking compliance with the basic draft).

3) Should we have a special topology 0 as default topology? This aspect was already mentioned by Jiazi. OSPF-MT uses the notion of default topology to be compliant with non-MT capable routers.  Non-MT capable routers will be limited to topology 0.

4) Is there a way to go beyond 16 possible topologies at the cost of efficiency at least as an optional feature?

Best regards
Christoph

2014-03-31 19:48 GMT+02:00 Christopher Dearlove <[email-masked]<mailto:[email-masked]>>:

On 31 Mar 2014, at 18:02, Charles E. Perkins wrote:

>> CMD: Each link may or may not have a specific type of metric assigned, and therefor that link may or may not be part of the corresponding topology. It is thus straightforward to implement the example you describe.
>
I'd pick two metric types from those available to be allocated administratively (which is missing from the IANA considerations section, but mentioned somewhere else) and define them that way in that network. (As something that specialised, it's not going to have a universal definition.)

>> The metrics are all (as in OLSRv2) assigned to links, path metrics are the sum of link metrics.
>
That's putting the cart and the horse the wrong way round. This is a link state protocol. Metric are defined for links. Metrics for routes are defined as the sum of the link metrics, they have no separate existence from that. See RFC 7181 (as it will be in a few days).

>> Actually, that's not the mathematical notation I would use. Range is an overloaded term, some use it for R(f), some use it for f(D(f)). My lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is the image, range was banished.
>
Of course it's not banished worldwide. But I wouldn't use it anything precise, because of the ambiguity., and the availability of image and codomain to be precise. (And actually, there's a third option I could point to, where image and codomain are, of necessity, the same.) But it's all irrelevant. I agree the usage of range as it current is, is confusing because range is often used as a "right hand" thing, whether image or codomain is irrelevant.

>> Range is an overloaded word, and this isn't using it in that way. Though it's not a great usage even if we ignore the functional usage. I take your point, we should reconsider this terminology.
>

Range is one. If you want another, trapezium and trapezoid switch meanings when you cross the Atlantic.

But I'm not going to get further stuck into that discussion. It's irrelevant to this draft - and this list.

>> No, you've inserted the metric in your quote. This is saying that the type of the codomain of the map is always one of those three things. Generic type, not metric type.
>
> indeed be considered data types.  Since this effort is going to be closely
Simple error (to the three/four). Consistently using the qualification you suggest for type is, I think (but co-authors can have opinions) a useful one. (And there are other types too, related to 5444, but I think those are already all qualified.)

> thought the only important thing here is that the correspondence
Is it ordered? Actually in this context, or a map, it doesn't need an order. But it does need an order when included in a message in TLVs. Personally I'd therefore implement it ordered so as to not have to sort those that needed to be ordered to include in TLVs. And then might as well do the same for all. But in an abstract model, it doesn't always (possibly never) need ordering. But I would need to read with care relating to parameter usage.

>>  Those three things are things assigned to a topology (indexed by metric type).
>
No, I mean what I said. This model of multi-topology has a one to one correspondence between metric type and topology. So the topologies are conveniently indexed by metric type. (Yes, many to one is considerably more complicated, especially with backward compatibility.)

>> CMD: No, I wouldn't make that definition, there's no reason to be that limited. What's critical is that routers will make a consistent judgement when forwarding a packet, which metric type should be used to forward that packet. What's important is that routers have a consistent approach to each metric type. (Critical means will do unpleasant things, like maybe looping, if not so. Important means will behave poorly, and may find bad routes, or no routes, if not so.) If it's agreed that (say) metric type X means fast reliable delivery, that X corresponds to DHCP type Y, and that packets should not be labelled Y without a very good reason, then we don't need to specify exactly what applications might create packets of that type.
>
> Sure.  It's almost tautological to limit the definition by your condition.
We need this to avoid any possibility of looping. That really is the reason. We had this discussion a while back on the list. And I wouldn't want to couple the network layer to applications.

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
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: Christoph Barz <[email-masked]>
Date: Wed, 2 Apr 2014 15:16:19 +0200

Hello Christopher,

2014-04-02 14:37 GMT+02:00 Dearlove, Christopher (UK) <
[email-masked]>:

>  The largest problem with topology other than as metric is the design aim
> to be interoperable with non-MT-OLSRv2. So far the only way to achieve both
> that we’ve come up with is thoroughly nasty, and significantly increases
> management requirements. The devil is in the details, it’s easy to come up
> with a partial idea, it’s the whole design that’s hard.
>

I will discuss with Henning if we can come up with a more concrete proposal.

> Once you are transmitting the same metric value more than once, you might
> as well call it a metric type. Which is the only backwardly compatible
> option we have anyway. And then type 0 as special in the way you indicate
> isn’t an option, because non-MT-OLSRv2 is not limited to type 0.
>
>
>
> I’m afraid “first step” isn’t what’s needed, we have a constrained design
> space, and any proposal needs detailed design. As I said, the authors have
> so far tried and not found anything pleasant.
>

You are right, you could also call it a metric type. However, the
formulation in the applicability statement says that each topology is
characterized by a different choice of link metric type. This could be
ambiguous. We should clearly state that it does not mean that different
metric definitions are a requirement in this context.

The 16 is a proposal for an administratively specified number. To be
> honest, this is a MANET, not a a heavy-duty network, and I’m not really
> expecting anyone to use quite that many, let alone more.
>

I agree that 16 is already a very large number of topologies for MANETs.
However, if you are using MT routing not only to have different metrics but
to do policy based routing, in some corner cases you might not want to be
restricted to 16.

 My greatest fear is that in the pursuit of the ideal, we give up on
> something useful that is good enough for most purposes.
>

Sure, you are absolutely right.

>
>
> (Incidentally, backwardly compatible can be with two disjoint networks. We
> could have two non-MT-OLSRv2 networks using types 42 and 57, and some
> MT-OLSRv2 using types 42 and 57. Routing would be within the 42 and 57
> domains, the MT-OLSRv2 routers being in both.)
>
>
>

Best regards
Christoph

> [email-masked] | http://www.baesystems.com
>
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Christoph
> Barz
> *Sent:* 02 April 2014 12:01
> *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>.*
>
>   Hello Christoper,
>
> hello Thomas,
>
> 1) The introduction and applicability statement identify the requirement
> to use different routing metrics as the reason for Multi-Topology OLSRv2. I
> 3) Should we have a special topology 0 as default topology? This aspect
> was already mentioned by Jiazi. OSPF-MT uses the notion of default
> topology to be compliant with non-MT capable routers.  Non-MT capable
> routers will be limited to topology 0.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Apr 2014 13:23:40 +0000

Incidentally as I recall, part of our unpleasantness was having to invent new values such as (name just for illustrative purposes) MT_SYMMETRIC for TLVs such as LINK_STATUS, where MT_SYMMETRIC means “if you are running MT-OLSRv2, treat as SYMMETRIC, if you are running non-MT-OLSRv2 you will ignore this as specified by RFC 7188 [or will be RFC 7188 in a few days]”. Right now I don’t recall exactly how or why this was used, and in any case I don’t want to use it, it was just part of the least bad hackery we could come up with. But it illustrates a warning, you have to get quite deep into design to realise this – or maybe find something better.

From: manet [mailto:[email-masked]] On Behalf Of Christoph Barz
Sent: 02 April 2014 14:16
To: Dearlove, Christopher (UK)
Cc: Christoph Barz; [email-masked]
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

*** WARNING ***

2014-04-02 14:37 GMT+02:00 Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:
The largest problem with topology other than as metric is the design aim to be interoperable with non-MT-OLSRv2. So far the only way to achieve both that we’ve come up with is thoroughly nasty, and significantly increases management requirements. The devil is in the details, it’s easy to come up with a partial idea, it’s the whole design that’s hard.

You are right, you could also call it a metric type. However, the formulation in the applicability statement says that each topology is characterized by a different choice of link metric type. This could be ambiguous. We should clearly state that it does not mean that different metric definitions are a requirement in this context.

I agree that 16 is already a very large number of topologies for MANETs. However, if you are using MT routing not only to have different metrics but to do policy based routing, in some corner cases you might not want to be restricted to 16.

Best regards
Christoph

Tel: +44 1245 242194<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christoph Barz
Sent: 02 April 2014 12:01
To: Christopher Dearlove

Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

*** WARNING ***

hello Thomas,

          N       1

Best regards
Christoph