. This is
documented in Section 3.1 of the draft.
o Implemented some wording changes suggested by P. Koch.
o Update the section with examples.
A detailed diff is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-04.
Cheers,
Med
: 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
for the unicast counterpart of these use cases?
Yes; various solutions including:
1. 6-4: RFC6146
2. 4-6-4: RFC6333, RFC6346, ...
The latest version of the document is available at:
https://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-03.
Comments and suggestions
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
After a discussion between the 6man chairs, the Internet and OM Area
Directors, the AD's have decided to move this draft to 6MAN. See the email
from Ron Bonica to the mboned list:
http://www.ietf.org/mail-archive/web/mboned/current/msg01592.html
We would like to encourage discussion of this
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
added two appendixes to
explain:
Not seeing a response on the list, it wasn't clear to me.
* Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection? (
http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1
)
This just restates that you
version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-02
Cheers,
Med
De : ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] De la part de
mohamed.boucad...@orange.com
Envoyé : vendredi 4 mai 2012 14:50
À : mboned-cha
the MPREFIX64 (comment from C. Bormann)
Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mboned-64-multicast-address-format-02
Cheers,
Med
De : ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] De la part de
mohamed.boucad...@orange.com
Envoyé : vendredi
Dear Bob,
Yes, I read that message. It is one of reasons I added two appendixes to
explain:
* Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection?
(http://tools.ietf.org/html/draft-ietf-mboned-64-multicast-address-format-02#appendix-A.1)
* Why Identifying an IPv4-Embedded
Hi Brian,
Sorry for getting back late. I read Bert's answers to your questions. His
answers are inline with my answers. Most information are statically
configured. For example: Ch1 is statically configured to 224.1.2.3 via OOB
mechanism. If the STB is IPv4 only, it will only use IPv4 mcast
On 5/14/2012 1:50 PM, Lee, Yiu wrote:
Hi Brian,
Sorry for getting back late. I read Bert's answers to your questions. His
answers are inline with my answers. Most information are statically
configured. For example: Ch1 is statically configured to 224.1.2.3 via OOB
mechanism. If the STB is IPv4
Hi Stig,
Right. I explain only one use case. Other may find the latter case is more
attractive for their deployments. This address format should enable the
dynamic use case as well.
Yiu
On 5/14/12 4:56 PM, Stig Venaas s...@cisco.com wrote:
On 5/14/2012 1:50 PM, Lee, Yiu wrote:
Hi Brian,
have
draft-ietf-mboned-64-multicast-address-format.
However, there has been many objections to
draft-ietf-mboned-64-multicast-address-format because it is trying to
extend IP addressing architecture.
I do agree to those who say that we do not need to extend the
architecture and hope that a simpler
Re-,
On 5/15/2012 Tuesday 5:06 AM, Lee, Yiu wrote:
Hi Stig,
Right. I explain only one use case. Other may find the latter case is more
attractive for their deployments. This address format should enable the
dynamic use case as well.
Yes, imaging the coexistence of the native provisioning and
-format@tools.ietf.org; The IESG;
mbo...@ietf.org
Subject: Re: [MBONED] APPSDIR review of draft-ietf-mboned-64-multicast-
address-format-01
Hi Yiu,
Let me ask a few questions...
On 5/9/12 10:52 PM, Lee, Yiu wrote:
Hi Carsten,
Thanks very much for reviewing the document. I just
application-layer protocols;
draft-ietf-mboned-64-multicast-address-format@tools.ietf.org
Objet : Re: [MBONED] APPSDIR review of
draft-ietf-mboned-64-multicast-address-format-01
Hi Yiu,
Let me ask a few questions...
On 5/9/12 10:52 PM, Lee, Yiu wrote:
Hi Carsten,
Thanks very much
Hi Carsten,
Thanks very much for reviewing the document. I just want to add a point to
your question about how applications decide when to use this multicast
address format. In fact, they don't. Imagine a use case where a legacy
IPv4 IP-TV receiver (an app) wants to join a channel which is
Hi Carsten,
Thanks a lot for your comments, please see inline below.
On 5/10/2012 Thursday 2:20 AM, Carsten Bormann wrote:
Hi Med,
thanks for looking into my review. Let me take this opportunity to reiterate
that, while I wrote this review for the Applications Area Directorate, it is
not
Dear Carsten,
Please see inline.
Cheers,
Med
-Message d'origine-
De : Carsten Bormann [mailto:c...@tzi.org]
Envoyé : mercredi 9 mai 2012 20:21
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc :
draft-ietf-mboned-64-multicast-address-format@tools.ietf.or
g; apps-disc...@ietf.org application
Hi Tina,
thanks for the pointers.
On the problem statement, you say:
It's has been adopted as MBONED WG item. The authors will submit the WG draft
soon.
So I would normally expect the two documents (problem statement and normative
spec) to go through as a cluster (if not the problem
d'origine-
De : Carsten Bormann [mailto:c...@tzi.org]
Envoyé : jeudi 10 mai 2012 13:01
À : Tina TSOU
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; mbo...@ietf.org;
6...@ietf.org; The IESG; apps-disc...@ietf.org
application-layer protocols;
draft-ietf-mboned-64-multicast-address-format
Hi Yiu,
Let me ask a few questions...
On 5/9/12 10:52 PM, Lee, Yiu wrote:
Hi Carsten,
Thanks very much for reviewing the document. I just want to add a point to
your question about how applications decide when to use this multicast
address format. In fact, they don't. Imagine a use case
From: mboned-boun...@ietf.org [mailto:mboned-boun...@ietf.org] On
Behalf Of Brian Haberman
On 5/9/12 10:52 PM, Lee, Yiu wrote:
Hi Carsten,
Thanks very much for reviewing the document. I just want to add a
point to
your question about how applications decide when to use this
multicast
Dear Carsten,
Thank you for the review.
Please see inline.
Cheers,
Med
-Message d'origine-
De : Carsten Bormann [mailto:c...@tzi.org]
Envoyé : dimanche 6 mai 2012 22:58
À :
draft-ietf-mboned-64-multicast-address-format@tools.ietf.or
g; apps-disc...@ietf.org application-layer
Hi Med,
thanks for looking into my review. Let me take this opportunity to reiterate
that, while I wrote this review for the Applications Area Directorate, it is
not intended to bear more weight than any other comment submitted by an
individual during a Last Call.
Med: There are plenty of
Sent from my iPad
On May 9, 2012, at 11:54 AM, Carsten Bormann c...@tzi.org wrote:
Hi Med,
thanks for looking into my review. Let me take this opportunity to reiterate
that, while I wrote this review for the Applications Area Directorate, it is
not intended to bear more weight than
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
for direction from your document shepherd
or AD before posting a new version of the draft.
Grüße, Carsten
-
Document: draft-ietf-mboned-64-multicast-address-format-01
Title: IPv4-Embedded IPv6 Multicast Address Format
Reviewer: Carsten Bormann
Review Date: 2012-05
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
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) blocks. FYI, we have considered that approach in an
early version of the document but it has been abandoned
Of
mohamed.boucad...@orange.com
Sent: Friday, May 04, 2012 8:50 AM
To: mboned-cha...@ietf.org; ipv6@ietf.org
Cc: Brian Haberman; draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org
Subject: draft-ietf-mboned-64-multicast-address-format
Dear all,
During the IETF LC for draft-ietf-mboned-64
Haberman;
draft-ietf-mboned-64-multicast-address-for...@tools.ietf.org
Subject: draft-ietf-mboned-64-multicast-address-format
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
...@ietf.org
Subject: Last Call: draft-ietf-mboned-64-multicast-address-format-01.txt
(IPv4-Embedded IPv6 Multicast Address Format) to Proposed Standard
Reply-To: i...@ietf.org
The IESG has received a request from the MBONE Deployment WG (mboned) to
consider the following document:
- 'IPv4-Embedded
-mboned-64-multicast-address-format-01.txt
Pages : 12
Date: 2012-02-29
Regards,
Brian
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
38 matches
Mail list logo