Subject: [Softwires] Provisioning Hub-and-spoke in MAP - How?

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 11:37:30 +0200

Hello, all,

We have heard many times that MAP is completely specified, and has been extensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been identified (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html).

This mail is just about ONE of these, the hub-and-spoke issue.
It has been discussed several times but AFAIK still without a complete answer.

The difficulty is that:
- The MAP-DHCPv6 draft has no parameter to indicate whether the ISP-chosen topology is mesh or hub-and-spoke.
- According to the MAP-address-and-port draft, "each MAP node in the domain has the same set of rules".
- As answered in the mail below, the choice "needs to be provisioned. either explicitly or implicitly (via the rules)".

Questions I have are then:
- Is the choice provisioned explicitly, implicitly, or possibly both?
- How?
- Which tests have confirmed that it worked?

Answer by any one who asserts he or she understands how MAP works will be welcome.

Thanks,
RD

> De : Ole Trøan <[email-masked]>
> Date : 2012-03-14 14:29
> À : Rémi Després <[email-masked]>
> Cc : Tomasz Mrugalski <[email-masked]>, Softwires WG <[email-masked]>
> Objet : Rép : [Softwires] Question about hub-and-spoke operation in MAP
> 
> Remi,
> 
>> I couldn't figure out by how CEs can be required to work hub-and-spoke without some DHCPv6 indication:
>> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how do they know whether their ISP expects direct paths between them (mesh) or BR hairpinning (hub-and-spoke)?
>> 
> 
> that's correct it needs to be provisioned. either explicitly or implicitly (via the rules).
> 
> cheers,
> Ole

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 11:51:46 +0200

Remi,

you're apparently confusing matters. There is no need to have a DHCPv6
option, or a million node deployment to test MAP implementations. DS-lite
is a good example, with implementations and standards track before the
DHCPv6 option.

Needless to say, if you're implying that tests of MAP without testing the
standards based DHCPv6 option are insufficient, then any test of 4rd-u or
anything for that matter without using the fully standards DHCP option
would be equally flawed.
At the very least however, MAP does not need to prove on thing:
Compatibility with IPv6, which 4rd-u would need to.

-Woj.

On 10 April 2012 11:37, Rémi Després <[email-masked]> wrote:

> - several missing points of the MAP-T+E specification have been identified
> (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html).
>
> - As answered in the mail below, the choice "needs to be provisioned.
> either explicitly or implicitly (via the rules)".
>
> >> - If two CEs apply the same BMR to their delegated IPv6 prefixes, how
> do they know whether their ISP expects direct paths between them (mesh) or
> BR hairpinning (hub-and-spoke)?
> >>
> >
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 12:01:23 +0200

Wojciech,

This isn't answers to questions I asked.
They remain open.

RD

Le 2012-04-10 à 11:51, Wojciech Dec a écrit :

> Remi,
> 
> you're apparently confusing matters. There is no need to have a DHCPv6 option, or a million node deployment to test MAP implementations. DS-lite is a good example, with implementations and standards track before the DHCPv6 option.
> 
> Needless to say, if you're implying that tests of MAP without testing the standards based DHCPv6 option are insufficient, then any test of 4rd-u or anything for that matter without using the fully standards DHCP option would be equally flawed. 
> At the very least however, MAP does not need to prove on thing: Compatibility with IPv6, which 4rd-u would need to.
> 
> -Woj.
>

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 12:07:50 +0200

The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI
based configuration including scripting was applied.

Question closed.

-Woj.

On 10 April 2012 12:01, Rémi Després <[email-masked]> wrote:

>> - several missing points of the MAP-T+E specification have been
>> identified (ref (*)
>> www.ietf.org/mail-archive/web/softwires/current/msg04049.html).
>>
>> - The MAP-DHCPv6 draft has no parameter to indicate whether the
>> ISP-chosen topology is mesh or hub-and-spoke.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Apr 2012 13:52:32 +0200

On 10.04.2012 11:51, Wojciech Dec wrote:
> option, or a million node deployment to test MAP implementations.
> DS-lite is a good example, with implementations and standards track
> before the DHCPv6 option.

> On 10 April 2012 11:37, Rémi Després <[email-masked]
> <mailto:[email-masked]>> wrote:
>     The difficulty is that:
Guys,
Please be reasonable. DHCP provisioning is trivial compared to other
MAP/4rd-U aspects. It is not relevant for core aspects of the technology
comparisons. My advice to people who spend their time on "my solution is
better than yours" discussions: Forget about DHCP for now and focus on
more important aspects.

My personal opinion is that DHCP does not matter at this stage. Sure, it
will be needed eventually, but you can *now* test implementations that
are statically configured.

Now, to the actual question about hub&spoke. We assumed that CE can
detect on its own if it is running in hub&spoke or mesh topology by
analyzing received rules. See last paragraph of section 4.2 of
mdt-softwire-map-dhcp-option that explain this simple algorithm (if it
can be called an algorithm at all - it is a simple "if" statement).

Honestly speaking as a co-author of MAP DHCP option draft, I didn't want
to spend too much time on this *yet*. That is also one of the reasons
why I didn't look at 4rd-U DHCP option yet. It changes too greatly
between revisions.

Cheers,
Tomek

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 14:51:58 +0200

Le 2012-04-10 à 12:07, Wojciech Dec a écrit :

> The pre-standard-still-being-defined DHCPv6 option was not tested, and CLI based configuration including scripting was applied.
> 

> Question closed.

For you, that's your choice, fair enough.

But not closed for the WG: members deserve to know how CEs are proposed to know whether they must work in mesh or hub-an-spoke topology (even if MAP remains experimental).

RD

---

From: John E Drake <[email-masked]>
Date: Tue, 10 Apr 2012 06:15:11 -0700

Remi,

As an observer, it seems as though you think you are running the WG rather than being a participant in it.

Thanks,

John

Sent from my iPhone

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Tuesday, April 10, 2012 5:52 AM
To: Wojciech Dec
Cc: Softwires WG; [email-masked]; Softwire Chairs
Subject: Re: [Softwires] Provisioning Hub-and-spoke in MAP - How?

Question closed.

RD

-Woj.
On 10 April 2012 12:01, Rémi Després <[email-masked]<mailto:[email-masked]>> wrote:
Wojciech,

RD

Remi,

-Woj.
On 10 April 2012 11:37, Rémi Després <[email-masked]<mailto:[email-masked]>> wrote:
Hello, all,

We have heard many times that MAP is completely specified, and has been extensively tested.
Yet:
- mapping rules of tested configurations have not been provided
- several missing points of the MAP-T+E specification have been identified (ref (*) www.ietf.org/mail-archive/web/softwires/current/msg04049.html<http://www.ietf.org/mail-archive/web/softwires/current/msg04049.html>).

The difficulty is that:

Thanks,
RD

> De : Ole Trøan <[email-masked]<mailto:[email-masked]>>
> Date : 2012-03-14 14:29
> À : Rémi Després <[email-masked]<mailto:[email-masked]>>
> Cc : Tomasz Mrugalski <[email-masked]<mailto:[email-masked]>>, Softwires WG <[email-masked]<mailto:[email-masked]>>

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 15:33:41 +0200

John,

> As an observer, it seems as though you think you are running the WG rather than being a participant in it.

Be sure I am far too realistic to believe that!

But I did invest lot of time and energy to build what a number of people find a good proposal. 
Current effort is to avoid this to be lost just because of a premature decision, one that would not reflect the clear lack of consensus for MAP that we saw in Paris.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 18:02:34 +0200

Hi, Tomek,

AFAIK, deciding whether hub-and-spoke selection is implicit by mapping rules or explicit with a parameter is a more general matter than an option or sub-optiuon format.

I know you can adapt to any choice made by the team in this respect.

What remains is that we still don't know whether it is possible to make it implicitly or not.

Th fact that DHCPv6 provisioning hasn't been tested, if confirmed, isn't a big deal at all IMHO, but the question was worth asking.

What is more significant is that nobody seems to be able to say, today, whether it can be  implicit or not, and how it will work.

Regards,
RD

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 11 Apr 2012 00:02:08 +0000

Hi Remi,

I think Woj has answered the question that MAP-E will require explicit
provision. He may not answer very clearly YES or NO, but saying it is
durable. IMNO, explicit or implicit is very critical. Implicit is
definitely better but it isn't a real concern if we have to provision a
parameter. IMHo, we should stop here and don't give other people we are
dog-fighting. I think slowly we will build up more support by showing
others we are willing to work with others.

Thanks,
Yiu 

P.S. I will real Maoke's draft about 4rd-u.

On 4/10/12 12:02 PM, "Rémi Després" <[email-masked]> wrote:

>Hi, Tomek,
>
>AFAIK, deciding whether hub-and-spoke selection is implicit by mapping
>rules or explicit with a parameter is a more general matter than an
>option or sub-optiuon format.
>
>Th fact that DHCPv6 provisioning hasn't been tested, if confirmed, isn't
>a big deal at all IMHO, but the question was worth asking.
>
>What is more significant is that nobody seems to be able to say, today,
>whether it can be  implicit or not, and how it will work.
>
>Regards,
>RD
>
>   
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 11 Apr 2012 00:18:47 +0000

I didn't mean to send this to the ML. I still don't know why it did. I
apologize if it offends anybody. Anyway, my position reminds the same. I
would like to work with others to improve technology, not arguing for the
sake of arguing. 

Yiu