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

From: Greg Shepherd <[email-masked]>
Date: Thu, 10 May 2012 10:33:13 -0700

*,

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

---

From: Greg Shepherd <[email-masked]>
Date: Mon, 21 May 2012 12:30:54 -0700

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 May 2012 16:17:28 -0500

I support the call.

Behcet

On Mon, May 21, 2012 at 2:30 PM, Greg Shepherd <[email-masked]> wrote:
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Kurt Windisch <[email-masked]>
Date: Wed, 30 May 2012 17:35:19 -0700

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. 

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Shepherd
Sent: Thursday, May 10, 2012 10:33 AM
To: [email-masked]
Subject: [MBONED] WGLC draft-ietf-mboned-auto-multicast-13

*,

MBONED Chairs

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Thu, 31 May 2012 16:45:42 +0000

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 ."

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.  

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.  

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

Thanks,
Greg