Subject: RE: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Nov 2013 15:49:38 +0000

Hi Erik and all:

Considering that the device access link may be wireless or that the device may be operating on batteries, whatever we can do in the infrastructure would be welcome.
The Wireless ND SAIL draft allows to propagate a registration up a hierarchy of registrars in a mapping system. We could leverage this to implement option 1 between siblings.
Both drafts will be discussed this morning.

Cheers,

Pascal

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: lundi 4 novembre 2013 16:42
To: Mark ZZZ Smith; Samita Chakrabarti; [email-masked]; [email-masked]
Cc: Erik Nordmark ([email-masked]); Pascal Thubert (pthubert)
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

> 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.

Good point - the VRRP case hasn't been worked through.

For the non-VRRP case of multiple routers the hosts will see that there are multiple and register with each one of them. But in the case of VRRP it looks to the host as a single router.

I can see three different ways to ensure that NEARs using VRRP can maintain all the registrations:
1. A state checkpointing/synchronization protocol between the VRRP NEARs 2. Making the hosts aware that they need to register at two different NEAR addresses 2a. A bit of a hack would be to, in addition for the RA from the virtual address, have the physical routers send a RA (with the E bit set) with the lowest possible preference.
2b. Explicitly sending the additional registration addresses in a new RA option.

AFAIK there aren't IETF standard protocols for checkpointing, thus #1 would potentially be a lot of work. And it would make the VRRP case quite different than the case of multiple NEARs not using VRRP.

Hence I'd be inclined to define the "additional registration addresses" 
option.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 04 Nov 2013 07:59:09 -0800

> Both drafts will be discussed this morning.

I don't know to what extent VRRP would be used in a wireless case. In a 
case of e.g., 802.11 the device sees a single point of failure in the 
form of the AP.

But allowing a VRRP pair of NEARs to synchronize their registration 
state isn't something that we have to preclude - my observation is that 
we don't have IETF standard protocols which ensure (eventually) 
consistent state in two devices.
The SAIL propagation, as I understand it, is more of a best effort 
approach with a fallback to rely on multicast NS on the backbone link. 
Such a best effort approach is fine in the SAIL context AFAICT, but 
wouldn't help the VRRP case.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 04 Nov 2013 07:42:04 -0800

For the non-VRRP case of multiple routers the hosts will see that there 
are multiple and register with each one of them. But in the case of VRRP 
it looks to the host as a single router.

I can see three different ways to ensure that NEARs using VRRP can 
maintain all the registrations:
1. A state checkpointing/synchronization protocol between the VRRP NEARs
2. Making the hosts aware that they need to register at two different 
NEAR addresses
2a. A bit of a hack would be to, in addition for the RA from the virtual 
address, have the physical routers send a RA (with the E bit set) with 
the lowest possible preference.
2b. Explicitly sending the additional registration addresses in a new RA 
option.

AFAIK there aren't IETF standard protocols for checkpointing, thus #1 
would potentially be a lot of work. And it would make the VRRP case 
quite different than the case of multiple NEARs not using VRRP.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Nov 2013 18:11:40 +0000

Hello Erik:

The wireless link fixes itself with re-association to an alternate AP and doing so they would probably reregister.
The problem that I see here is if the change of NEAR with an VRRP group happens transparently to the device, do we agree?

Pascal

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: lundi 4 novembre 2013 07:59
To: Pascal Thubert (pthubert); Mark ZZZ Smith; Samita Chakrabarti; [email-masked]; [email-masked]
Cc: Erik Nordmark ([email-masked])
Subject: Re: draft-chakrabarti-nordmark-6man-efficient-nd-02 submitted

> Both drafts will be discussed this morning.

I don't know to what extent VRRP would be used in a wireless case. In a case of e.g., 802.11 the device sees a single point of failure in the form of the AP.

But allowing a VRRP pair of NEARs to synchronize their registration state isn't something that we have to preclude - my observation is that we don't have IETF standard protocols which ensure (eventually) consistent state in two devices.
The SAIL propagation, as I understand it, is more of a best effort approach with a fallback to rely on multicast NS on the backbone link. 
Such a best effort approach is fine in the SAIL context AFAICT, but wouldn't help the VRRP case.

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 04 Nov 2013 13:31:15 -0800

On 11/4/13 10:11 AM, Pascal Thubert (pthubert) wrote:> Hello Erik:
 >
 > The wireless link fixes itself with re-association to an alternate AP 
and doing so they would probably reregister.
 > The problem that I see here is if the change of NEAR with an VRRP 
group happens transparently to the device, do we agree?

Pascal,

My though it is that a EAH would register (and maintain registration) 
with all the NEAR physical routers which are part of the virtual router. 
That requires that the EAH finds out about about the physical routers 
(in the form of additional registration addresses).

Thus when there is a VRRP failover there is nothing that the EAH would 
need to do; the registrations are already in the new active physical router.

In that model when configuring VRRP on a NEAR router it would make sense 
to also enable sending this new "additional registration addresses" 
option in the RAs. However, if the VRRP group of NEARs has some other 
way to synchronize their state, then they can use that and not send this 
new option in the RAs.

Regards,
    Erik

 >> Considering that the device access link may be wireless or that the 
device may be operating on batteries, whatever we can do in the 
infrastructure would be welcome.
 >> The Wireless ND SAIL draft allows to propagate a registration up a 
hierarchy of registrars in a mapping system. We could leverage this to 
implement option 1 between siblings.
 > I don't know to what extent VRRP would be used in a wireless case. In 
a case of e.g., 802.11 the device sees a single point of failure in the 
form of the AP.
 >>> 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.
 >> For the non-VRRP case of multiple routers the hosts will see that 
there are multiple and register with each one of them. But in the case 
of VRRP it looks to the host as a single router.
maintain all the registrations:
 >> 1. A state checkpointing/synchronization protocol between the VRRP 
NEARs 2. Making the hosts aware that they need to register at two 
different NEAR addresses 2a. A bit of a hack would be to, in addition 
for the RA from the virtual address, have the physical routers send a RA 
(with the E bit set) with the lowest possible preference.
 >> AFAIK there aren't IETF standard protocols for checkpointing, thus 
#1 would potentially be a lot of work. And it would make the VRRP case 
quite different than the case of multiple NEARs not using VRRP.