]
Envoyé : mardi 14 août 2012 17:33
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Bob Hinden; ipv6@ietf.org; Jacni Qin;
draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org;
Stig Venaas
Objet : Re: draft-ietf-mboned-64-multicast-address-format
Med,
The new draft appears to have many changes
: BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Bob Hinden; ipv6@ietf.org; Jacni Qin;
draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org;
Stig Venaas
Objet : Re: draft-ietf-mboned-64-multicast-address-format
Med,
The new draft appears to have many changes from the previous
version. It would
Venaas
Objet : Re: draft-ietf-mboned-64-multicast-address-format
On Tue, Aug 14, 2012 at 4:09 AM, mohamed.boucad...@orange.com wrote:
Dear all,
I'm initiating this thread in the hope of understanding the
objections from the 6man WG and hopefully to make some progress for
this document
Med,
The new draft appears to have many changes from the previous version. It would
be helpful if you could describe the changes. This is usually done in the
draft itself, but I didn't see it in -03.
Thanks,
Bob
On Aug 14, 2012, at 2:09 AM, mohamed.boucad...@orange.com
On Tue, Aug 14, 2012 at 4:09 AM, mohamed.boucad...@orange.com wrote:
Dear all,
I'm initiating this thread in the hope of understanding the
objections from the 6man WG and hopefully to make some progress for
this document. To initiate the discussion, below are provided some
preliminary Q/A:
On 8/14/2012 9:40 AM, Behcet Sarikaya wrote:
On Tue, Aug 14, 2012 at 4:09 AM, mohamed.boucad...@orange.com wrote:
Dear all,
I'm initiating this thread in the hope of understanding the
objections from the 6man WG and hopefully to make some progress for
this document. To initiate the
I think there's a misunderstanding here. The only requirement is to
translate the IP headers. The document in question deals with the
address translation part of that task.
On 25/05/2012 11:09 PM, Jon Steen wrote:
Sorry all, coming into this late. I have read the RFC and really do not get
why
Cheers
Med
-Message d'origine-
De : Bob Hinden [mailto:bob.hin...@gmail.com]
Envoyé : mercredi 23 mai 2012 18:38
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Bob Hinden; ipv6@ietf.org
Objet : Re: draft-ietf-mboned-64-multicast-address-format
Med,
On May 23, 2012
Dear all,
Many thanks for the individuals who read the draft and provided some comment.
My read of the the answers received in this thread is there is no strong
reasons to question the design choices as documented in the draft.
FWIW, I just submitted a updated version taking into account the
Med,
On May 23, 2012, at 6:20 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Dear all,
Many thanks for the individuals who read the draft and provided some comment.
My read of the the answers received in this thread is there is no strong
reasons to question the
me know if it solves your concerns?
Thanks.
Cheers
Med
-Message d'origine-
De : Bob Hinden [mailto:bob.hin...@gmail.com]
Envoyé : mercredi 23 mai 2012 18:38
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Bob Hinden; ipv6@ietf.org
Objet : Re: draft-ietf-mboned-64-multicast-address-format
Med
I'd like to respond to one of your points. Your overall thrust
(preservation of the existing architure) is reasonable, but it is really
useful operationally for nodes to be able to recognize IPv6 multicast
addresses that contain embedded IPv4 multicast addresses. If the path
taken by the
Dear Bob, et al.;
On Sat, May 5, 2012 at 10:12 PM, Bob Hinden bob.hin...@gmail.com wrote:
Med,
On May 4, 2012, at 5:50 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Dear all,
During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian
suggested to
Med,
On May 4, 2012, at 5:50 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:
Dear all,
During the IETF LC for draft-ietf-mboned-64-multicast-address-format, Brian
suggested to use the remaining flag instead of reserving ff3x:0:8000/33 (SSM)
and ffxx:8000/17 (ASM)
I don't know why IPv6 becomes more arcane with every new I-D. Why not work to
make it simpler, rather than more complex and confusing, with every new
iteration?
In this particular case, it is really confusing to change the location of this
new field, 64IX, depending whether it's ASM or SSM.
On Fri, May 4, 2012 at 3:29 PM, Manfredi, Albert E
albert.e.manfr...@boeing.com wrote:
I don’t know why IPv6 becomes more arcane with every new I-D. Why not work
to make it simpler, rather than more complex and confusing, with every new
iteration?
When you start with simplicity, experience
16 matches
Mail list logo
