AB,
thank you for the review. See my answer below:
On Sun, Feb 10, 2013 at 3:08 AM, Abdussalam Baryun
<abdussalambaryun@xxxxxxxxx> wrote:
>
> Reply to your request dated 07/02/2013
> Also following AD advice.
> Draft Reviewed By: Abdussalam Baryun (AB) Dated: 10/02/2013
>
> Reviewer Comment #AB1: Related to Aim and Terminology.
> ++++++++++++++++++++++++++++++++++++
>
> Overall I support the work, but subject to amendments.
>
> The Abstract is interesting but seem general
Do you have any specific suggestions what you would like to add/change
in the abstract?
> > This document specifies the "Depth-First Forwarding" (DFF) protocol
> > for IPv6 networks,
>
> AB> do you mean all IPv6 networks, if some please mention *some*
I don't think this is relevant to add in the abstract. As stated in
section 3 of the draft, it can be used for all IPv6 networks, but for
some the protocol is not very beneficial (and examples are given for
such situations).
> > a data forwarding mechanism that can increase
> > reliability of data delivery in networks with dynamic topology and/or
> > lossy links.
>
> AB> IPv6 considers dynamic topology, does the paragraph mean that some
> networks are static topology.
I am not quite sure what you mean by IPv6 "considers topology". In a
static topology (i.e. with no or very few changes of links) and with
low packet loss rate, the DFF protocol would have little (or no)
benefit, because most likely the packets would be sent from the source
to the destination according to the information provided by the
routing protocol, and no packets would be lost.
> Suggest to clarify the dynamic
> frequency.
I am not sure what you would like to see clarified. Can you be more specific?
> Also not clear what is missing with IPv6 protocol in such
> nets that needs DFF.
If you mean data forwarding, I think the draft is pretty clear about
which cases it is beneficial in. The motivation for DFF is explained
in section 1.1.
> > The protocol operates entirely on the forwarding plane,
> > but may interact with the routing plane.
>
> AB> amend> entirely on the forwarding plane,
> to; entirely within the forwarding plane,
I am not a native English speaker, but "to operate on" seems a valid
usage of the word. But maybe a native speaker could suggest which is
the right usage.
>
> > The routing plane may be informed of
> > failures to deliver a packet or loops.
>
> AB> Amend> routing plane may be informed
> to; routing plane protocols may be informed
I think the current sentence is sufficient; I don't see the benefit of
adding the word "protocols".
> Terminology section>
>
> AB> you need to define that all routers have the DFF protocol, even
> though it is known by heart that any forwarder needs to run DFF but
> you MUST mention that at least to the reader,
I think this is actually a good point. I was wondering whether to
enforce all routers in a routing domain to run DFF. That does not seem
like a reasonable approach. I found only one case that could be a
problem when using both DFF and non-DFF routers in the network that
results in a loop, but I think I found an easy fix. Here is the
problem illustrated using an example:
...--- A ----- B ---- C --- ...
Assume routers A and C use DFF, but not B. When B receives a packet
from A, it would ignore the DFF header and skip over it, and then
forward the packet to C (assuming C is the next hop in its RIB). Now,
it is possible that C returns the packet (RET==1) to B, e.g. because
it does not have any other neighbor. B receives the returned packet
and would resend the packet to C (because it does not care about the
DFF header), and thus RET would still be 1. C, having tried already
all neighbors would return the packet to B (and so on, loop between B
and C until hop-limit == 0).
I see the following options:
1) Change the options header type from something starting with 001
(i.e. "skip over this option and continue processing the header.") to
011 ("discard the packet.") in IPv6 to discard the packet if the
header is unknown. This would avoid the problem, but I don't think
that's possible for 6lowpan mesh-under.
2) Mandate that all routers in the routing domain "MUST use DFF" for
forwarding packets.
3) Add a rule that if a packet is returned (RET==1) from P_prev_hop
(i.e. the original previous hop when first received a packet), it is
discarded, e.g. if router C receives a packet from B with RET==1 and B
is the P_prev_hop.
Option 1) would be possible, but not for 6lowpans, only for IPv6
route-over. Option 2) is probably not very good. Option 3) would fix
the loop issue, and thus allows non-DFF and DFF routers in the same
network. I will provide some updated text in the next revision of the
draft.
>
> AB> you missed to define the Router, which is mentioned many times but
> I don't know which one. I think it is a must because you refer to two
> planes forwarding and routing planes. Please define the Forwarder as
> well. I don't find any Forwarder action in the draft, why not while
> you specify there is a forwarding plane!
I am undecided on defining the term "router". It is a well-known term
in IETF; but then, maybe one could define it like in RFC6130 ("Router
- A router running this protocol"). Not sure this conveys a lot of
information, though. So unless others also suggest adding it, I will
not change the terminology section.
Since I don't use the term "forwarder" (which is usually part of the
functions of a router), I don't think I should define that in the
terminology.
>
> AB> suggest that you explaine forwarding and routing in separate and
> show where they join relating to your protocol.
I think the concept of forwarding and routing plane is fairly well
understood in the IETF, so I don't think I should re-explain that in
the draft.
Best regards
Ulrich