Subject: Re: [6lo] draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 21 Aug 2013 13:55:42 -0700 (PDT)

Hi,

I haven't had a chance to do a thorough read though, however I haven't been able to find where the following scenarios is dealt with. 

In a pure energy efficient scenario, say there are two NEAR routers on the link (NEAR1, NEAR2). An EAH host (EAH1) at bootstrap chooses NEAR1, registers its addresses and uses NEAR1 as its egress router for off-link traffic. For the return traffic (i.e, off-link traffic coming onto the energy efficient segment), what occurs if the upstream network chooses to use NEAR2 to try to forward traffic to EAH1, as the upstream network considers NEAR2 rather than NEAR1 to be closer to EAH1 e.g, because of a smaller IGP metric, or the traffic source link is directly attached to NEAR2?

In my understanding, NEAR2 wouldn't have knowledge of EAH1, because EAH1 has only been registered with NEAR1. So it would seem that currently the only choice is for NEAR2 to drop those packets.

Further to this two or more NEAR scenario, even if the upstream network always considers NEAR1 to be the closer to the EAHs, if the NEARs are protected by a redundancy protocol such as VRRP, when VRRP switches from using NEAR1 to NEAR2, how does NEAR2 acquire address registration information? Would it be considered a EAH bootstrap event, so that all of the EAHs have to go through selection and then registration of a NEAR? While I think that would work, it would seem to be defeating the purpose of having a redundancy protocol like VRRP which tries to make switching over between routers nearly if not ideally transparent to downstream hosts.

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Aug 2013 11:01:47 +0000

Hello Mark:

There is a need for a protocol between the 6LBRs/NEAR routers to exchange their state.
This could be achieved by an extension on ND for proxy operations as described in dratf-thubert-6lowpan-backbone-router, a similar extension to a routing protocol running on the backbone or a richer extension to IPv6 NDP allowing some degree of pub/sub as well.

We are in the process of writing a personal submission describing the latter, I hope we can publish soon.

Cheers, 

Pascal

-----Original Message-----
From: Mark ZZZ Smith [mailto:[email-masked]] 
Sent: mercredi 21 août 2013 22:56
To: Samita Chakrabarti; [email-masked]; [email-masked]
Cc: Erik Nordmark ([email-masked]); Pascal Thubert (pthubert)
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

Hi,

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 25 Aug 2013 20:37:09 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > There is a need for a protocol between the 6LBRs/NEAR routers to
    > exchange their state.  This could be achieved by an extension on ND for
    > proxy operations as described in dratf-thubert-6lowpan-backbone-router,
    > a similar extension to a routing protocol running on the backbone or a
    > richer extension to IPv6 NDP allowing some degree of pub/sub as well.

Are the wired part of the 6LBRs always located on the same link?
I'm asking because it seems like this is an important assumption.
I read 6lowpan-backbone-router-03.
Please number the figure in section 3. I'll call it "Figure Plan Network"

I don't like the term backbone, and backbone router.
What I see are three areas of a DAG connected by a heterogeneous layer-2.
The "BBR" are just RPL routers.  I don't know why a new protocol is
necessary for the mesh-over case. 

Perhaps the MESH-under case has some requirements, but I'd rather just
pretend that it's four links (an ethernet link, and three mesh-under links)
connected together to form a single mesh-over network.

It seems to me that you are inventing a protocol to solve the MESH-under
problem, but that we already have such a protocol.

-- 
Michael Richardson
-at the cottage-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Aug 2013 13:25:16 +0000

Hello Michael:

The BBR draft will be repositioned as a number of functions are migrated to other drafts, including efficient ND.
What will be left in the BBr draft is probably the function by a RPL root (LBR) to proxy ND over the backbone so as to attract traffic for IPv6 addresses that are located on the LLN.
So it is not just a root. The key piece is the mapping (redistribution?) of RPL routes learnt from DAO into a Binding Table state in order to enable ND proxy operation.

>  Are the wired part of the 6LBRs always located on the same link?
Yes. This is why we call this link the backbone. It is expected to be a transit link where traditional NDP operates. Backbone Router is the term used by ISA100.11a to refer to the routing entity that federates multiple LLNs as a single subnet over a high speed backbone. I'm using that same term to ease communication between ISA and IETF.

> It seems to me that you are inventing a protocol to solve the MESH-under problem, but that we already have such a protocol.
The backbone router does not operate mesh routing at all. It is really focused on ND proxy operation over a transit link we use as federating backbone for a multilink subnet.

Cheers, 

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: lundi 26 août 2013 02:37
To: [email-masked]; [email-masked]
Subject: [6lo] 6lowpan-backbone-router-03

I don't like the term backbone, and backbone router.
What I see are three areas of a DAG connected by a heterogeneous layer-2.
The "BBR" are just RPL routers.  I don't know why a new protocol is necessary for the mesh-over case. 

Perhaps the MESH-under case has some requirements, but I'd rather just pretend that it's four links (an ethernet link, and three mesh-under links) connected together to form a single mesh-over network.

It seems to me that you are inventing a protocol to solve the MESH-under problem, but that we already have such a protocol.

--
Michael Richardson
-at the cottage-

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 30 Aug 2013 02:09:50 +0000

Hi Mark,

Thanks for the interesting usecase example. Please see in-line. 

-----Original Message-----
From: Mark ZZZ Smith [mailto:[email-masked]] 
Sent: Wednesday, August 21, 2013 1:56 PM
To: Samita Chakrabarti; [email-masked]; [email-masked]
Cc: Erik Nordmark ([email-masked]); [email-masked]
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

Hi,

===> You are right. The document does not clearly handles this case.  However implicitly, an EAH can register with multiple routers in the network. But in order to add router policies ( in this case NEAR1 forwards northbound-only, NEAR2 forwards southbound only)  and synchronize that with EAH, it needs some more work [ perhaps some additional option with the registration]. Pascal has indicated the backbone router draft function.
This document tries to be generic and provides hooks for further enhancement for constrained nodes running IPv6.

===> Please see above.

===> We have not thought about interaction with VRRP. Good point.  We should discuss that off-line to  understand the scenario and its applicability in this document.

Best regards,
-Samita