Subject: [manet] draft-ietf-manet-olsrv2-multitopology-02

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 1 Jul 2014 16:45:55 +0000

Working group participants, 

It is time for a Working Group Last Call on the above mentioned draft. Please review and submit any comments to the mailing list by close of business on July 14. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 2 Jul 2014 15:35:23 +0100

Hi Stan,

I am not ready for last call and IMHO the WG did not discuss it enough, no
one reviewed. I think it needs minimum three months for last call. However,
I will try to review, and I think I made many issue-questions before to
the author but still did not get answers (I will repeat them when I review
anyway). Thanks.

AB

On Tuesday, July 1, 2014, Stan Ratliff (sratliff) wrote:

> It is time for a Working Group Last Call on the above mentioned draft.
> Please review and submit any comments to the mailing list by close of
> business on July 14.
>
> Regards,
> Stan
> _______________________________________________
> manet mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Jul 2014 14:58:24 +0000

The period for WGLC is not actually laid down in BCP 25, WGLCs are managed by WG chairs in consultation with ADs. But the period the chairs have set this time is fairly typical. Three months is entirely inappropriate.

As for no one reviewed, that’s what this period is for. And while no one has written up a formal review, people have read the earlier drafts (the latest draft does not include any major changes) and it was presented as far back as Berlin.

I do not recall any previously asked and unanswered questions from you.

What I would say is that the concept of a multitopology link state routing protocol is not breaking new ground – see RFC 4915 for OSPFv2 for example. The issues here are first interoperability with non-MT-OLSRv2, which the authors think is important and haven’t had any push back on, and the devil in the details as ever.

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance 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: 02 July 2014 15:35
To: Stan Ratliff (sratliff)
Cc: manet IETF
Subject: Re: [manet] draft-ietf-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>.

Hi Stan,

I am not ready for last call and IMHO the WG did not discuss it enough, no one reviewed. I think it needs minimum three months for last call. However, I will try to review, and I think I made many issue-questions before to the author but still did not get answers (I will repeat them when I review anyway). Thanks.

AB

Regards,
Stan
_______________________________________________
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: Jiazi YI <[email-masked]>
Date: Wed, 2 Jul 2014 17:16:50 +0200

On Wed, Jul 2, 2014 at 4:35 PM, Abdussalam Baryun <
[email-masked]> wrote:

> one reviewed.

If the draft is discussed enough is very subjective, so I won't comment.
But "no one reviewed" is absolutely not true. There have been discussions
on the draft. Personally, I gave comments before also (any will give
another review).

Jiazi

>> [email-masked]
> [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Jul 2014 17:42:09 +0200

> I am not ready for last call and IMHO the WG did not discuss it enough, no

I disagree strongly. I did implement it and the point is that just a
few points came up. All of them were mentioned on the list.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 02 Jul 2014 18:35:49 +0200

I support publication of this draft as an Experimental RFC.
Experimental RFCs are cool.

I have one major concern about this draft, and some minor nits.

While the title implies that it defines fully general multi-topology
routing, the actual protocol strongly links the topologies to metric
types.  I'm not sure if that's intended.

In particular, multi-topology seems like a useful extension to implement
routing policies, say "avoid links that don't enforce link-layer encryption"
or "avoid routers that belong to Henning".  It would seem at first sight
that I would need to encode such policies in a metric in order to make use
of this extension.

Minor nits:

It would be good to state the invariants enforced and not enforced.
I could be wrong, but I understand that the topologies can be different
for different metrics, but every topology must be a subgraph of the
topology advertised to non-MT routers.  If that's right, that's a useful
property to help the reader get an intuitive feel.

1. Introduction

"it would be desirable to be able to use alternative metrics for different
packet routing."  Sounds strange.  I suggest "for routing different packets".

3. Applicability Statement

I'd like to know whether the data plane mechanism is expected to revert to
a default metric if no route is found to a given destination or not.
I assume not (which would confirm my guess that this is policy routing).

I'm also a little worried about delegating this mechanism to an external
mechanism.  If different routers implement different mechanisms, won't
persistent routing loops arise?

4. Protocol Overview

I found this section difficult to read for purely syntactic reasons.

"However there may be deployments where routers, that do not implement
MT-OLSRv2 (non-MT-OLSRv2 routers), are to participate in a MANET with
MT-OLSRv2 routers."  Remove both commas.  Or perhaps reformulate as "There
may be deployments where both MT-OLSv2 and non-MT-OLSRv2 routers
participate in a single routing domain" or somesuch.

"advertised neighbor status, is maintained per supported neighbor".
Remove the comma.

"More so than OLSRv2, the use of multiple metric types across the MANET
must be managed, by administrative configuration or otherwise."  Strange
syntax.

12. Management considerations

It's still not clear to me how the protocol avoids loops if different
routers map the same DSCP to different metrics.  If you're assuming the
mapping is uniform, it should be stated in this section.

Shouldn't the last three bullet points be a single point?

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Jul 2014 18:47:36 +0200

> that I would need to encode such policies in a metric in order to make use

I had the same discussion with Christopher before... its more a
"multi-metric" draft, but you can argue about the name.

In theory you could announce the same metric value twice, once for
each "sub-topology" and then leave out the metric for links you don't
like, but that is a lot of overhead.

But I have an idea for a "sub-topology" extension for this draft.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 18:19:47 +0100

It is intended that metric = topology, because no one (authors included, who have tried) has come up with a solution that separates the two, interworks correctly with non-MT-OLSRv2, and isn't truly horrible. (Much greater need for planned conformity of routers can also be a problem.)  That challenge had been on the table for months. No one even produced one that just failed the truly horrible test. It's also nothing unusual - look at OSPFv2 (RFC 4915) which essentially does the same.

Note that by ensuring that 8 (the authors also considered 16, and would be open to changing that) metrics are administratively configured, there's always scope for a reasonable number of topologies.

I'm not going to address all the points now (I'm on a mobile phone) but with regard to looping, because a packet travels by one metric and one metric only - no default fallback - it should not loop. In fact that's exactly why that behaviour.

Where is there a suggestion of mapping one DSCP to multiple metrics? That's exactly backwards. Of course the mapping of packet to metric is outside the scope of this draft (even whether to use DSCP) except it should be clear that the mapping must be well-defined and produce the same result at each router for each packet. That may need to be said more clearly (I don't have draft in front of me to see what exactly is said).

-- 
Christopher Dearlove

> On 2 Jul 2014, at 17:35, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 18:25:20 +0100

If you can come up with one that works, we'd like to see it. (We'd have even more liked to have seen it earlier.) Note that some apparent ideas turn out not to work - I've tried some.

I (note the change from we) also wouldn't find a solution that forces over-management acceptable. Note that the current design allows all routers to make independent choices as to which metrics/topologies to support.

(I also don't agree it's not multi-topology. If so, neither is RFC 4915.)

-- 
Christopher Dearlove

> On 2 Jul 2014, at 17:47, Henning Rogge <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 02 Jul 2014 19:33:03 +0200

> It is intended that metric = topology, because no one (authors included,
> who have tried) has come up with a solution that separates the two,
> interworks correctly with non-MT-OLSRv2, and isn't truly horrible.

Ok, that's a very good reason.  I suggest putting that in the introduction.

> Where is there a suggestion of mapping one DSCP to multiple metrics?

There's nothing that says that the DSCP mapping must be consistent between
distinct routers.

> it should be clear that the mapping must [..] produce the same result at
> each router for each packet. That may need to be said more clearly

Yes, please.

-- Juliusz

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 18:44:53 +0100

Well, before we say it's not possible, let's see if Henning (or anyone else, but he seems most likely to succeed) has an idea that works. All I can say is that the authors haven't found one. I wouldn't want to wait indefinitely for an idea, this is of course only aimed at Experimental, but an idea (enough to assess) before WGLC deadline would need to be considered as to whether to adopt.

(We did have to give up on one idea that looked promising at one point, of allowing inter working with more than one non-MT-OLSRv2 network using different metrics. It's possible we could treat the one metric we now do recognise as non-MT-OLSRv2 as a special case. Which already puts a kink in things as that's likely to be the "best" metric. The problems then start arising as to how to define topology to metric mapping, especially without making the network ad hoc in name only.)

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

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Jul 2014 19:59:35 +0200

Hmm,

my idea would be to have a second TLV similar to TLV_TYPES, which
defines a mapping of an index to a "full topology/metric" (can use the
same topology number multiple times).

The MPR bitarray and Willingness array just gets extended by a number
of entries according to the length of the new mapping TLV.

Each address in a TC needs an additional TLV with a bitarray that
defines if the link is available for each of the mappings.

This should allow you to save a lot of bytes because you don't have to
announce the same metrics multiple times.

I still have to go through the details (earlier I thought I would not
need a TLV for each address in the TCs), but I think it could work.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 19:12:42 +0100

I'm not liking it so far, for a number of reasons, but let's see where it goes, as none are fatal yet.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 2 Jul 2014 20:03:01 +0100

I am sorry Henning, I try my best to track reviews, I still did not review
but I seen your review to individual draft and did not see the WG document
as mentioned by Chair. However, I still not have time to check but if there
was no changes between draft before adopted and after, then that was the
reason of my misunderstanding of your review.

(I usually check reviews of WG drafts more than individuals, even if they
have same title and abstract, I had confused my progress with one NHDP
individual draft before, because there may be few changes done by authors
after adopted, and reviews cannot be tracked).

AB

On Wednesday, July 2, 2014, Henning Rogge wrote:

> <[email-masked] <javascript:;>> wrote:
> >
> > Hi Stan,
> >

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 2 Jul 2014 23:18:10 +0200

> On 02 Jul 2014, at 19:25, Christopher Dearlove <[email-masked]> wrote:
> 
> I (note the change from we) also wouldn't find a solution that forces over-management acceptable.

Oh, you could write "we" instead of "I" here, if you intended to mean "the authors" ;)

Thomas

> Note that the current design allows all routers to make independent choices as to which metrics/topologies to support.
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 2 Jul 2014 23:16:55 +0100

I hadn't checked that with you, so although you don't surprise me, that needed to be I then.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Jul 2014 13:11:51 +0000

Comments below, CMD: Thanks for your comments.

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

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Juliusz Chroboczek
Sent: 02 July 2014 17:36
To: Stan Ratliff (sratliff)
Cc: manet IETF
Subject: Re: [manet] draft-ietf-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.
--------------------------------------------------------

While the title implies that it defines fully general multi-topology routing, the actual protocol strongly links the topologies to metric types.  I'm not sure if that's intended.

In particular, multi-topology seems like a useful extension to implement routing policies, say "avoid links that don't enforce link-layer encryption"
or "avoid routers that belong to Henning".  It would seem at first sight that I would need to encode such policies in a metric in order to make use of this extension.

CMD: Commented previously, and an ongoing discussion.

Minor nits:

It would be good to state the invariants enforced and not enforced.
I could be wrong, but I understand that the topologies can be different for different metrics, but every topology must be a subgraph of the topology advertised to non-MT routers.  If that's right, that's a useful property to help the reader get an intuitive feel.

CMD: I noted that the mapping packet -> metric (topology) needs to be stated as well-defined, same at all routers. That belongs in Section 3.

CMD: It's not actually necessary for the property you suggest to be true. It's only necessary to support the default metric if you can communicate directly with a non-MT router. And thus you could have a non-default part of the network. Simplest (but stupid) case is A - B - C, where B talks to A and C on different and non-compatible interfaces (say, different frequencies). Default metric 0, supported by non-MT C. A supports metric types 1 and 2, B supports metric types 1 and 2 on interface to A and (at least) 0 on interface to C. This assumes A and C never talk directly. Slightly more sensible is A - B - C - D where A, B and C support metric type 1 and B, C and D support metric type 2, on physically different interfaces. D is non-MT. B and C are doubly connected.

1. Introduction

"it would be desirable to be able to use alternative metrics for different packet routing."  Sounds strange.  I suggest "for routing different packets".

CMD: I think more extensive surgery on that sentence would be even better.

I'd like to know whether the data plane mechanism is expected to revert to a default metric if no route is found to a given destination or not.
I assume not (which would confirm my guess that this is policy routing).

I'm also a little worried about delegating this mechanism to an external mechanism.  If different routers implement different mechanisms, won't persistent routing loops arise?

CMD: See above. But it really has to be an external mechanism - it's happening in a different process, typically using concepts (like DSCP - but not tied to that) that are outside OLSRv2. It is a management issue, and I need to check it's mentioned in the management section.

4. Protocol Overview

"However there may be deployments where routers, that do not implement
MT-OLSRv2 (non-MT-OLSRv2 routers), are to participate in a MANET with
MT-OLSRv2 routers."  Remove both commas.  Or perhaps reformulate as "There may be deployments where both MT-OLSv2 and non-MT-OLSRv2 routers participate in a single routing domain" or somesuch.

CMD: Iprefer removing the commas (I'm not sure why they are there) as at this point we haven't actually defined non-MT-OLSRv2 router.

CMD: It needs moving rather than removing, before for.

"More so than OLSRv2, the use of multiple metric types across the MANET must be managed, by administrative configuration or otherwise."  Strange syntax.

CMD: I know what it means, but ...

It's still not clear to me how the protocol avoids loops if different routers map the same DSCP to different metrics.  If you're assuming the mapping is uniform, it should be stated in this section.

CMD: Yes, this should be said here as well as in Section 3.

CMD: I think what I prefer is that the last two bullets should be sub-bullets of the currently  pre-penultimate bullet.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Jul 2014 15:34:31 +0200

> it really has to be an external mechanism - it's happening in
> a different process, typically using concepts [...] that are outside
> OLSRv2.

I was thinking about advertising the mapping over the protocol, and
refusing to use a metric for which two neighbours have different mappings.
But that's probably overdoing it at this stage -- only implementation
experience will tell if the requirement to manually ensure uniformity is
too onerous, and publishing this as Experimental seems like a good way to
encourage experimentation.

-- Juliusz

P.S. Wow, all your e-mails get defaced like that?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Jul 2014 15:46:09 +0200

> CMD: It's not actually necessary for the property you suggest to be true...

I got it, thanks.

I think it would be helpful to include a slightly more abstract version of
this explanation in the introduction to the document.

-- Juliusz

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 18 Jul 2014 10:59:31 +0100

On Wednesday, July 2, 2014, Dearlove, Christopher (UK) wrote:
>  http://www.ietf.org/mail-archive/web/manet/current/msg15850.html

The questions were for the draft before adoption, but if answered will help
the experiment of this adopted protocol. I am sorry for not complete review
but will submit shortly before meeting.

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 22 Jul 2014 12:26:42 +0000

All of those questions are answered in the draft, in particular in Section 4.

From: Abdussalam Baryun [mailto:[email-masked]]
Sent: 18 July 2014 11:00
To: Dearlove, Christopher (UK)
Cc: Stan Ratliff (sratliff); manet IETF
Subject: Re: [manet] draft-ietf-manet-olsrv2-multitopology-02

*** WARNING ***

The questions were for the draft before adoption, but if answered will help the experiment of this adopted protocol. I am sorry for not complete review but will submit shortly before meeting.

AB