Subject: Re: [MBONED] WGLC draft-ietf-mboned-auto-multicast-13

From: Greg Bumgardner <[email-masked]>
Date: Wed, 6 Jun 2012 11:50:00 -0700

Bob,

Thanks for the review. Comments below.

-g.b.

On May 31, 2012, at 9:45 AM, SAYKO, ROBERT J wrote:

> Greg, et al,
> 
> 
> Here are our comments.
> 
> 
> A) Our expectation is that multicast datagrams may be fragmented and contained in more than one AMT Data message.   The document seems pretty consistent that an AMT Multicast data message contains the entire IP multicast datagram is there a disconnect here?
> 
> There are several places where this should be addressed:
> 
> Section 4.2.1 "Multicast Data:  Sent by relays to deliver an encapsulated IP multicast datagram to a gateway"  à ".. to deliver an encapsulated IP multicast datagram (or fragment thereof) to a gateway."
> Section 4.2.2.3 "each multicast IP datagram that arrives at the relay is encapsulated in an AMT message" à "encapsulated in one or more AMT message"
> Section 5.1.6 "A relay sends a Multicast Data message to deliver an IP multicast packet" à "sends one or more Multicast Data messages."
> Section 5.1.6.4 "A complete IPv4 or IPv6 Multicast datagram" à "A complete or fragment of an IPv4 ."
> 
I could probably have fixed this by changing datagram to packet, but I will do as you suggest and include fragment in the descriptions.
> 
> 
> B) Would like to recommend the following text from section "5.3.3.2. Handling a Relay Discovery Message":
> 
> 	If the Relay Discovery message was received as an IPv4 datagram, the
> 	relay MUST return an IPv4 address in the Relay Address field of the
> 	Relay Advertisement message.  If the Relay Discovery message was
> 	received as an IPv6 datagram, the relay may return an IPv4 or IPv6
> 	address in the Relay Address field.
> 
> included in section "5.1.2.5 Relay Address" as well.  
> 
> 
> C) Would like to recommend some clarification regarding the "Response MAC" in the Teardown message.  Section "5.1.7.4. Response MAC" states: 
> 
> 	A 48-bit value copied from the Response MAC field (Section 5.1.4.6)
> 	in the last Membership Query message the relay sent to the gateway
> 	endpoint address of the tunnel to be torn down.  The gateway endpoint
> 	address is provided by the Gateway IP Address and Gateway Port Number
> 	fields carried by the Membership Query message.
> 
> We believe this implies that the Relay will need to keep track of the last "Response MAC" sent to the Gateway.

I'm not sure why one would read it this way as other portions of the document indicate that the relay does NOT need to keep track of the Response MAC as the information required to compute and verify the value is carried by the Teardown message. The relay only uses the MAC to verify that the Teardown message was sent in response to an earlier Membership Query message. The only state maintained by the relay is the private secret used to generate recent Response MAC values.

> 
> 
> If this is the intention, then section "4.2.1.3. Teardown Sequence" bullet "8" and section "5.3.3.5. Handling a Teardown Message" should be updated accordingly.  
> 
> If this is not the intention, then section "5.1.7.4. Response MAC" should be reworded.  

I will add a blub regarding the stateless-ness of the Response MAC.

> 
> 
> Regards,
> Bob Sayko and the AT&T AMT team.
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Shepherd
> Sent: Monday, May 21, 2012 3:31 PM
> To: [email-masked]
> Subject: Re: [MBONED] WGLC draft-ietf-mboned-auto-multicast-13
> 
> We're half way through the 3 week WGLC for AMT and we've received no
> responses. Please read and respond ASAP so we can progress.
> 
> Thanks,
> Greg
> 
> On Thu, May 10, 2012 at 10:33 AM, Greg Shepherd <[email-masked]> wrote:
>> *,
>> 
>> Yes, I think we may finally be here! The Paris and post-Paris
>> discussions were addressed in the finally rev so it is now time for
>> WGLC for draft-ietf-mboned-auto-multicast-13:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mboned-auto-multicast/
>> 
>> It is quite long so we'll give it three weeks for responses before
>> moving it along. Please respond by May 31st. And as always, we need
>> votes of approval as much as comments and issues. Let's see this
>> finally move to req pub!
>> 
>> Thanks to everyone who has been involved throughout the past +decade. :p
>> 
>> MBONED Chairs
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 6 Jun 2012 11:50:41 -0700

Bob,

-g.b.

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 6 Jun 2012 16:34:00 -0700

Kurt,

Comments below...

Thanks,

-g.b.

On May 30, 2012, at 5:35 PM, Kurt Windisch wrote:

> Sorry for the 11th-hour response to this WGLC.
> 
> I do have a couple of comments:
> 
> 1. The IGMPv3 spec calls for the type-of-service bit for IP control to be set on all IGMP packets (section 4 of RFC 3376, "Every IGMP message described in this document is sent with ... IP Precedence of Internetwork Control (e.g., Type of Service 0xc0) ...". It seems logical that IPv4 AMT control messages should have the same TOS as the control packets that they encapsulate. Thus, I'd like to suggest that all IPv4 AMT control packets (AMT packets EXCEPT the AMT Data packet) should have TOS 0xc0. 
> 

I'm not set against making this change, but I do want to point out that some gateways will not be able to set the TOS (at all or to this value), so this would definitely be a SHOULD or MAY requirement.  If we were to apply this rule to encapsulated IGMP packets, then shouldn't we be doing the same for encapsulated MLD packets (even though the MLD spec(s) do not appear to set forth any requirements regarding IPv6 traffic class)?

> 2. (nit) In the new text of section 5.2.3.5.4, it states: The IGMP and MLD protocol specifications indicate that senders should use a link-local source IP address in message datagrams." This is incorrect since it is only applies to MLD and only the MLD specs make such a statement.
> 
> I don't see any problems with the rest of the document or changes.
> 
> Thanks
> --Kurt
> 
> Sent: Thursday, May 10, 2012 10:33 AM
> To: [email-masked]
> Subject: [MBONED] WGLC draft-ietf-mboned-auto-multicast-13
> 
> *,
>

---

From: Greg Bumgardner <[email-masked]>
Date: Wed, 6 Jun 2012 17:22:38 -0700

All,

I have made changes to the draft based on WGLC comments. I would like those of you who responded to take a look at the attached diff to see if the changes are satisfactory. I would like to publish draft #14 in the next day or so.

Thanks, 

-g.b.

---

From: Greg Bumgardner <[email-masked]>
Date: Thu, 7 Jun 2012 00:44:00 -0700

Thanks Tom.

Just a couple of comments below.

I corrected the errors you identified and fixed a few more that I found after running the document through a better spell checker. These changes appear in the attached diff.

Thanks again,

-g.b.

On Jun 6, 2012, at 6:07 PM, Tom Taylor wrote:

> In 5.1.5, still have "Message Update message" rather than "Membership Update message".
> 
I must have skipped over that one when I was going through the e-mails.

> In 5.2.1, you did primary -> primarly -- still missing the 'i'.
> 
> In 5.3.1, you got rid of the comma before "Section", but didn't add the "in" in front of it.
> 
> 5.3.3.4, third-last para: missing "of" between "form" and "group".
> 
I definitely remember fixing this, now see that this mistake was repeated in the adjacent paragraph.

> Still wondering why you have "Static" in the section titles of 5.2.2.1 and 5.2.2.2.
> 
I removed "Static" from the section titles (though it is still used within the section text). 

> On 06/06/2012 8:22 PM, Greg Bumgardner wrote:
>> All,
>>