Hi Francis,
Please see inline.
Cheers,
Med
-Message d'origine-
De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr]
Envoyé : mardi 13 mars 2012 17:56
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG;
Re-,
Thanks Rajiv for the pointer.
BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must be
adjacent), draft-cui-* and the like can use pseudo-random algorithms to
generate port ranges.
Cheers,
Med
-Message d'origine-
De : Rajiv Asati (rajiva)
Dear Qiong,
Please see inline.
Cheers,
Med
De : Qiong [mailto:bingxu...@gmail.com]
Envoyé : mercredi 14 mars 2012 00:50
À : Francis Dupont
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG;
draft-cui-softwire-b4-translated-ds-lite;
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r...@laposte.net
...
The 4rd mechanism is for protocols that have ports at their usual place
(all existing protocols that have ports have
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r...@laposte.net
...
The 4rd mechanism is for protocols that have ports at their usual
Le 2012-03-14 à 10:00, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després despres.r...@laposte.net
...
The 4rd mechanism is
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:00, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi Després despres.r...@laposte.net
2012-03-13 12:02, Maoke :
2012/3/13 Rémi Després
Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02,
Sec. 1 says::
the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an
IPv4 prefix, an IPv4 address or a shared IPv4 address.
(We all agree, I think, that this is important.)
Sec.5.2 says:
The MAP IPv6
Hi Med, see inline response to your questions wrt sd-nat-02
On Mar 13, 2012, at 10:58 AM,
mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com
mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote:
(*) Question 1: It is not clear in text if there is a second
Hi Alain,
It's a little confusing now. Let me try to get things clear.
So the sd-nat-02 is not quite similar to the earlier version, the
mechanism somehow changes.
In my understanding, now the principle of the mechanism is similar to
the lightweight 4over6 draft, but I may miss something here.
Remi,
Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02,
Sec. 1 says::
the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an
IPv4 prefix, an IPv4 address or a shared IPv4 address.
(We all agree, I think, that this is important.)
Sec.5.2 says:
The
In your previous mail you wrote:
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
= there is one but:
- it translates
Re-,
Thanks Alain for the answers. Please see inline.
Cheers,
Med
-Message d'origine-
De : Alain Durand [mailto:adur...@juniper.net]
Envoyé : mercredi 14 mars 2012 12:11
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG;
Le 2012-03-14 à 13:17, Ole Trøan a écrit :
Remi,
Ole, co-authors of draft-mdt-softwire-mapping-address-and-port-02,
Sec. 1 says::
the residual IPv4 over IPv6 mechanisms must be capable of...Provisioning an
IPv4 prefix, an IPv4 address or a shared IPv4 address.
(We all agree, I think,
Ole, Tomek,
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)?
In your previous mail you wrote:
However, the draft seems give people impression there is only one NAT
at CPE(i.e. 2.3. Stateless DS-Lite CPE operation) and AFTR is
responsible for decapsulation and IPv4 package validation. Did I miss
something?
= yes, the SD-CGN (the SD-AFTR with
In your previous mail you wrote:
= I leave the draft-penno-* unclear items to Reinaldo...
(note: 1- it should be not what we want as it makes CPEs trivial
to track, 2- it doesn't remove the mandatory check on source ports
in the from CPE to the Internet way)
Med: I
Hi Maoke and Remi,
Thanks very much for discussing this issue on the mailing-list. I guess the
points are now clear for both options. IMHO, there is no one better than the
other, it is all about choice of implementation. Perhaps it is time for more
people to comment how they feel for both
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)?
I am a little lost. Let's put the double-nat aside for a moment. Except
the fact that sd-nat uses icmp for port-set provisioning, what else
different between Lightweight 4over6 vs. sd-nat? Am I missing something?
For Lightweight 4over6, we can use anycast for redundancy. I fail to see
what sd-nat
In your previous mail you wrote:
(*) Question 1: It is not clear in text if there is a second NAT
in the AFTR or not. Could you please confirm/infirm a second NAT
is present?
in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the
correct IPv4
Me too.
And another comment:
In sd-nat, it says More importantly, that draft (lightweight 4over6) does
not explain how this solution can be deployed in a regular DS-Lite
environment.
I think this is a deployment issue and lightweight 4over6 can definitely be
deployed in a regular DS-Lite
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:46, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 10:00, Maoke a écrit :
2012/3/14 Rémi Després despres.r...@laposte.net
Le 2012-03-14 à 06:51, Maoke a écrit :
2012/3/13 Rémi
Behcet, I apologize. Even if we differ on what constitutes a multicast
solution, I was wrong to refer to your drafts in a pejorative manner.
Tom Taylor
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
24 matches
Mail list logo
