[homenet] Alia Atlas' No Objection on draft-ietf-homenet-hncp-09: (with COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-hncp-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/



--
COMMENT:
--

I support Brian's Discuss.

1)  In Sec 1.1, it states "...in homenet environments where multiple IPv6

   source-prefixes can be present, routing based on source and
destination 
   address is necessary [RFC7368]."
  
   Looking at RFC7368, I don't see anything that matches the strength of
this
   assertion which says in Sec 3.2.4 merely  "Another avenue is to
introduce support
   throughout the homenet for routing that is based on the source as
   well as the destination address of each packet."

   While src-dest routing is certainly a solution - and an interesting
one - it doesn't
   seem at all appropriate for an HNCP spec to assert that it is
necessary.

2) For the DNCP profile,  draft-ietf-homenet-dncp-12 says  "Anything
received over multicast, except Node Endpoint TLV (Section 7.2.1) and
Network State TLV (Section 7.2.2)." and this draft says "HNCP nodes MUST
ignore all Node State TLVs received via multicast
 on a link which has DNCP security enabled in order to prevent spoofing
of node state changes."
Could you please align and clarify the desired behavior for HNCP?


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Alia Atlas' Yes on draft-ietf-homenet-dncp-11: (with COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-dncp-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--

Thank you very much for addressing my previous Discuss points and
comments.  
I understand that version -11 will handle the most recent concerns, as
shown in 
the github diff.

I've also read this draft too many times at this point to be certain that
I've picked up all the points of
unclarity. 

a) As pointed out by Lizhong, it would be very useful to have some text
discussing
the issues around a network hash collision.  I suspect that this is
related to guidance
for a DNCP profile on how to make a decision about what hash function to
use and
how many bits to include

6) Please define H(...) in terminology, since Sec 4 uses it before it is
defined in 
Section 7.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Alia Atlas' Yes on draft-ietf-homenet-dncp-11: (with COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-dncp-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
COMMENT:
--

Thank you very much for addressing my previous Discuss points and
comments.  
I understand that version -11 will handle the most recent concerns, as
shown in 
the github diff.

I've also read this draft too many times at this point to be certain that
I've picked up all the points of
unclarity.  I've requested another Routing Directorate review, from a new
reviewer, so I may be modifying
my ballot again before the telechat on Thursday.

6) Please define H(...) in terminology, since Sec 4 uses it before it is
defined in 
Section 7.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)

[Alia Atlas]

Hi Steven,

The changes look goodThank you.
I'd recommend putting H() in the terminology.  I agree that it's defined at
the start of Section 7 - but it is used earlier around Sec 4.2.  You can
also
refer to H() where how to calculate the network hash is defined.

I think the draft is a lot more readable and easier to understand now.

As I said in my discuss, I may have a few more comments from a
Routing Directorate review (since I'm no longer a new reader), but you've
nicely addressed all my concerns.

thanks,
Alia



On Tue, Oct 20, 2015 at 7:31 AM, Steven Barth  wrote:

> Hi Alia,
>
> thanks a lot for your continuous reviews. I have staged a few changes in
> our Git to address your remaining issues. We will include it in a an
> upcoming version with fixes for other remaining blockers left in -11.
>
> See: https://github.com/fingon/ietf-drafts/commit/374a4a3
> More replies inline below.
>
> Thanks,
>
> Steven
>
>
> > 1) End of Sec 4.4, can you clarify what the behavior is for
> > unrecognized TLV that is included in the Node Data field of a Node
> > State TLV?  I assume that its meaning is not processed, but it is
> > included in the computation of the Node State Hash?
>
> Clarified.
>
> >
> > I've also read this draft too many times at this point to be certain that
> > I've picked up all the points of
> > unclarity.  I've requested another Routing Directorate review, from a new
> > reviewer, so I may be modifying
> > my ballot again before the telechat on Thursday.
>
> Thanks.
>
> >
> >
> > --
> > COMMENT:
> > --
> >
> > I also have a few more minor comments that affect readability.
> >
> > 2) On p. 6, Definition of Peer means that the same DNCP node using a
> > different local and remote endpoint pair would be a different Peer??
> > Is that intentional?
>
> Changed to "at least one".
>
>
> > 4) In Sec 4.5, it seems unfortunate to have old network and
> > connectivity state stored.  It seems to me that it'd be fairly trivial
> > to describe a "polite neighbor" termination policy where a peer sends
> > an Node Data TLV for itself with no data in it - including Node
> > Endpoint TLVs.  I am a bit nervous about bad side effects, but I do
> > not have a specific example to mind and obviously, a neighbor can fail
> > as well as gracefully shut down connections.  Describing "polite
> > neighbor"
> > behavior may be too much of a technical change at this point, but I'd be
> > happy if you think about it seriously.
>
> I think there are legitimate cases where this graceful termination is
> redundant, i.e., because the derived protocol employs a transport or
> link-layer that provides such events already. Nevertheless I guess a
> derived protocol could probably with some care add such a mechanism
> where it makes sense. I'm a bit reluctant to add it as that stage really.
>
>
> > 5) In Sec 7.2.2, it says "This TLV contains the current locally
> > calculated network state hash, see Section 4.1 for how it is calculated."
> >  This describes the value when sent.  When received, it contains the
> > Peer's network state hash.
>
> Changed to "contains the current network state hash calculated by its
> sender"
>
> > 6) Please define H(...) in terminology, since Sec 7 uses it.
>
> Hmm, it is currently defined at the beginning of Section 7 just before
> the first sub-paragraph so I am not sure if it will add more clarity to
> also add it to the terminology.
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-dncp-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/



--
DISCUSS:
--

Thank you very much for addressing my previous Discuss points and
comments.  On a fresh read of the updated draft,
I have the following one minor point (but it matters for interoperability
with DNCP profiles):

1) End of Sec 4.4, can you clarify what the behavior is for
unrecognized TLV that is included in the Node Data field of a Node
State TLV?  I assume that its meaning is not processed, but it is
included in the computation of the Node State Hash?

I've also read this draft too many times at this point to be certain that
I've picked up all the points of
unclarity.  I've requested another Routing Directorate review, from a new
reviewer, so I may be modifying
my ballot again before the telechat on Thursday.


--
COMMENT:
--

I also have a few more minor comments that affect readability.

2) On p. 6, Definition of Peer means that the same DNCP node using a
different local and remote endpoint pair would be a different Peer??
Is that intentional?

3) In Sec 4.1.1, I had no idea that the node's sequence number was
included before.  Thank you for the extra clarity!

4) In Sec 4.5, it seems unfortunate to have old network and
connectivity state stored.  It seems to me that it'd be fairly trivial
to describe a "polite neighbor" termination policy where a peer sends
an Node Data TLV for itself with no data in it - including Node
Endpoint TLVs.  I am a bit nervous about bad side effects, but I do
not have a specific example to mind and obviously, a neighbor can fail
as well as gracefully shut down connections.  Describing "polite
neighbor"
behavior may be too much of a technical change at this point, but I'd be
happy if you think about it seriously.

5) In Sec 7.2.2, it says "This TLV contains the current locally
calculated network state hash, see Section 4.1 for how it is calculated."
 This describes the value when sent.  When received, it contains the
Peer's network state hash.

6) Please define H(...) in terminology, since Sec 7 uses it.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS and COMMENT)

[Alia Atlas]

Hi Steven,

On Thu, Oct 8, 2015 at 2:19 AM, Steven Barth  wrote:

> Hello Alia,
>
> unfortunately we haven't gotten any response from you wrt. your DISCUSS on
> DNCP yet.
> We would really like to address the issues you have raised, but would need
> some feedback
> from your side to do so. Please note that we have pushed a new revision in
> the meantime
> and tried to clear off the remaining issues in our mail from September
> 17th which I have
> quoted below again.
>

I was waiting for the updated version and have now read it.

I did find the changes and extra text to be good improvements.

What is missing is frequently absolute clarity on how to do various parts.

If you want, I can take a pass at some more serious restructuring and
writing
some clarifications - but I will only do that if you feel it is helpful.


> Please let us know how to proceed on the matter to resolve your DISCUSS.
>
>
>
> Thanks,
>
>
> Steven
>
>
>
> On 17.09.2015 17:10, Steven Barth wrote:
> > Hello Alia,
> >
> >
> > please find replies inline.
> >
> >
> > Cheers,
> >
> > Steven & Markus
> >
> >
> >> --
> >> DISCUSS:
> >> --
> >>
> >> First,  I have a number of specific comments.   Some of these are
> hazards
> >> to technical interoperability; I've tried
> >> to include those in my discuss - but the general point is that it is
> very
> >> hard to tell a number of details because the
> >> structure is assumed.   Having read this document, I do not think that I
> >> could properly implement DNCP from scratch.
> >
> > Please note that an independent DNCP (or more specifically an HNCP)
> > implementation has been successfully developed based on
> > an earlier version of this draft and has been shown to be
> > interoperable with the reference implementation of the draft authors.
> > We used the implementer’s feedback afterwards to further refine the draft
> > to avoid possible ambiguities.
>

I understand that but there were still a number of gaps.  For instance, I
see nothing
that describes how to compute the network state hash.  I would expect a
section like:

"4.1.1 Computing Node Data Hash

To compute the data hash associated with a node, the TLVs are ordered first
based
on the lowest type and then numerically increasing based on the values.
This creates
a bit string that is input to the Hash Function specified by the DNCP
application profile.  The
length of the output hash is dependent upon the DNCP application profile.
The following gives an example using the fictitious profile given in
Appendix C.

.

A Node Data Hash may be computed for a locally stored node or for a Node
TLV that is
received in the following cases

4.1.2  Computing a Network State Hash

To compute the Local Network State Hash, only the nodes which are
bidirectionally connected
to the local node can be used.  These nodes are determined by the algorithm
given in
Section 4.6 which determines the current network topology graph from the
local computing
node's perspective.  As discussed in Section 4.6, any nodes which are not
reachable
may be removed from the local node's knowledge; at a minimum, such nodes
MUST NOT
be used in computing the Local Network State Hash.

To compute a Received Network State Hash, the local node uses the
information from the
associated received Node TLVs.  If Node Data is included in a Node TLV,
then an updated
Node Data Hash MUST be computed as described in Sec 4.1.1.  Otherwise, the
Node Data
Hash contained in the Node TLV MUST be used.  . It is assumed that all
nodes included in the
Network State TLV are considered to be bidirectionally reachable by the
originating node.

To compute either a Local or a Received network state hash, the nodes are
ordered based
upon their node identifiers in increasing numerical order.  Each node is
checked to see that
it has an updated Node Data Hash.  A node is considered to have an updated
Node Data Hash if 
If a node doesn't have an updated Node Data Hash, then that must first be
computed before
the Network State Hash can be computed.  Finally, the bit string created by
taking the Node Data
Hash of each node in the specified ordered is input to the Hash Function
specified by the
DNCP application profile.  The  length of the output hash is dependent upon
the DNCP
application profile.

The following is an example using the fictitious profile given in
Appendix C.

...


The Local Network State Hash is recomputed when 
"


>> a) What is a topology graph?  When is it created, modified, or destroyed?
> >>  Is it a conceptual artifact constructed
> >> from the various TLVs?  I think a quick paragraph describing it would
> >> help.
> >
> > The term “topology graph” is defined in the Terminology Section and based
> > on bidirectional peer reachability which is defined right afterwards. In
> the
> > latter definition it is mentioned that 

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Henning,

On Tue, Aug 25, 2015 at 1:17 PM, Henning Rogge hro...@gmail.com wrote:

 On Tue, Aug 25, 2015 at 7:02 PM, Alia Atlas akat...@gmail.com wrote:
  Ted, I asked a question about a feature that is considered critical in
 every
  routing environment that I am familiar with.
  I find it frustrating that looking ahead to significantly more complex
 home
  networking topologies and link types, which may be
  many years out still, is unexceptional, but asking about a feature that
  allows better use is described as premature optimization.
  I am asking about a routing requirement.
 
  I still am not clear on how link interference is handled for different
  destinations.

 The options I know are ignore it or include the interference domain
 size into the link cost.


Ok - it makes sense to me about including it in the link cost.


 Still, using multipath in wireless environments can be tricky... it is
 quite easy to mess up even with two paths and get less throughput than
 from a single path.


So the concern is getting worse throughput to the same destination - but for
different destinations, one just hopes the information in the link cost are
sufficient?


 There is also the point that multipath choices tend not to be
 isometric... just because the two paths from your local point of view
 seem to be good they are not necessarily good from the point of view
 of the next hop.


In a way that can't be captured by link metrics?  I haven't really looked at
the unique characteristics for wireless.  I'm happy to do a bit of
self-education.

Thanks,
Alia


 Henning Rogge

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Juliusz

On Tue, Aug 25, 2015 at 1:37 PM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

  Ted, I asked a question about a feature that is considered critical in
  every routing environment that I am familiar with.

 I think that we all have different pictures of what a homenet will look
 like.  Some of us appear to believe that homenets will predominantly
 consist of wired links with a few WiFi access points at the edges, while
 others (including myself) think that as soon as we give the hungry masses
 the ability to build self-configuring networks that are efficiently routed
 at layer 3, people will start building networks where wireless is used for
 transit.

 This is exciting stuff, Alia, more exciting than some of the contributors
 to this list seem to realise.


Absolutely on the exciting stuff and on the ability to make a real impact.
On the different pictures, I agree totally  that's why I'm poking a little
into
assumptions  requirements.


 Now the only goal of ECMP is to improve performance.  If the homenet uses
 only wired links for transit, then ECMP is easy to do, whether in IS-IS or
 in Babel.  If, however, the homenet is using multiple mutually interfering
 radio links for transit, then a naive implementation of ECMP will actually
 decrease performance due to interference (cross-link collisions).  Doing
 ECMP in the particular case of non-interfering paths (e.g. wired paths)
 should be safe, and the radio interference extension to Babel should
 already carry all the required information.

 Thankfully, ECMP does not have to be a Homenet requirement -- if the ECMP
 extension is backwards compatible (and there's no reason why that
 shouldn't be the case), then we can simply leave it as an implementation
 option, and let the market decide.

 I realise you're impatient to see ECMP in Homenet, Alia, but my main
 priorities right now are to satisfy the requirements of the IETF
 secretariate wrt. the Babel extension drafts (I've missed the IANA
 requirements in one of the drafts), getting shncpd into shape for
 integration into Debian, and helping with the Babel/Bird implementation --
 and teaching starts in two weeks!  Please give me a few months until
 things calm down a little.


Actually, I don't have a strong opinion on whether ECMP is needed in
homenet!
That's why I'm asking - but I'm hoping for technical reasons and trying to
understand
why the interference isn't a general problem.  Perhaps it's just because
for ECMP/multi-path,
there is a choice and trade-off to be examined as to the improvement.

I'm sure you are busy!

Regards,
Alia



 -- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Ted,

On Fri, Aug 21, 2015 at 12:19 AM, Ted Lemon mel...@fugue.com wrote:

 On Aug 11, 2015, at 7:25 PM, Alia Atlas akat...@gmail.com wrote:
  It sounds to me like using multiple paths (ECMP or otherwise) is
 something that hasn't been clearly nailed down in the requirements?

 Putting ECMP in the requirements seems like a terrible idea.   I don’t
 think there’s a need for it, for two reasons.   First, none of the
 applications you described actually require it.  Yes, you’d get better
 performance if they had it, so it would be a nice value-added feature.
  But it is not a base requirement for the homenet to function.   Second,
 did you read my description of the typical homenet user’s mental model of
 what a homenet looks like a week ago?   I think this is a key point: the
 end user has no idea what ECMP is, what its operational characteristics
 are, what links it might function over, etc.   So ECMP would have to
 self-configure, and that includes the sort of stuff Juliusz was talking
 about—noticing interfering versus non-interfering paths, etc.   This is a
 research project.   I think it would be great if homenet could do this work
 at some point in the future, but it is not something that should be part of
 the base requirements for the homenet, because if it were, it would delay
 availability of a complete homenet spec by years.


ECMP or downstream paths is not a research project; it is common used
technology.  When the traffic streams desired are larger than can fit
across a single path, it becomes critical.

Figuring out how to handle interfering vs. non-interfering paths is, I
think, orthogonal to ECMP.  The multiple links
that might interfere can easily be used for different destinations.  While
interesting, that seems like a problem that can needs
solving already.  Is that piece of the problem a research project?
Figuring out what links interfere?  Is this something that would need
a centralized view of the home network?

From a user's perspective, use of multiple paths would be transparent -
except that they'd see better performance through
their network.  There can be high-bandwidth demands like data backup or
streaming multiple high-def video.

Regards,
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Ted,

On Tue, Aug 25, 2015 at 12:43 PM, Ted Lemon mel...@fugue.com wrote:

 On Aug 25, 2015, at 11:46 AM, Alia Atlas akat...@gmail.com wrote:

 ECMP or downstream paths is not a research project; it is common used
 technology.  When the traffic streams desired are larger than can fit
 across a single path, it becomes critical.


 ECMP in a homenet environment, self-configuring and reliable, is a
 research project.

 Figuring out how to handle interfering vs. non-interfering paths is, I
 think, orthogonal to ECMP.  The multiple links
 that might interfere can easily be used for different destinations.  While
 interesting, that seems like a problem that can needs
 solving already.  Is that piece of the problem a research project?
 Figuring out what links interfere?  Is this something that would need
 a centralized view of the home network?


 This is not a problem that a typical end user needs solved.   You do not
 need ECMP for 4k Netflix.   You do not need ECMP to talk to your IoT
 devices.   You don’t even need ECMP to talk to your homenet file server, in
 the currently unlikely event that it’s not in the cloud (that is, in a rack
 in a data center outside the home).   ECMP might be _nice_ for the unlikely
 in-home file server case, but it is not _necessary_.   If you think it is,
 it’s probably because you are used to low-performance home routers with
 bufferbloat, a problem ECMP would not address, and likely would make worse.
   We’ve all experienced the home router that, when you try to do a massive
 file transfer between two devices, suddenly stops routing anything else
 until the transfer is finished.   This is not a problem that ECMP would fix.


It depends on link speeds in part.  My point was merely that this is a
default in link-state routing. It is self-configuring, of course. I was
asking to understand the requirements.


 What I consider to be a research project are:

 - Figuring out that links interfere


Is this merely the trade-off between using multiple links?  I normally
assume that some traffic is carried
across all links.  I am not sure why the concept of using multiple paths is
radically different than the basic
problem or why you feel it explodes the complexity?


 - Figuring out what set of links are candidates for ECMP for a particular
 pair of endpoints


In most routing protocols, this is trivial and done.  I do believe that
there is work to be done for Babel in
this space, if it is needed.


 - Handling unannounced topology changes


?? Isn't that what a routing protocol does - detects and distributes the
topology change?


 To me this is a classic case of premature optimization.   Of course
 ultimately we’d like this to work.   But it’s not even remotely something
 that we care about _right now_.   If we ship homenet devices that do not do
 ECMP, nobody will even notice.


Ted, I asked a question about a feature that is considered critical in
every routing environment that I am familiar with.
I find it frustrating that looking ahead to significantly more complex home
networking topologies and link types, which may be
many years out still, is unexceptional, but asking about a feature that
allows better use is described as premature optimization.
I am asking about a routing requirement.

I still am not clear on how link interference is handled for different
destinations.

Regards,
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Henning,

On Tue, Aug 25, 2015 at 1:50 PM, Henning Rogge hro...@gmail.com wrote:

 On Tue, Aug 25, 2015 at 7:38 PM, Alia Atlas akat...@gmail.com wrote:
  There is also the point that multipath choices tend not to be
  isometric... just because the two paths from your local point of view
  seem to be good they are not necessarily good from the point of view
  of the next hop.
 
 
  In a way that can't be captured by link metrics?  I haven't really
 looked at
  the unique characteristics for wireless.  I'm happy to do a bit of
  self-education.

 Imagine a network with three wireless routers (A,B,C)... A is the
 uplink, you are C, but both A and C can only see B.

 All routers are dualband routers (all have both a 2.4 GHz and a 5 GHz
 radio).

 From your (C) point of view the multipath-solution is easy, one path
 use 2.4 GHz (C to B to A), the other one uses 5 GHz (C to B to A).

 But when your IP packet arrives at B, B doesn't know it is part of a
 multipath stream... so forcing both streams to stay on their frequency
 is not trivial if you don't want to do source routing.


Ok - I was assuming that each router would hash and pick a next-hop for the
traffic.  So traffic that came in on a 2.4 GHz could go out the 5 GHz.
With consistent hashing, maybe one could force traffic to specific paths,
but that isn't usual for ECMP.


 There is a solution for this easy example (as Juliusz will certainly
 be able to tell you), but there are more complicated setups which are
 even more difficult.

 Multipath on wireless links is easy to mess up, so I would suggest NOT
 including it into the feature-set required by Homenet.


Ok.  Let me poke a bit more.  Is it safe to use parallel wireless links
between
two routers A and B?  Consider that there's a square topology, as below,
where E-F and
D-E are both wireless, and links have the same metric.  Can C safely send
traffic
to reach F via both D and E?  Can F safely send traffic to reach C via both
D and E?
How is this case different than if C were split into a C1 and a C2 so that
F-E-C1 and F-D-C2?

   [ C ]-[ D ]
 |   | w
 |   |
  [ E ] ---w--- [ F ]

Basically, I'm trying to understand the restrictions.

Thanks for your explanations!
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Alia Atlas]

Can we please remove ieee-ietf-co...@ietf.org from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a
good time to interact,
but I think this conversation is really not the point of that list.

It's already cc'd to mboned and homenet...

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert eck...@cisco.com wrote:

 On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert) wrote:
  Yes it is. IP over Foo must indicate if IP multicast over a link uses L2
 mechanisms or not.
 
  If not, a router learns from MLD the state it needs to figure to which
 devices it should copy a given packet.

 Well, the problem with WiFI is that L2 multicast  are useful under some
 conditions and not useful under others. And the conditions are more
 complex than boolean ;-)

  For Wi-Fi, there is no multicast support and it is sufficiently clear
 now that relying on broadcast is not a good idea.

 Pretty sure you don't mean that. If you would eliminate ALL multicast, you
 didn't have discovery of new devices.

  Rather, a good idea could be to build a multilink subnet with APs that
 are also routers to serve the wireless edge, whereby the Ethernet backbone
 can rely on L2 broadcast while the wireless edge is routed. Many LLNs work
 like this. Why should Wi-Fi be an exception?

 Thats why i asked what device model we need. Don't think i got an
 answer for that though. L3 homenet APs would be lovely. But will it
 be sufficient to ONLY support those theoretical devices in homenet ?

   Again, if if's IPs problem then if 802.11 would just clearly state
 that this is
   the case, then we have a way forward. I just hope 802.11 understand
 that
   it'll see a lot more unicast coming its way and be prepared to handle
 it.
 
  I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE
 to do an immensely scalable L2 multicast support so that Solicited Node
 Multicast appears so cool on a switched fabric? Does not seem to work
 either.

 Sure.

  The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo
 in general which would be my take. And then the IETF has to decide if it
 wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join
 the effort so we do the job right.

 Getting IPv6 link signaling work with WiFi sucking L2 multicast
 is just a bit of work in the L2 IPv6 protocols that can be done
 IMHO without botrhering IEEE. Getting streaming multicast work
 best requires more L2 awareness and it doesn't seem homenet
 is interested in thast anyhow, so i think we're only going to get
 a solution for the L2 IPv6 signaling piece realistically in the
 IETF alone.

 Cheers
 toerless

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] question: equal-cost multipath?

[Alia Atlas]

I am interested to learn what people think about whether equal-cost
multi-path routes are needed in homenet.  Given the previous discussion
about parallel wireless links - which I know I have in my house and can't
use - I've been wondering if these have been considered.

ECMP is critical in the data-center and backbone, but I'm interested in
seeing what the reasoning is as to why it isn't or is needed in the homenet
scenarios.

Thanks,
Alia

P.S. I do expect that any routing protocol can be made to do ECMP, of
course.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

[Alia Atlas]

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 may be
of interest in understanding some of the issues with IPv6 and wifi.

Regards,
Alia

On Tue, Aug 11, 2015 at 12:30 PM, Toerless Eckert eck...@cisco.com wrote:

 Sure...
 But don't look at me, i don't remember i added that Cc:, i added mboned
 ;-))

 On Tue, Aug 11, 2015 at 12:15:49PM -0400, Alia Atlas wrote:
  Can we please remove ieee-ietf-co...@ietf.org from this conversation?
  Once we as the IETF figure out what to write down and discuss, that'll
 be a
  good time to interact,
  but I think this conversation is really not the point of that list.
 
  It's already cc'd to mboned and homenet...
 
  Thanks,
  Alia
 
  On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert eck...@cisco.com
 wrote:
 
   On Mon, Aug 10, 2015 at 10:43:56AM +, Pascal Thubert (pthubert)
 wrote:
Yes it is. IP over Foo must indicate if IP multicast over a link
 uses L2
   mechanisms or not.
   
If not, a router learns from MLD the state it needs to figure to
 which
   devices it should copy a given packet.
  
   Well, the problem with WiFI is that L2 multicast  are useful under some
   conditions and not useful under others. And the conditions are more
   complex than boolean ;-)
  
For Wi-Fi, there is no multicast support and it is sufficiently clear
   now that relying on broadcast is not a good idea.
  
   Pretty sure you don't mean that. If you would eliminate ALL multicast,
 you
   didn't have discovery of new devices.
  
Rather, a good idea could be to build a multilink subnet with APs
 that
   are also routers to serve the wireless edge, whereby the Ethernet
 backbone
   can rely on L2 broadcast while the wireless edge is routed. Many LLNs
 work
   like this. Why should Wi-Fi be an exception?
  
   Thats why i asked what device model we need. Don't think i got an
   answer for that though. L3 homenet APs would be lovely. But will it
   be sufficient to ONLY support those theoretical devices in homenet ?
  
 Again, if if's IPs problem then if 802.11 would just clearly state
   that this is
 the case, then we have a way forward. I just hope 802.11 understand
   that
 it'll see a lot more unicast coming its way and be prepared to
 handle
   it.
   
I'd hate this, IEEE telling IETF what to do. Just like IETF telling
 IEEE
   to do an immensely scalable L2 multicast support so that Solicited Node
   Multicast appears so cool on a switched fabric? Does not seem to work
   either.
  
   Sure.
  
The IETF has to decide if it wants to design IP over 802.11 - or
 Wi-Foo
   in general which would be my take. And then the IETF has to decide if
 it
   wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may
 join
   the effort so we do the job right.
  
   Getting IPv6 link signaling work with WiFi sucking L2 multicast
   is just a bit of work in the L2 IPv6 protocols that can be done
   IMHO without botrhering IEEE. Getting streaming multicast work
   best requires more L2 awareness and it doesn't seem homenet
   is interested in thast anyhow, so i think we're only going to get
   a solution for the L2 IPv6 signaling piece realistically in the
   IETF alone.
  
   Cheers
   toerless
  
   ___
   homenet mailing list
   homenet@ietf.org
   https://www.ietf.org/mailman/listinfo/homenet
  

 --
 ---
 Toerless Eckert, eck...@cisco.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Michael, Juliusz,  Pascal,

Thanks for your thoughts.   I understand about the different upstream
providers.  However,  inside the home, if there are multiple paths, I can
also picture it being useful to use them (backups to a NAS, multiple video
streams, etc).

Whether they are simply equal-cost or unequal but safe to use paths is an
interesting detail,  but I think the main point is whether parallel paths
will be supported.

The concerns about wifi links interfering with each other is interesting.
I wonder if that is always a local decision for one end of the links or
whether a link from A to B and one from C to D would need to be
coordinated?  I'm tempted to want a nice abstraction layer, but I also
sense that it isn't quite that simple.

It sounds to me like using multiple paths (ECMP or otherwise) is something
that hasn't been clearly nailed down in the requirements?

Regards,
Alia
On Aug 11, 2015 5:54 PM, Michael Richardson mcr+i...@sandelman.ca wrote:


 I don't think that ECMP is useful/interesting *within* the Homenet.

 It is certainly true that having two DSL links bonded is regularly done
 (usually using MPPP), but that presents as a single link.  Some will want
 two
 CPE routers for reasons of redundancy on their multi-path uplink. My
 opinion
 is that we are rapidly getting to professional managed networks here,
 even
 if the professional the ISP or the very sophisticated home-based IT worker.

 Being able to identify backup links and rapidly swing traffic is important,
 but I think that all the protocols can do that.

 I think that MPTCP is more likely to bring significant benefit to
 applications that need to leverage multiple ISPs.

 --
 Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
  -= IPv6 IoT consulting =-




 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] question: equal-cost multipath?

[Alia Atlas]

Hi Lorenzo,

On Tue, Aug 11, 2015 at 8:47 PM, Lorenzo Colitti lore...@google.com wrote:

 On Wed, Aug 12, 2015 at 2:47 AM, Alia Atlas akat...@gmail.com wrote:

 ECMP is critical in the data-center and backbone, but I'm interested in
 seeing what the reasoning is as to why it isn't or is needed in the homenet
 scenarios.


 ECMP is critical in the datacenter and backbone because those networks are
 designed to provide the E (equal) in ECMP. Because the links are equal,
 it's easy to load-balance over them without needing to do complicated stuff
 like traffic engineering - you just treat an N-way ECMP bundle as a link N
 times bigger, and hash across it. That does not happen in home networks,
 which are more grown than designed.


ECMP applies beyond link bundles.  Of course, equal-cost can be hard to do
- and one can safely use downstream paths.  The relevant question is
whether traffic is expected to be able to take multiple paths to allow
load-balancing.



 Having a homenet load-balance Internet-bound across multiple provides is a
 non-starter because it is presumed that said providers will employ BCP38
 filtering. It's possible for the *hosts* to load-balance across different
 providers by simply sending their packets with different source addresses
 (and, in some cases, different routers).


Yes, of course if one is doing src-dest routing, the multiple paths would
have to be valid for the route.

Regards,
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New work in other SDOs [was Despair]

[Alia Atlas]

new-w...@ietf.org is alive  used for coordination and information.  We
also coordinate specifically with the IEEE on items of mutual interest
several times a year.
On Aug 7, 2015 12:13 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:

 On 08/08/2015 02:44, Weil, Jason wrote:
  Are you suggesting that IEEE and IETF send liaison letters to each other
  when they begin crafting new protocols?

 Actually such a mechanism has existed for 15 years or so: the infamous
 new-w...@ietf.org list, which I invented. It's a closed list (at this
 point I forget why, but I imagine some SDOs have a complex about it)
 populated by various liaisons. The theory was for SDOs to notify each
 other about possibly overlapping new work in a more simple way than a
 formal liaison statement. Because it's closed, I have no idea whether
 there's any recent traffic.

  This could possibly be useful
  assuming anyone acted on it. The more likely scenario is for each SDO to
  send an liaison saying ³Hey we just spent x years designing our new
  protocol y, please take a look and see if your protocols both past and
  present will function efficiently over it.²

 ... with a P.S. apologising for having forgotten to mention it x years
 ago on the new-work list. Yes, that's exactly what has happened before
 now.

 Brian

 
  In my experience there seems to be very little overlap between engineers
  working in the IEEE and those working in the IETF. My company for example
  has exactly zero overlap. IPv6 Multicast over IEEE 802.11 seems to be a
  good example of how more interaction would be immensely useful early on
 in
  the protocol development process. I¹m not sure there is a fix here, but
 it
  would definitely be useful for both SDOs to keep in mind each others
  protocols for interoperability purposes instead of just pointing to the
  other to fix their protocols.
 
  Customers
 
  Jason
 
  On 8/7/15, 2:21 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 
  On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:
 
  It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet
  and
  then complain to IEEE that in fact it is not.
 
  This is an interesting viewpoint. IETF isn't using wifi as if it was
  Ethernet. The customers who buy Wifi products buy it and run IP over
 it,
  expecting it should work (because that's what the advertising says). IP
  has been designed for wired ethernet (and Wifi carries ethernet frames).
  As far as I can tell, 802.11 never told the IETF that it wouldn't
 support
  multicast (really).
 
  I'd say IETF isn't saying IP works great over Wifi (it doesn't really
  make any claims for any L1 or L2). However, I see producers of Wifi
  equipment saying that their products are great for using to connect to
  the
  Internet, which is saying Wifi is great for IP.
 
  IPv6 over Ethernet makes heavy use of multicast over Ethernet, which
  for
  the lack of a highly scalable Multicast service always ends up
  broadcasted over the whole fabric.
 
  When Wi-Fi is confused with Ethernet and the whole multi link becomes a
  single layer 2 fabric, we create a crisis that will not be solved by
  imputing the responsibility on the other SDO.
 
  Which is exactly why I said that both SDOs need to do something.
 However,
  since IP was first I think that 802.11 should have come to IETF a long
  time ago and said that it couldn't do multicast. Basically, what I
  interpret you're saying is that Wifi in its current form isn't suited to
  carry IP the way IP has been designed, for a long time. That would be
  news
  for a lot of people.
 
  My suggestion is to finally recognize that Wi-Fi is not Ethernet, in
  particular from the perspective of multicast, and provide the
  appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone
  router discussed above is one candidate solution.
 
  It's not only IPv6, but it's also IPv4 (since it uses broadcast, but
 less
  of it).
 
  But what I hear here is that your opinion is that 802.11 doesn't need to
  change, but the IETF needs to change for IP to work over Wifi. I'd
 really
  appreciate some kind of official agreement from each SDOs who should do
  what. If the long-term technical solution is that the IETF should change
  L3 to basically avoid broadcast and multicast, then that's fine, as long
  as this is agreed upon by both parties.
 
  However, I do think that 802.11 needs to point out to its members that
 if
  they don't implement assured multicast replication, IP doesn't work
  properly. Then they can decide what should be done in the short term,
  because changing IP will take quite a while.
 
  --
  Mikael Abrahamssonemail: swm...@swm.pp.se
 
  ___
  homenet mailing list
  homenet@ietf.org
  https://www.ietf.org/mailman/listinfo/homenet
 
 
  This E-mail and any of its attachments may contain Time Warner Cable
 proprietary information, which is privileged, confidential, or subject to
 copyright 

Re: [homenet] Despair

[Alia Atlas]

Hi Mikael,

On Wed, Aug 5, 2015 at 1:54 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:

 On Wed, 5 Aug 2015, Toerless Eckert (eckert) wrote:

 Still sucks to tweak a routing protocol design for a broken l2 design
 (only unicast reliability provided for).


 In November 2014 when I asked the IETF upper brass and the IEEE liasion
 to tell IEEE that they need to make multicast and broadcast work on wifi
 because most L3 protocols rely on it, including IPv4 and IPv6.



 I don't know what happened after that, I didn't hear anything back. I
 asked multiple times.


This is the first I've heard of your personal concern.  However, the need
to have multicast protocols work
better did come up when we recently rechartered PIM.  That turned into
4) Optimization approaches for IGMP and MLD to adapt to link conditions in
wireless and mobile networks and be more robust to packet loss.

There is a draft that I noticed was recently
published
https://datatracker.ietf.org/doc/draft-mcbride-mboned-wifi-mcast-problem-statement/

I think that the issues need to be clearly articulated to hand work over to
IEEE.

Regards,


 I pinged them again just now, replying to the previous ping email on
 this issue from March 2015.

 --
 Mikael Abrahamssonemail: swm...@swm.pp.se

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Alia Atlas' No Objection on draft-ietf-homenet-prefix-assignment-07: (with COMMENT)

[Alia Atlas]

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-prefix-assignment-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/



--
COMMENT:
--

I agree with Alvaro and Brian on the need to clarify topology changes. 
In Sec 3, I see
   The algorithm supports dynamically changing topologies:

   o  Nodes may join or leave the set of participating Nodes.

   o  Nodes may join or leave Links.

   o  Links may be joined or split.

and what isn't clearly stated is that when a link fails (partially or
fully) or comes into existence ,
is that a topology change?

For instance, if a link fails, surely that shouldn't be a topology change
for the prefix assignment,
but rather a matter for routing to handle.  I do see in Sec 4.3 When a
Link is removed, all Assigned Prefixes
assigned to that Link MUST be destroyed.  Perhaps a link removal isn't
considered a topology change in this
context because it doesn't cause renumbering??

How is a new Link added to be considered?  How does a router know that
its end of a link is the
same link as on another router?  How is a link removed versus merely
down?

An assumption seems to be that the flooding mechanism can work without
any prefix numbering.  That's fine but
would be good to state.  I'm a bit twitchy about the bootstrapping.


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] RtgDir review: draft-ietf-homenet-dncp-07.txt

[Alia Atlas]

Les,

Thanks very much for your  review.

Alia

On Tue, Jul 7, 2015 at 1:25 AM, Les Ginsberg (ginsberg) ginsb...@cisco.com
wrote:

  Hello,

  I have been selected as a Routing Directorate reviewer for this draft.
 The

 Routing Directorate seeks to review all routing or routing-related drafts
 as

 they pass through IETF last call and IESG review, and sometimes on special

 request. The purpose of the review is to provide assistance to the Routing
 ADs.

 For more information about the Routing Directorate, please see

 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

  Although these comments are primarily for the use of the Routing ADs,

 it would be helpful if you could consider them along with any other IETF

 Last Call comments that you receive, and strive to resolve them through

 discussion or by updating the draft.

  Document: draft-ietf-homenet-dncp-07

 Reviewer: Les Ginsberg

 Review Date: July 6, 2015

 IETF LC End Date: Seems to have already occurred??

 Intended Status: Standard



 Major Issues:



 My biggest concern is that the document - and its companion HNCP - are not

 yet mature enough to be doing last call. What is being defined here is a

 state synchronization protocol which is used within the context of a

 parent protocol (most interestingly a routing protocol for the homenet

 context) and which depends upon another configuration protocol

 (presumably HNCP) to fully define the behavior.



 Judging from the review comments provided by others (notably Thomas
 Clausen's

 detailed review) and the continued discussion on the mailing list it has
 not

 yet been demonstrated that the specification is clear enough and robust
 enough

 for implementations to meet all the requirements and interoperate.



 This is not to suggest that you are on the wrong track - but given the

 dependencies pushing this to last call seems - to put it politely -

 very ambitious. I would prefer to see more implementation experience
 before

 the document moves to a state where it is presumed to be complete.



 I still have some trouble calling this a protocol. This is more of a
 process -

 or part of a process - which comprises a routing protocol. The process
 defined

 here serves to support reliable distribution and synchronization of
 state

 in an efficient manner under a limited set of conditions. I don't want to

 quibble too much about the term protocol - but I would prefer something
 like:



 a generic set of procedures which - when supplemented by a specific
 profile -

 define a means of maintaining state synchronization



 Some specific comments on points in the draft follow.



 ***



 Section 2 Terminology



 The term neighbor is not defined - but used frequently in the document.

 The term peer is defined as:



 another DNCP node with which a DNCP node communicates using a particular

 local and remote endpoint pair.



 What I am used to is that the definition above for peer is usually

 associated with the term neighbor, whereas the term peer is more
 generic -

 it is associated with a node in the network which performs the same
 functions

 in the protocol - but is not necessarily a neighbor.



 Section 4.5 illustrates why I find this confusing as it says



 When receiving a Node Endpoint TLV... the remote node MUST be added as a
 peer

   on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created

   for it.



 ???



 ***



 Section 4.4 - final bullet on Page 11



o  Any other TLV: TLVs not recognized by the receiver MUST be

   silently ignored.



 Does ignore mean discard? (This is one traditional meaning)



 If so this seems inappropriate as it is part of the database sent by

 the node and therefore needs to be retained in order to keep a consistent

 database. Perhaps store but do not process is a more accurate behavioral

 description?



 

 Section 6.1 Keep-alives



 Here is another case where the confusion between peer and neighbor
 arises

 for me. I would expect that keep-alives are only used between neighbors -

 but the text here uses the term peer.



 Are keep alives sent in multicast-listener mode? From the text in 6.1.2
 and

 6.1.3 it seems no - but I am not certain.

  *

 Section 6.2 Support For Dense Broadcast Links



 If a node is in Multicast-listen+unicast mode does it bear any
 responsibility

 for publishing state data in the event the node with highest node
 identifier

 does not have the latest information? I presume yes - but the text does
 not

 discuss this point.



 Also, does multicast-listener mode affect the way neighbors are
 advertised?

 It seems not - so what you are preventing w multicast-listener mode is

 redundant state updates - but there is no change to the set of neighbors

 advertised (N*(N-1))?



 

 Section 6.3 Node Data Fragmentation



 The significance of the MTU limitation is network-wide i.e. a too large

 Node 

Re: [homenet] Homenet Design Team for Routing Protocol Selection

[Alia Atlas]

On Wed, Apr 8, 2015 at 11:18 AM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

  Russ White (lead)
  Margaret (Wasserman) Cullen
  Ralph Droms
  Philippe Klein
  Wes George
  Ross Callon

  we want the design team to be impartial

 I think only Margaret has a passing familiarity with Babel.  Since the
 team is impartial, I assume there's also at most one person familiar with
 IS-IS?


In this, you would be incorrect.  Russ White is also familiar with Babel.
That is
also - sorry - a false presentation of fairness which assumes that those on
the
design team will be biased and that it is reasonable and necessary to find
equal numbers of
people familiar with one of the most widely deployed IGPs and with an
interesting
protocol that has a niche deployment.

There is knowledge of multiple IGPs in the team - and as critically, an
impartiality
and willingness to listen and consider the requirements and how the
candidates compare.
What I think we needed on the design team is both impartiality,
understanding of homenet
use cases for deriving use-cases, understanding of different IGPs, and
understanding
how to select a routing protocol based upon requirements.

Regards,
Alia



 -- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Homenet Design Team for Routing Protocol Selection

[Alia Atlas]

Terry's email on April 6 confirmed that Homenet will use the approach
of having a Design Team to select the one mandatory-to-implement
routing protocol.   The charter for the design team, as sent in his email,
is below.

I am happy to also announce the membership of the design team with
many thanks to them for taking on this time-consuming and critical job.

Russ White (lead)
Margaret (Wasserman) Cullen
Ralph Droms
Philippe Klein
Wes George
Ross Callon

The design team has a private mailing list homenet-dt-rout...@ietf.org
for their internal communication.   The design team members are the
only ones on that mailing list.

Charter:

Homenet's architecture (RFC 7368) articulates the general features
required.  The working group has agreed that a single routing protocol
must be identified as mandatory to implement.  The final purpose of
this design team is to select and present a single routing protocol
with a summary of the necessary extensions and work to be the one that
is mandatory to implement.  Once the design team has made its
recommendation, the working group will consider any substantial
technical objections (see RFC 7282) as part of gaining consensus.

For the design team to make this determination, it shall first
understand the use-cases for homenet and derive routing requirements
from those.  Then it shall compare these routing requirements to
candidate routing protocols and examine the gaps in each.  For each
highly plausible candidate routing protocol, the design team will
estimate the work and actions needed, the resources at hand
or reasonably available, and the associated timeline to get
an acceptable, full, standardized solution using each protocol.
Based upon this information and the perceived market timing
needs of the technology, the design team will make its selection.
The requirements, gaps, and reasoning will be documented.

This document should be delivered by the July 2015 IETF.

Regards,
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Homenet Design Team for Routing Protocol Selection

[Alia Atlas]

Lorenzo,

On Wed, Apr 8, 2015 at 10:05 AM, Lorenzo Colitti lore...@google.com wrote:

 Alia,

 Russ White (lead)
 Margaret (Wasserman) Cullen
 Ralph Droms
 Philippe Klein
 Wes George
 Ross Callon


 Nowhere on that list do I see names that I recognize as being involved in
 current homenet implementations - or at least, in the implementations that
 seem most likely for selection.

 Is there a reason that none of those implementers were made part of the
 team? Was it done intentionally, out of concern that if they had been on
 the team, they would be partial to their own designs?


Yes - we want the design team to be impartial and make an informed
technical decision.  There were many others
that were considered but impartiality was a very important criteria.  It
does no good for the design team to recreate the extremely polarized
conversation that have happened in Homenet.

We did include Philippe as someone who is familiar with constrained
environments as well layer 2 considerations.

If not, then... well, how can the team make a useful decision if it has not
 been involved with the work so far?


It was done intentionally.  I believe that this design team has the
background and knowledge to assess requirements and compare against
candidate routing protocols.  The design team is most able to reach out to
others for questions and advice.

Regards,
Alia
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

[Alia Atlas]

Lorenzo,

On Fri, Apr 3, 2015 at 10:44 PM, Lorenzo Colitti lore...@google.com wrote:

 On Fri, Apr 3, 2015 at 12:04 AM, Alia Atlas akat...@gmail.com wrote:

 In the light of the above figures -- can I trust an IETF working group to
 understand that a huge amount of effort has been put into removing
 mechanisms from this protocol, and to respect that work?


 Yes, I think that the requirement for minimal mechanisms and a simple
 easy to implement and troubleshoot protocol can be clearly expressed.  How
 well the WG handles this depends in part on the WG chairs and how strongly
 the participants are reminded of that requirement and how stringently the
 need
 for truly active consensus is focused on.


 Alia - can we put something to that effect in the charter?


That is part of the scoping  chartering discussion.  It is a possible
outcome.  I'm
still gathering data (finally next week getting a bit more time to focus)
and listening
to opinions and concerns.
Figuring out the charter scope is part of asking for what are the
requirements and
applicability driving the obvious and deployed interest in Babel?


 There is a real risk that any WG working on standardizing babel will start
 proposing lots of changes to the protocol (due to NIH syndrome, general
 bikeshedding, etc.), alienating its author and leading to lost time and the
 usual failures of design-by-committee.


Usually, people are suggesting a change or feature because they need it for
a deployment or customer.  Sometimes,
there are just interesting ideas - but requiring implementations and
solid discussion usually make it clear what the
case is and how much applicability/scope creep there is.

Regards,
Alia

To avoid this, can we see to it that the charter of any group chartered to
 take babel to proposed standard status be chartered to do so without making
 substantial changes to the protocol mechanics?

 That way, if the protocol works well as is, we'll get a standard soon. If
 it doesn't, the WG can always throw up its hands and fail fast.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

[Alia Atlas]

Joel,

On Tue, Mar 31, 2015 at 12:02 PM, Joel M. Halpern j...@joelhalpern.com
wrote:

 Actually Ray, IETF process, as described by the IESG, happily allows for
 Downref with suitable approval and notice to the community.  So, as far as
 I can tell, homenet could indeed reference and mandate Babel in a Proposed
 Standard RFC.  I would agree that homenet choosing to do that would be a
 strong impetus for moving the document to Standards track. But that does
 not have to be gating.

 https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry


RFC 6126 is both experimental and through the ISE.  The experience with it
is not equivalent to that with standardized protocols.  As I said in
Dallas, if the mandatory-to-implement protocol for homenet is babel, it
will need to be standardized through the IETF consensus process.   Ideally,
with motivation, that would be quick.

Regards,
Alia




 Yours,
 Joel


 On 3/31/15 11:54 AM, Ray Bellis wrote:


  On 31 Mar 2015, at 16:35, Dave Taht dave.t...@gmail.com wrote:

 I don't see any point in starting up a new working group[1] whatsoever
 based on the events of the last ietf homenet meeting, particularly
 with the arrival of a new written from-spec version of babel in under
 15 hours, (which I am still chortling about. I am tempted to write one
 in rust).


 Whilst full standardisation of Babel may end up happening in a WG anyway,
 some of this design team's job will be to establish whether it's more
 expedient to bring Babel up to proposed standard levels of specification
 than to add Homenet-related features (per your list below) to existing IETF
 endorsed standards.

  It is just punting the question and more delay when stuff that is more
 than sufficiently stable is done, already, and shipping, with a 5 year
 long productization pipeline left to fill.


 For better or worse, IETF process dictates that we cannot use what is
 officially an _experimental_ protocol in a standards track document.
 Markus' work was very impressive, but not sufficient to overcome that
 hurdle.

 However this _should_ be a very short-lived punt - less than one IETF
 cycle.  The WG was unable to reach consensus over three full IETF cycles,
 and this structured design team approach _should_ clear this log jam.

  (If it helps any (which I doubt) I have never thought that homenet
 must settle on one routing protocol, and certainly the from the ISP
 part of the link is underspecified)

 At least one routing protocol must be available, however to turn back
 the tide of the current situation where none are commonly available in
 most consumer routing gear. More than one IS available.


 We are arguing on the choice of one _mandatory to implement_ protocol.
 For interoperability's sake, this will be the one that must be available.

 Nothing can (nor will) prevent additional protocols from being
 implemented, and perhaps even operate simultaneously.

  Aside from that my major two requirements have only been

 0) Must support source specific routing
 1) A homenet capable routing protocol MUST work well over wifi and
 wireless links in addition to conventional ethernet and other mac
 layers

 My minor requirements were:

 0) Binary and memory sizes must be small enough to fit into teeny routers
 1) should be wildly available in every off the shelf OS that might be
 used for routing
 2) should be extensively tested in environments ranging from homes, to
 battlemesh, to small business campus networks
 3) Should have a good spec, must have at least one open sourced and
 liberally licensed implementation


 These requirements are all very well understood.

  So to me, y'all are wasting time that could be better spent into A)
 pouring resources into making hnetd less the monster than it became,


 please elaborate (in a separate thread, please!)

  B) dogfooding what exists and C) developing better tests and D)
 developing better metrics

 PS However.

 [1] I would not mind a working group that took the outputs of the
 battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up
 against the outputs of the ietf working groups (like RPL, olsrv2, and
 others from manet and elsewhere) - and the IEEE (like all the layer 2
 isis stuff) and that wg BOTH tackled them in the working group AND in
 the real world - and worked to sort out the mess of academic code and
 real world requirements in the hope, that one day, maybe before I die
 of old age and/or apoplexy, the one true routing protocol and metrics
 emerged from the chaos.


 If enough people backed that and a suitable charter was agreed that could
 happen.

 kind regards,

 Ray

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

[Alia Atlas]

On Tue, Mar 31, 2015 at 12:58 PM, Joel M. Halpern j...@joelhalpern.com
wrote:

 As I read the rules, if Alia does not want to allow the downref, it can't
 happen.  But if she and the working group both want it, and the IETF last
 call accepts it, then it can happen.  This is an example of the rules
 allowing us to do what we as a community think is best.


As I said in the meeting, my concern is not because of the process
requirements - but because of the experience and improvements found during
the standardization and interoperability process.  Even the partial
implementation that was done brought up a couple different issues in either
documentation or code.

Regards,
Alia


 Yours,
 Joel

 On 3/31/15 12:25 PM, Margaret Wasserman wrote:


 Hi Joel,

 As I understand it, the downref policy is intended to allow references
 to Informational or Experimental documents in specific cases.  The page
 you referenced says:  Exceptions to this rule are sometimes needed as
 the IETF uses informational RFCs to describe non-IETF standards or
 IETF-specific modes of use of such standards.

 I don't think it is intended to allow a downref to a protocol defined in
 a non-IETF RFC.  Babel was published as an Independent Submission
 Experimental RFC.  We have already been told by at least one AD that
 they wouldn't approve that sort of downref, but that may not represent a
 final decision of the IESG.

 If this is something the Homenet WG may want to do (even though we
 didn't have consensus to do this during the meeting), would it be
 possible for us to get an answer from the IESG about whether they would
 approve this, as part of our selection process?

 Margaret


 On Mar 31, 2015, at 12:02 PM, Joel M. Halpern j...@joelhalpern.com
 mailto:j...@joelhalpern.com wrote:

  Actually Ray, IETF process, as described by the IESG, happily allows
 for Downref with suitable approval and notice to the community.  So,
 as far as I can tell, homenet could indeed reference and mandate Babel
 in a Proposed Standard RFC.  I would agree that homenet choosing to do
 that would be a strong impetus for moving the document to Standards
 track. But that does not have to be gating.

 https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

 Yours,
 Joel

 On 3/31/15 11:54 AM, Ray Bellis wrote:


  On 31 Mar 2015, at 16:35, Dave Taht dave.t...@gmail.com wrote:

 I don't see any point in starting up a new working group[1] whatsoever
 based on the events of the last ietf homenet meeting, particularly
 with the arrival of a new written from-spec version of babel in under
 15 hours, (which I am still chortling about. I am tempted to write one
 in rust).


 Whilst full standardisation of Babel may end up happening in a WG
 anyway, some of this design team's job will be to establish whether
 it's more expedient to bring Babel up to proposed standard levels
 of specification than to add Homenet-related features (per your list
 below) to existing IETF endorsed standards.

  It is just punting the question and more delay when stuff that is more
 than sufficiently stable is done, already, and shipping, with a 5 year
 long productization pipeline left to fill.


 For better or worse, IETF process dictates that we cannot use what is
 officially an _experimental_ protocol in a standards track document.
  Markus' work was very impressive, but not sufficient to overcome
 that hurdle.

 However this _should_ be a very short-lived punt - less than one IETF
 cycle.  The WG was unable to reach consensus over three full IETF
 cycles, and this structured design team approach _should_ clear this
 log jam.

  (If it helps any (which I doubt) I have never thought that homenet
 must settle on one routing protocol, and certainly the from the ISP
 part of the link is underspecified)

 At least one routing protocol must be available, however to turn back
 the tide of the current situation where none are commonly available in
 most consumer routing gear. More than one IS available.


 We are arguing on the choice of one _mandatory to implement_
 protocol.  For interoperability's sake, this will be the one that
 must be available.

 Nothing can (nor will) prevent additional protocols from being
 implemented, and perhaps even operate simultaneously.

  Aside from that my major two requirements have only been

 0) Must support source specific routing
 1) A homenet capable routing protocol MUST work well over wifi and
 wireless links in addition to conventional ethernet and other mac
 layers

 My minor requirements were:

 0) Binary and memory sizes must be small enough to fit into teeny
 routers
 1) should be wildly available in every off the shelf OS that might be
 used for routing
 2) should be extensively tested in environments ranging from homes, to
 battlemesh, to small business campus networks
 3) Should have a good spec, must have at least one open sourced and
 liberally licensed implementation


 These requirements are all very well understood.

  So to me, 

Re: [homenet] Selecting a routing protocol for HOMENET

[Alia Atlas]

Juliusz,

On Tue, Mar 31, 2015 at 11:56 AM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

  Then it shall compare these routing requirements to
  candidate routing protocols and examine the gaps in each.  For each
  highly plausible candidate routing protocol, the design team will
  estimate the work and actions needed, the resources at hand
  or reasonably available, and the associated timeline to get
  an acceptable, full, standardized solution using each protocol.

 I don't see the word proven or the words implementation experience.

 My (perhaps mistaken) feeling is that whenever I mention an important
 feature of Babel, there's a chorus of that could be done in IS-IS, we
 just haven't done it yet.  I've tried to explain that many of the things
 that Babel is doing are difficult or outright impossible[1] in IS-IS, but
 I don't feel like I've been heard.

 Can the charter please make sure that the design team will only consider
 features that have been implemented and proven to work?


The design team is considering the work to get an acceptable, full, and
standardized solution.  One aspect of that can be having multiple
interoperable
independent implementations.  That doesn't mean that everything has to be
implemented already but it should be clear that the work necessary is
engineering
and not research.

Regards,
Alia

-- Juliusz

 [1] Dijkstra, next-hop routing, non-distributive metric.  Pick any two,
 but you can't have all three.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Selecting a routing protocol for HOMENET

[Alia Atlas]

Markus,

On Thu, Mar 26, 2015 at 2:27 PM, Markus Stenberg markus.stenb...@iki.fi
wrote:

  On 26.3.2015, at 13.20, Terry Manderson terry.mander...@icann.org
 wrote:
  That is certainly not omitted, why do you think it would be?
  ..Specifically when we look at outputs from the routing area (and Alia
 can
  certainly speak for her own Area on this) two reference implementations
  are generally required. That same ideal was highlighted in the workgroup
  meeting. So that ethos is very much included.
 
  Are there any other comments in either the positive or negative
 direction?
  Please WG, speak up.

 I have my doubts that this will converge anywhere useful. Why are we
 trying to force exactly 1 routing protocol at any rate? It was all based on
 one hum in London(?) year ago, and it seems more and more like a bad idea
 given e.g. potential for diverse set of link technologies in future homes.


Different link technologies do not need to lead to different routing
protocols.  Different types of
interfaces can have very different logic.


 Also, if routing guys essentially make the decision, I would definitely
 love to hear what is _the best_ option, not just Babel  IS-IS choice from
 them knowing there is ISIS WG in RTG area, but not Babel one.


PLEASE reread the proposed design team charter.  It articulates the process
that would be followed in this homenet design team. Nowhere does it even
vaguely imply that the team would make a slam dunk answer based on a
superficial examination of implementations, standardization, and deployment.

We have spent quite some time figuring out the proper charter for the
design team to handle and articulate concerns.

Regards,
Alia



 Cheers,

 -Markus
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] T.M.S. proudly presents - Babel: the 2nd implementation

[Alia Atlas]

Julius,

On Thu, Mar 26, 2015 at 11:00 AM, Juliusz Chroboczek 
j...@pps.univ-paris-diderot.fr wrote:

  On Tuesday, there was much whining about single Babel
  implementation. Luckily T.M.S.[1] to the rescue - ~15 hours after start,
  routes synchronized unidirectionally, and after fixing bug or two this
  morning they go both ways, loop-free, etc. So I would argue I have
  implemented RFC6126 (aka Babel).

 Markus, I'm impressed -- I was estimating it would take you a week, not
 15 hours.

 Matthieu and I refrained from communicating with Markus while he was
 working on that -- we didn't want to give him any hints.  Alia, Ted, am
 I allowed to discuss implementation details with Markus, or would that no
 longer count as independent implementation?


What I'd recommend is keeping track of questions and issues - so you can do
errata
or think about what a bis draft would look like.

People do - of course - talk, but the goal is to have a document that
covers all
the details enough.

Regards,
Alia


 -- Juliusz






___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] actual requirements for standardization of an ietf protocol?

[Alia Atlas]

In the Routing Area, it depends upon the WG as to whether 2 interoperable
implementations are required.   This is always the case in,  for example ,
IDR.  For a new routing protocol,  I think it would be appropriate to be
comfortable that others can implement it and it works well.

Regards,
Alia
On Mar 25, 2015 7:43 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:

  1) I don't know where the 2 separate implementation concept is
  embedded formally in the ietf structures for approval.

 It isn't, for Proposed Standard status, although historically the
 Routing Area has been tougher than the rest of the IETF because of
 reasonable concern that a faulty routing protocol can produce more
 horrible failure modes than pretty much anything else.

 http://tools.ietf.org/html/rfc4794 may clarify a bit.

 For advancement to Internet Standard there is a requirement
 for 2 implementations but that is not germane to the current
 discussion. (http://tools.ietf.org/html/rfc6410)

 Sigh. It's embarassing how baroque the IETF process documents
 have become, but it would be a lot of uninspiring work to
 clean them up. That's why I've been maintaining this page for
 a few years now: http://www.ietf.org/about/process-docs.html
 (And yes, I'm aware it's overdue for an update.)

   Brian

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet