Subject: [MBONED] WGLC for draft-ietf-mboned-v4v6-mcast-ps

From: Leonard Giuliano <[email-masked]>
Date: Thu, 21 Mar 2013 06:45:58 -0700

We would like to begin working group last call for 
draft-ietf-mboned-v4v6-mcast-ps.  Please include the following in your 
consideration:

-Is the document of a sufficient quality for publication?
-Are all of the use cases and components in the draft reflective of real 
world problems that you think MBONED should attempt to address?

Please post any and all comments supporting/opposing the draft to the list 
by Apr 19.  Most recent version of the draft can be found here:

http://www.ietf.org/id/draft-ietf-mboned-v4v6-mcast-ps-02.txt

---

From: Simon Perreault <[email-masked]>
Date: Fri, 22 Mar 2013 11:12:57 +0100

Support.

> -Is the document of a sufficient quality for publication?

Yes.

> world problems that you think MBONED should attempt to address?

Yes.

Simon

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 22 Mar 2013 14:22:29 +0000

Supported

On 3/21/13 9:45 AM, "Leonard Giuliano" <[email-masked]> wrote:

>_______________________________________________
>MBONED mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mboned

---

From: <[email-masked]>
Date: Fri, 22 Mar 2013 16:37:06 +0100

Hello mboners, 

CJ: Yes.

-Are all of the use cases and components in the draft reflective of real world problems that you think MBONED should attempt to address?

CJ: Yes.

Please post any and all comments supporting/opposing the draft to the list by Apr 19.  Most recent version of the draft can be found here:

Cheers,

Christian.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 22 Mar 2013 11:42:14 -0400

YES++ Marc.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 22 Mar 2013 10:00:04 -0700

This is neither support nor opposition.

On 3/21/13 6:45 AM, Leonard Giuliano wrote:
> -Are all of the use cases and components in the draft reflective of 
> real world problems that you think MBONED should attempt to address?
Without my AD hat on. The use cases in 3.x are essentially a matrix of 
the available receiver x source  x network combinations minus the native 
ones. I doubt very much that the market will demand solutions for all of 
them even if they are valid. It's not my job to decide which ones, it's 
the customer(s). I am satisfied that with the former section 5 gone, we 
no longer have a program of activities laid out for solving each one of 
them.

Regarding whether mboned attempts to address them, that's a high bar, 
imho it's whether mboned participates agree with the PS.
> Please post any and all comments supporting/opposing the draft to the 
> list by Apr 19.  Most recent version of the draft can be found here:
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 22 Mar 2013 12:04:09 -0700

Hi

I don't think the document is quite ready for publication. Here
are my thoughts. Many of these are discussion points, rather than
explicit issues. Apologies for not reviewing the document carefully
earlier.

Issue 1:
    o  Multicast Delivery Network: Network in short, covers the realm
       from Designated Routers that are directly connected to sources to
       IGMP/MLD (Internet Group Management Protocol/Multicast Listener
       Discovery) Querier devices that process IGMP/MLD signalling
       traffic exchanged with receivers.

I think it might be better to use the term First Hop Routers,
instead of Designated Routers. DR is PIM-SM specific.

Issue 2:
I don't quite get this:

    Multicast to the receivers, not from the receivers:  This document
       only covers the case where multicast traffic is forwarded by the
       service provider network to the receivers.  This document does not
       cover the case where the receivers send multicast traffic to the
       network.

You can think of receivers and sources separately. If we describe how
traffic is going from a source to a receiver, then we don't really care
if the source happens to be a receiver. Maybe what I'm trying to say is
that multicast always go to the receivers. And that is all we need to
discuss.

Issue 3:
   o  Zap rapidly.  The time it takes to switch from one content to
       another must be as short as possible.  For example, zapping times
       between two TV channels should be in the magnitude of a few
       seconds at most, whatever the conditions to access the multicast
       network.  A procedure called "IGMP fast-leave" is sometimes used

A few seconds sounds pretty bad to me. I would say it should be less
than a second. Maybe say that it should be comparable to a pure IPv4
case. I don't think there should be any significant overhead due to
translation.

Issue 4:
    o  Preserve the integrity of contents.  Some contract agreements may
       prevent a service provider from altering the content owned by the
       content provider, because of copyright, confidentiality and SLA
       assurance reasons.  Multicast streams should be delivered without
       altering their content.

We should perhaps clarify that content is e.g. the content the user
sees, not the content of IP packets. E.g. RTP headers may need to be
modified, but that should not be regarded as changing the content.

Issue 5:
In 3.1 you have Rcvs --- IGMP --- AF1 --- MLD --- MR. I think it many
cases there would not be MLD though. Rather than translating to MLD,
a MR might just create IPv6 multicast state as if it received an MLD
report, directly from the received IGMP packets. That is, when
implementing AF in a PIM router, I don't see why you would actually
create MLD messages.

I know the diagram is like this because you are thinking of AF1 as a
stand-alone device. But I think it would typically be integrated with
other functions. So it may be good to have some wording saying that
this is just the conceptual model, and that it doesn't necessarily
mean that AF is a separate device and that messages may not need to be
explicitly translated into new messages.

Issue 6:
Someone mentioned an issue with the terminology in the mboned meeting.
We're using terms like 6-4 for IPv6 receiver --- IPv4 source, that is
putting the receiver first. I think someone said that in softwires it
was the opposite? Are we clear what terminology we want to have?

Issue 7:
In 4.2 it says:

    Multicast distribution trees are receiver-initiated.  IPv4 receivers
    that want to subscribe to an IPv4 multicast group will send the
    corresponding IGMP Report message towards the relevant IGMP Querier.

I would say this is slightly misleading. It make it look like the
report is addressed to a particular querier. The messages are usually
sent as multicast though, and the hosts don't care who is the querier.

Issue 8:
In 4.3 it says:

    Such interaction may be complicated by different combinations: the
    IPv4 multicast domain is SSM-enabled (with no RP (Rendezvous Point)
    routers), while the IPv6 multicast domain may support both ASM (Any
    Source Multicast) and SSM (Source Specific Multicast) [RFC3569]
    modes.

I guess this is OK, but I would argue that it is more likely that IPv4
is ASM and IPv6 is SSM. So I wonder if it makes sense to change the
example.

Issue 9:
In 4.4.1.1. and other places in 4.4.1, it may need to be pointed out
that it may not be a stand-alone IWF that simply translates messages.
E.g. if you have an MLD proxy (say a switch today), it would based on
the combined MLD state of the downstream receivers, send aggregated MLD
reports upstream. If this also becomes an IWF, you would when receiving
IGMP reports downstream create state, so that when you send the
aggregated MLD reports upstream, you would also include IPv6 groups (or
channels) based on your IPv4 state.

Issue 10:
4.4.3 I don't think this document should enforce certain format, only
reference them. "The address formats have been defined in..." sounds
like it is only these specific formats, and none other.

Issue 11:
Security Considerations. I think there are additional considerations.
E.g. could the translation hide the real source of the content. When
translating ASM-SSM you have certain security expectations from SSM
(only receiving from the single specified sender), which are not the
case when coming from ASM. Also, if mappings are not stateful, it may
be harder to monitor and troubleshoot the traffic. Also, there are
concepts of IPv4 and IPv6 multicast scopes. When translating, it must
be taken into account how to reasonably map between scopes, and it is
important that the scopes are configured appropriately on the routers
so that say a scope intended to be within a site for IPv4, doesn't leak
outside the site due to translation to IPv6 inside the site.

Stig

---

From: "Diego R. Lopez" <[email-masked]>
Date: Sun, 24 Mar 2013 22:14:51 +0000

This is to express my support.

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Qiong <[email-masked]>
Date: Mon, 25 Mar 2013 11:24:43 +0800

Support.

I think this document is useful and ready for WGLC.

Best wishes
Qiong

On Mon, Mar 25, 2013 at 6:14 AM, Diego R. Lopez <[email-masked]> wrote:

> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 10:30:50 +0100

Hello Stig, all,

Thanks for the feedback. A few comments inline. 

[snip]
Issue 1:

I think it might be better to use the term First Hop Routers, instead of Designated Routers. DR is PIM-SM specific.

CJ: I guess we wanted to be as specific as possible. I would argue that PIM-SM multicast networks are the rule, not the exception, and the proposed definition reflects multicast designs that have been adopted by many operators/IPTV service providers...not too many CBT networks in the field, right :-)? I would personally stick to the proposed wording.

Issue 2:
I don't quite get this:

You can think of receivers and sources separately. If we describe how traffic is going from a source to a receiver, then we don't really care if the source happens to be a receiver. Maybe what I'm trying to say is that multicast always go to the receivers. And that is all we need to discuss.

CJ: what we meant here is that the draft does not consider multicast services that assume a source/receiver heuristic, e.g., videoconferencing services. The draft primarily focuses on residential multicast-based services, as per a typical 1:n group communication scheme. We can surely improve the wording to clarify this scope.

Issue 3:

A few seconds sounds pretty bad to me. I would say it should be less than a second. Maybe say that it should be comparable to a pure IPv4 case. I don't think there should be any significant overhead due to translation.

CJ: I agree with the last sentence. As for the zapping figure, this is just an example. I think the second remains the reference unit in that area, but, obviously, the shorter, the better. 

Issue 4:

We should perhaps clarify that content is e.g. the content the user sees, not the content of IP packets. E.g. RTP headers may need to be modified, but that should not be regarded as changing the content.

CJ: Would "Preserve the integrity of the contents a receiver has selected (or wants to retrieve)" be OK?

Issue 5:
In 3.1 you have Rcvs --- IGMP --- AF1 --- MLD --- MR. I think it many cases there would not be MLD though. Rather than translating to MLD, a MR might just create IPv6 multicast state as if it received an MLD report, directly from the received IGMP packets. That is, when implementing AF in a PIM router, I don't see why you would actually create MLD messages.

I know the diagram is like this because you are thinking of AF1 as a stand-alone device. But I think it would typically be integrated with other functions. So it may be good to have some wording saying that this is just the conceptual model, and that it doesn't necessarily mean that AF is a separate device and that messages may not need to be explicitly translated into new messages.

CJ: fair enough.

Issue 6:
Someone mentioned an issue with the terminology in the mboned meeting.
We're using terms like 6-4 for IPv6 receiver --- IPv4 source, that is putting the receiver first. I think someone said that in softwires it was the opposite? Are we clear what terminology we want to have?

CJ: I think the terminology used by the draft is clear, but any suggestion's welcome.

Issue 7:
In 4.2 it says:

I would say this is slightly misleading. It make it look like the report is addressed to a particular querier. The messages are usually sent as multicast though, and the hosts don't care who is the querier.

CJ: right, but I don't see how the current wording contradicts this. Do you suggest us to remove "relevant" in the above sentence? If so, I'm OK with this suggestion.

Issue 8:
In 4.3 it says:

I guess this is OK, but I would argue that it is more likely that IPv4 is ASM and IPv6 is SSM. So I wonder if it makes sense to change the example.

CJ: I think this is a service provider-specific design consideration. The proposed wording just wanted to highlight situations where extra complexity may arise.

Issue 9:
In 4.4.1.1. and other places in 4.4.1, it may need to be pointed out that it may not be a stand-alone IWF that simply translates messages.
E.g. if you have an MLD proxy (say a switch today), it would based on the combined MLD state of the downstream receivers, send aggregated MLD reports upstream. If this also becomes an IWF, you would when receiving IGMP reports downstream create state, so that when you send the aggregated MLD reports upstream, you would also include IPv6 groups (or
channels) based on your IPv4 state.

CJ: it seems to me that your comment is somewhat related to the above Issue #5, which introduces implementation-specific considerations that discuss an organic view about the actual location of IWF functions. The goal of the draft is certainly not to enter that kind of considerations, but rather stick to functional considerations, as per a kind of conceptual model as you mentioned earlier. From that perspective, the current wording is OK, but we can add a line about the fact that the draft does not discuss the various IWF implementation options.

Issue 10:
4.4.3 I don't think this document should enforce certain format, only reference them. "The address formats have been defined in..." sounds like it is only these specific formats, and none other.

CJ: fair enough, we can smooth the text a bit.

Issue 11:
Security Considerations. I think there are additional considerations.
E.g. could the translation hide the real source of the content. When translating ASM-SSM you have certain security expectations from SSM (only receiving from the single specified sender), which are not the case when coming from ASM. Also, if mappings are not stateful, it may be harder to monitor and troubleshoot the traffic. Also, there are concepts of IPv4 and IPv6 multicast scopes. When translating, it must be taken into account how to reasonably map between scopes, and it is important that the scopes are configured appropriately on the routers so that say a scope intended to be within a site for IPv4, doesn't leak outside the site due to translation to IPv6 inside the site.

CJ: thanks for this elaboration that perfectly makes sense to me. I suggest to update this section accordingly.

Thanks again for your review. I'll let my fellow co-authors further comment, if need be.

Cheers,

Christian.

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 25 Mar 2013 05:45:29 -0700

Christian,

Why are we still trying to address 4-6-4 and 6-4-6 here? I thought
multicast transition issues were to focus on 6-4/6 and 6-4/6, while
Softwire is addressing 4-6-4 and 6-4-6.

Greg

---

From: <[email-masked]>
Date: Mon, 25 Mar 2013 13:51:52 +0100

Hello Greg,

Please remember the draft is a problem statement draft that tries to summarize the use cases that have been discussed and presented by several operators while nurturing the document, regardless of which WG is the relevant placeholder to address each of these use cases (or not).

>From that standpoint, I don't think the draft explicitly suggests mboned to address all the transition scenarios one could think about, but is rather meant to described what may be the issues raised by multicast transition scenarios.

Cheers,

Christian.

-----Message d'origine-----
De : Greg Shepherd [mailto:[email-masked]] 
Envoyé : lundi 25 mars 2013 13:45
À : JACQUENET Christian OLNC/OLN
Cc : Stig Venaas; Leonard Giuliano; MBONED WG
Objet : Re: [MBONED] WGLC for draft-ietf-mboned-v4v6-mcast-ps

Christian,

Why are we still trying to address 4-6-4 and 6-4-6 here? I thought multicast transition issues were to focus on 6-4/6 and 6-4/6, while Softwire is addressing 4-6-4 and 6-4-6.

Greg

On Mon, Mar 25, 2013 at 2:30 AM,  <[email-masked]> wrote:
> the combined MLD state of the downstream receivers, send aggregated 
> MLD reports upstream. If this also becomes an IWF, you would when 
> receiving IGMP reports downstream create state, so that when you send 
> the aggregated MLD reports upstream, you would also include IPv6 
> groups (or
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 25 Mar 2013 10:27:36 -0400

> Softwire is addressing 4-6-4 and 6-4-6.

I'm puzzled by your comment. I thought we were going to list the various issues in the problem-statement draft, and be an mboned (as ops/requirement) wg document. Then, we (IETF) can distribute the various scenarios to the right wg for protocol work. Therefore, I don't understand your comment. Your comment seems related to where to distribute future protocol work, not about the problem statement document itself.

Marc.

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 25 Mar 2013 07:41:51 -0700

> I'm puzzled by your comment. I thought we were going to list the various issues in the problem-statement draft, and be an mboned (as ops/requirement) wg document. Then, we (IETF) can distribute the…

The work in Softwire is not "future" it is present. So calling out
4-6-4 in this document seems to miss the fact that solution work has
already taken place.

Greg

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 25 Mar 2013 07:43:42 -0700

> 4-6-4 in this document seems to miss the fact that solution work has

..and let me elaborate a bit more. The problem multrans was supposed
to address was the case of having a single stream in one address
family being received by end-stations regardless of address family -
Transition, not transport.

Greg

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 25 Mar 2013 11:27:16 -0400

> 4-6-4 in this document seems to miss the fact that solution work has

disagree again. An problem statement RFC should describe the issues, the scenarios, etc..  This is orthogonal to the actual decision within the IETF to where the subsequent work will be done, in which wg, when, etc...  So to me the fact that some followup work has already started in one wg is irrelevant to whether the use-case scenario should be or not in a problem statement draft.  

Marc.

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 25 Mar 2013 08:33:37 -0700

On Mon, Mar 25, 2013 at 8:27 AM, Marc Blanchet
<[email-masked]> wrote:
> disagree again. An problem statement RFC should describe the issues, the scenarios, etc..  This is orthogonal to the actual
> decision within the IETF to where the subsequent work will be done, in which wg, when, etc...  So to me the fact that some
> followup work has already started in one wg is irrelevant to whether the use-case scenario should be or not in a problem
> statement draft.
>
> Marc.

Sure. But how many times are we going to do this?:

http://tools.ietf.org/html/draft-metz-softwires-multicast-problem-statement-00

Greg

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Mar 2013 15:35:30 -0700

> CJ: I guess we wanted to be as specific as possible. I would argue that PIM-SM multicast networks are the rule, not the exception, and the proposed definition reflects multicast designs that have b…

There are people using bidir and DM too. But even for SM, it's actually
not necessarily correct. For SSM, the DR has no special role at the
first hop. If there are multiple routers on the LAN with the source, the
router that will forward depends on where the receiver is, and what the
path is to the source. The DR may not be involved at all.

For ASM, the DR will do PIM registers, but after that, the multicast
forwarding is not necessarily done by the DR either (similar to SSM).

> CJ: what we meant here is that the draft does not consider multicast services that assume a source/receiver heuristic, e.g., videoconferencing services. The draft primarily focuses on residential m…

Maybe rather say that? If you solve translation source - receiver in
one direction, it is possible that it would take care of this case too.
But what about say RTP then? Do we want to allow receivers to send RTCP
reports?

> CJ: I agree with the last sentence. As for the zapping figure, this is just an example. I think the second remains the reference unit in that area, but, obviously, the shorter, the better.

Could we say that the delay you should comparable, or of the same
magnitude as when no transition technique is used?

> CJ: Would "Preserve the integrity of the contents a receiver has selected (or wants to retrieve)" be OK?

Yes, maybe.
> I know the diagram is like this because you are thinking of AF1 as a stand-alone device. But I think it would typically be integrated with other functions. So it may be good to have some wording sa…

OK, so great if can say something like that.
> CJ: I think the terminology used by the draft is clear, but any suggestion's welcome.

I think the comment made was that what this draft (and we in mboned)
call 6-4 is 4-6 in softwires? The difference is whether list the source
or the receiver first. I don't remember who mentioned this, and I
haven't looked into it myself.

> CJ: right, but I don't see how the current wording contradicts this. Do you suggest us to remove "relevant" in the above sentence? If so, I'm OK with this suggestion.

Maybe just say that they will send corresponding IGMP reports. You don't
have to say where they are sent. They are not sent to the querier. The
querier may not even care. For PIM-SM, it would be the DR, not the
querier who cares.
> CJ: I think this is a service provider-specific design consideration. The proposed wording just wanted to highlight situations where extra complexity may arise.

This was a very minor point. I know we're just trying to explain
that we may switch between SSM and ASM. Just a suggestion.
> CJ: it seems to me that your comment is somewhat related to the above Issue #5, which introduces implementation-specific considerations that discuss an organic view about the actual location of IWF…

You're right, but it may be worth noting that somewhere in 4.4.1 too.

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 27 Mar 2013 21:15:57 +0000

Hi Christian,

For the DR discussion, I tend to agree with Stig for this since DR has
specific meaning in asm. It may be better to use a more neutral word to
identify the router connecting to the source because the transition
problem statement should also cover at minimum ssm.

Thanks,
Yiu

On 3/25/13 6:35 PM, "Stig Venaas" <[email-masked]> wrote:

>> I think it might be better to use the term First Hop Routers, instead
>>of Designated Routers. DR is PIM-SM specific.
>>
>> CJ: I guess we wanted to be as specific as possible. I would argue that
>>PIM-SM multicast networks are the rule, not the exception, and the
>>proposed definition reflects multicast designs that have been adopted by
>>many operators/IPTV service providers...not too many CBT networks in the
>>field, right :-)? I would personally stick to the proposed wording.
>
>> CJ: what we meant here is that the draft does not consider multicast
>>services that assume a source/receiver heuristic, e.g.,
>>videoconferencing services. The draft primarily focuses on residential
>>multicast-based services, as per a typical 1:n group communication
>>scheme. We can surely improve the wording to clarify this scope.
>
>> CJ: I agree with the last sentence. As for the zapping figure, this is
>>just an example. I think the second remains the reference unit in that
>>area, but, obviously, the shorter, the better.
>
>>cases there would not be MLD though. Rather than translating to MLD, a
>>MR might just create IPv6 multicast state as if it received an MLD
>>other functions. So it may be good to have some wording saying that this
>>is just the conceptual model, and that it doesn't necessarily mean that
>>AF is a separate device and that messages may not need to be explicitly
>>translated into new messages.
>>
>> CJ: fair enough.
>
>> CJ: right, but I don't see how the current wording contradicts this. Do
>>you suggest us to remove "relevant" in the above sentence? If so, I'm OK
>>with this suggestion.
>
>> CJ: I think this is a service provider-specific design consideration.
>>The proposed wording just wanted to highlight situations where extra
>>complexity may arise.
>
>> CJ: it seems to me that your comment is somewhat related to the above
>>Issue #5, which introduces implementation-specific considerations that
>>discuss an organic view about the actual location of IWF functions. The
>>goal of the draft is certainly not to enter that kind of considerations,
>>but rather stick to functional considerations, as per a kind of
>>conceptual model as you mentioned earlier. From that perspective, the
>>current wording is OK, but we can add a line about the fact that the
>>draft does not discuss the various IWF implementation options.
>
>>case when coming from ASM. Also, if mappings are not stateful, it may be
>>harder to monitor and troubleshoot the traffic. Also, there are concepts
>>of IPv4 and IPv6 multicast scopes. When translating, it must be taken
>>into account how to reasonably map between scopes, and it is important
>>that the scopes are configured appropriately on the routers so that say
>>a scope intended to be within a site for IPv4, doesn't leak outside the
>>site due to translation to IPv6 inside the site.
>>
>> CJ: thanks for this elaboration that perfectly makes sense to me. I
>>suggest to update this section accordingly.
>>
>>_________________________________________________________________________
>>________________________________________________
>>
>>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;
>> As emails may be altered, France Telecom - Orange is not liable for
>>messages that have been modified, changed or falsified.
>> Thank you.
>>
>

---

From: <[email-masked]>
Date: Fri, 29 Mar 2013 09:53:09 +0100

Hello Yiu,

The "first hop router" wording suggested by Stig is fine by me. The udpated version of the draft will reflect the change, but I would argue that routers directly connected to the source (and possibly elected) are designated as DRs as epr the PIM-SM specification, whatever the ASM or SSM flavor of the multicast design.

Cheers,

Christian.

-----Message d'origine-----
De : Lee, Yiu [mailto:[email-masked]] 
Envoyé : mercredi 27 mars 2013 22:16
À : Stig Venaas; JACQUENET Christian OLNC/OLN
Cc : MBONED WG
Objet : Re: [MBONED] WGLC for draft-ietf-mboned-v4v6-mcast-ps

Hi Christian,

For the DR discussion, I tend to agree with Stig for this since DR has specific meaning in asm. It may be better to use a more neutral word to identify the router connecting to the source because the transition problem statement should also cover at minimum ssm.

Thanks,
Yiu

On 3/25/13 6:35 PM, "Stig Venaas" <[email-masked]> wrote:

>> CJ: I guess we wanted to be as specific as possible. I would argue 
>>that PIM-SM multicast networks are the rule, not the exception, and 
>>the proposed definition reflects multicast designs that have been 
>>adopted by many operators/IPTV service providers...not too many CBT 
>>networks in the field, right :-)? I would personally stick to the proposed wording.
>
>first hop. If there are multiple routers on the LAN with the source, 
>the router that will forward depends on where the receiver is, and what 
>the path is to the source. The DR may not be involved at all.
>
>>traffic is going from a source to a receiver, then we don't really 
>>care if the source happens to be a receiver. Maybe what I'm trying to 
>>say is that multicast always go to the receivers. And that is all we 
>>need to discuss.
>>
>> CJ: I agree with the last sentence. As for the zapping figure, this 
>>is just an example. I think the second remains the reference unit in 
>>that area, but, obviously, the shorter, the better.
>
>> CJ: right, but I don't see how the current wording contradicts this. 
>>Do you suggest us to remove "relevant" in the above sentence? If so, 
>>I'm OK with this suggestion.
>
>Maybe just say that they will send corresponding IGMP reports. You 
>don't have to say where they are sent. They are not sent to the 
>querier. The querier may not even care. For PIM-SM, it would be the DR, 
>not the querier who cares.
>>
>> Issue 8:
>> In 4.3 it says:
>>
>> I guess this is OK, but I would argue that it is more likely that 
>>IPv4 is ASM and IPv6 is SSM. So I wonder if it makes sense to change 
>>the example.
>>
>This was a very minor point. I know we're just trying to explain that 
>we may switch between SSM and ASM. Just a suggestion.
>>
>> Issue 9:
>>discuss an organic view about the actual location of IWF functions. 
>>The goal of the draft is certainly not to enter that kind of 
>>considerations, but rather stick to functional considerations, as per 
>>a kind of conceptual model as you mentioned earlier. From that 
>>perspective, the current wording is OK, but we can add a line about 
>>the fact that the draft does not discuss the various IWF implementation options.
>
>>so that say a scope intended to be within a site for IPv4, doesn't 
>>leak outside the site due to translation to IPv6 inside the site.
>>
>>___ ________________________________________________
>>
>>par erreur, veuillez le signaler  a l'expediteur et le detruire ainsi 
>>que les pieces jointes. Les messages electroniques etant susceptibles 
>>d'alteration,  France Telecom - Orange decline toute responsabilite si 
>>ce message a ete altere, deforme ou falsifie. Merci.
>>
>>privileged information that may be protected by law;  they should not 
>>be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender 
>>and delete this message and its attachments.