Subject: AMT (was Re: mboned: draft minutes of the last mboned session)

From: Tom Pusateri <[email-masked]>
Date: Mon, 01 May 2006 12:06:48 -0400

In message <[email-masked]> you write:
>   ----
>  draft-ietf-mboned-auto-multicast-05.txt  
>  Dave Thaler (see slides)
>*Dave Thaler: 05 went through WGLC discussion, with various discussions
>	-Expect -06 soon, early version sent to amt ML
>	-Added IGMP/MLD Query to AMT Membership Query
>	-message to allow gateway to know what version of report to respond wit
>h.
>*Dino -- will the amt membership sent periodically? 
>*Dave -- sent in response to query (as frequently as the gw asks for it). The 
>QQIC should be used to communicate what the router query intervals etc so that
> hosts that abuse this and send too much can be ignored 
>*Dino -- is the query "quickly" reliable? if lost is retransmitted quickly?
>*Dave -- don't remember
>*Dino -- take offline
>*Greg - Follows IGMP/MLD timing, but you said that the gateway side had the ti
>mers. wants the router to control. Need to add text about clarifying what the 
>gateways to (re:timing)
>*Dave -- Added text to say the UDP checksum SHOULD BE calculated on control me
>ssages but MAY be 0 on the multicast data messages.
>*Dino - Checksum: should be zero on data messages
>discussion on MAY vs SHOULD, Dave and Dino agree

So what was the outcome of this? The minutes aren't clear.
Dave, Dino?

>*Dave -- Clarified that the IP header is included in IGMP/MLD messages as well
> as the multicast data messages.
>	-presention of editorial changes
>	- (i).    argument: Support for sourcing, already existing
>	-Proposal: 
>		-A gw MAY support sourcing
>		-Public relays MUST support sourcing   
>		-Private relays SHOULD support souring
>*Greg -- prefer MAY, MAY, MAY, RPFing to anycast prefix too complex
>*Dave -- don't assign same anycast prefix to a gw that does support souring an
>d those that do. 
>*Greg -- No, you find the closest one anyway.
>*Dino -- If the gateway does a MAY, that means most gws' won't implement, publ
>ic gws MUST. No working system. MAY, MAY, MAY, and get a gw prefix (second for
> address allocation). should be consistent

Also not clear on the outcome. Dave, Greg? Do we want a second prefix again?
If so, the AMT Relay Anycast Prefix needs to be big enough to get advertised
in BGP (how big is this in this day and age? A /20, a /19?). It seems like
a waste to allocate a /19 or bigger and only use one or two addresses.

The gateway source prefix needs to be a /16. Since we are only using
a few addresses for the anycast relay prefix, I was combining these
to save on allocations.

>*Pekka -- do you personally expect a sign number sourcing SSM with AMT?
>*Dave -- don't know
>* Pekka --  MUST in sourcing in AMT
>	-whatever decision wants quick decision
>*Dave-- agree quick decision necessary
>	-(ii).   IPv6 Unicast Prefix Length
>		-Draft said /64; perhaps /16           
>	- (iii).  Data encapsulation
>		-GRE doesn't go though NATs --> just UDP or negoiate for GRE.
>		-Proposal: Keep it simple--just UDP (no change to spec) 
>*Pekka -- can AMT signaling extensible enough for the routers to signal prefer
>ence?
>*Dave -- you'd have to change the packet format. but are messages that could b
>e extended to do that. would add complexity.
>*Pekka -- v6 prefix length --> need at least /32  (otherwise won't be routable
>).
>	-need more clear instructions about IANA
>	-maybe update IANA considerations
>*Marshall -- tell the chairs what to do so we can talk to IANA, let us know.
>*Dino -- don't expect fast mass deployment. But we may get fast deployment, bu
>t if it doesn't perform well, won't get to mass deployments, propose we need a
> simple negotiation

So I like the idea (Marshall?) came up with and use a different anycast
address to discover relays that support GRE vs. relays that support UDP.
A relay could listen to both addresses of course if it supports both
types of encapsulation.

Thanks,
Tom
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 May 2006 08:46:26 -0700

>> So what was the outcome of this? The minutes aren't clear.

    I don't know. Dave has to respond. There is nothing in -05 that talks
    about periodic sending of Membership Queries. That really needs to be
    resolved in the next draft.

    Dave did make a blanket statement saying that IGMP, as defined today, 
    just runs over AMT. So I think the "IGMP Query" could be sent periodically
    but there is also a "AMT Membership Query". So it needs to be clarified
    in the AMT spec.

>> So what was the outcome of this? The minutes aren't clear.

    If you were asking about this, I think we did reach conscensus. That is,
    UDP encapsulated Multicast Data need not be checksummed. The inner
    IP header is checksummed from the originating source host as well as
    the inner UDP payload.

>> a few addresses for the anycast relay prefix, I was combining these

    There were some of us that wanted MAY, MAY, MAY but not everyone agreed.
    Maybe the chairs should just make a call.

>> A relay could listen to both addresses of course if it supports both

    Sounds good to me. Less protocol interaction. Would be nice to finalize
    the protocol details so implementations can get on with it.

Thanks,
Dino

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 02 May 2006 17:33:58 -0400

>    resolved in the next draft.

Yes, I think this is going to take some experimentation.  Normally,
I would say that default IGMP query intervals should be triggered
by the gateway. But if a firewall/NAT device times out the stream
before this, then faster refreshes will be needed. Dave wants the
relay to be able to slow down refreshes using the QQIC field in the
query. This is a good plan but also doesn't help with firewall/NAT
boxes. I think the gateway may need to send Requests to the relay
but the relay may throttle them and only send queries as often as
it wants to allow them. This solves the firewall/NAT problem but
doesn't require as much work at a loaded relay.

I will write this up with default values but this will need to be
tunable in several ways.

>    IP header is checksummed from the originating source host as well as

By "need not be checksummed", does this translate to MAY or OPTIONAL?

>    Maybe the chairs should just make a call.

Well, I think a second IPv4 /16 prefix is unlikely. But I also think
it should be gateways MAY, public relays MAY, private relays MAY
support sourcing at the gateways. So we should try to do this with
a single IPv4 prefix.

This means joins from the multicast infrastructure may reach a relay
that just drops the join or the relay may support it and send a
Request to the gateway but the gateway doesn't support it so it
drops the Request.  This is no worse than it is today without AMT
so I don't see this as a problem.

>    the protocol details so implementations can get on with it.

Yes, that's what I'm trying to do to finish the document.

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 May 2006 16:36:37 -0700

>> Yes, I think this is going to take some experimentation.  Normally,

    Some specific questions Tom. See inline.

>> query. This is a good plan but also doesn't help with firewall/NAT

    Triggered by the gateway? The Relay is sending the AMT Membership
    Query. And there is no QQIC in the AMT Membership Query.

    So if you want the Relay to send IGMP Queries, this needs to be put
    in the spec. That is, should the AMT Membershiup Query encapsulate the 
    IGMP Query? I'm not suggesting this but just want clarity.

>> doesn't require as much work at a loaded relay.

    Can you expand on this more?

>> By "need not be checksummed", does this translate to MAY or OPTIONAL?

    At the working group, I suggested "SHOULD not checksum data packets".

>> support sourcing at the gateways. So we should try to do this with

    Okay.

>> so I don't see this as a problem.

    Sure.

>> Yes, that's what I'm trying to do to finish the document.

    Way cool. Thanks Tom.

Dino

---

From: "Greg Shepherd" <[email-masked]>
Date: Tue, 2 May 2006 21:45:06 -0700

> support sourcing at the gateways. So we should try to do this with

Thank you!

Greg

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 May 2006 12:01:44 +0300 (EEST)

> So what was the outcome of this? The minutes aren't clear.

Note that RFC2460 states:

       o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
          the UDP checksum is not optional.  That is, whenever
          originating a UDP packet, an IPv6 node must compute a UDP
          checksum over the packet and the pseudo-header, and, if that
          computation yields a result of zero, it must be changed to hex
          FFFF for placement in the UDP header.  IPv6 receivers must
          discard UDP packets containing a zero checksum, and should log
          the error.

draft-heffner-frag-harmful-01.txt also discusses why fragmentation is 
harmful, especially for IPv4.  This is underlined when checksums are 
disabled.

So, it's a bit questionable whether we should allow (or even 
recommend) zero checksum.  Certainly we can't do that for IPv6 at 
least.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 19 May 2006 10:42:19 -0400

>recommend) zero checksum.  Certainly we can't do that for IPv6 at 

Dino,
	You were the one who wanted this. I assume its because you are
trying to speed things up when software forwarding UDP. But with the
addition of GRE as an option and the desire to do UDP in the hardware
in the future, can you live with making UDP checksums required for
data messages?

Thanks,
Tom

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 19 May 2006 10:17:14 -0700

>> in the future, can you live with making UDP checksums required for

    I would argue we are not violating this. Beacuse in the AMT case, we
    are not "originating" UDP packets but rather using the AMT Multicast
    Data message which sits inside of UDP as an "encapsulation". This could
    be playing with semantics but the intent of 2460 is really from a host
    originating data.

    Yes, I want to speed things up but I want to do it for both UDP and GRE
    cases. Beacuse if a windows box is a gateway and a cisco box is a relay
    and we want packets to automatically go through a NAT, we want this to
    scale.

    If we require UDP checksum on AMT Multicast Data messages, then I'll be
    even stonger advocating GRE. And if we are not flexible here, AMT will
    not take off. We need to be practical.

    Also, this would set a precedent for a hardware forwarder to checksum
    the entire packet. There are many architectures, new and old where the
    entire packet may not be FIFOed in the forwarding decision block of
    the ASIC. Another precedent is to require pseudo-header state maintenance
    as well in hardware. A non-starter in my opinion.

Dino