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

From: Stig Venaas <[email-masked]>
Date: Mon, 01 Apr 2013 11:25:46 -0700

On 3/29/2013 1:53 AM, [email-masked] wrote:
> 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.

Christian, per PIM-SM, one of the routers will be selected as the DR.
But consider a topology like this:

   |-R2---R3
S-|       |
   |-R1---R4---R5---Receiver

Here we have the source S. We have routers R1 and R2 directly connected
to the source. Assume R2 is the DR (because highest IP address, or
highest DR priority if that is configured). Let R4 be the RP.

In this scenario, R2 would send PIM-registers, then the RP (R4) would
join towards the source, and later on the last hop router (R5) would
join towards the source etc. These joins would go from R4 to R1,
because that is the shortest path to the source.

What happens is that R1 is the one responsible for forwarding multicast,
not R2 which is the DR. So the multicast delivery is not just the DR,
the DR would just take care of the initial registers.

Stig

> 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:
>
>> On 3/25/2013 2:30 AM, [email-masked] wrote:
>>> Hello Stig, all,
>>>
>>> Thanks for the feedback. A few comments inline.
>>>
>>> [snip]
>>> 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.
>>>
>>> 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.
>>
>> 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).
>>
>>>
>>> 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.
>>>
>>> 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.
>>
>> 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?
>>
>>>
>>> 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.
>>>
>>> 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?
>>
>>>
>>> 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.
>>>
>>> CJ: Would "Preserve the integrity of the contents a receiver has
>>> selected (or wants to retrieve)" be OK?
>>
>> Yes, maybe.
>>>
>>>
>>> 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.
>>
>> OK, so great if can say something like that.
>>>
>>> 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.
>>
>> 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.
>>
>>> 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.
>>>
>>> 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:
>>>
>>>       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.
>>>
>>> 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.
>>>
>>> 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.
>>
>> You're right, but it may be worth noting that somewhere in 4.4.1 too.
>>>
>>> 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.
>>
>> Stig
>>
>>> 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.
>>>
>>
>> _______________________________________________
>> MBONED mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mboned
>
> _________________________________________________________________________________________________________________________
>
> 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.
>