Subject: [MBONED] AMT Tunneling Draft 11

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Sun, 16 Oct 2011 23:25:31 +0000

After reviewing the document we at AT&T  are recommending the following:

1) Throughout document capitalize the keywords (e.g. MUST,  SHOULD, MAY, etc) for requirements 
2) Throughout document remove text allowing the sourcing of multicast traffic behind an AMT GW
3) Throughout document use terms and formats consistently - examples:
	a. Section 5.3 prefix the term AMT or GW to messages (do not say Query,  but be specific - AMT Query Message
	b. Section 5.3 suffix the message correctly (do not say AMT Request,  but be specific - AMT Request Message)
	c. Section 6.4 use the term message not packet
4) Section 4.5 - be specific that operators should be allowed to use their own Anycast address
5) Section 4.6 - same comment as for 4.5
6) Section 6.5 - The change to Membership Query can occur with or without the Membership Teardown,  but is required for the Memebership Teardown message
7) Section 6.5.2 - Add text "The AMT Membership Query Message SHOULD contain the GW information fields"
8) Section 6.8 - Add text " This message required that the MAT Membership Query Message" passed the GW address and port"
9) Section 7.1 - proposes that GW may do discovery at startup and SHOULD do periodic rediscovery.   The periodic rediscovery should be left up to GW implementation. Rather see "may do periodic rediscovery".   May also do Discovery at start of every tunnel and to Not do periodic rediscovery as it could be disruptive to streams that are in progress.
10) Section 7.4 - Only includes example where ICMP unreachable message is received to indicate Relay is down.   ICMP messages may not be received because network routers do not always return ICMP messages.   To be clear the message should include the example where there the GW fails to receive an expected AMT Query message from the Relay within some period of time.
11) Section 10 - more explicit and stronger language around the Quiese-like feature.     Currently, it says the Relay "may" stop advertising the anycast.    If Relay has reached its capacity it "must" withdraw the Anycast or will black-hole traffic.

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 16 Oct 2011 17:52:57 -0700

Thanks Robert!

Thomas & Greg, please do not submit a rev of the doc until all diffs
have been taken to the list and met consensus.  Let's start getting
the diffs to the list soon so we can have something to show in Taipei.

Thanks,
Greg

On Sun, Oct 16, 2011 at 4:25 PM, SAYKO, ROBERT J <[email-masked]> wrote:
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>

---

From: Greg Bumgardner <[email-masked]>
Date: Sun, 16 Oct 2011 18:07:09 -0700

Robert,

Thanks for the feedback.

Thomas and I have been working on some changes that will appear in the 
next version of the draft should they be accepted. We will be releasing 
diffs for a new draft ASAP.

Comments inline...

-g.b.

> 1) Throughout document capitalize the keywords (e.g. MUST,  SHOULD, MAY, etc) for requirements
Working on that.
> 2) Throughout document remove text allowing the sourcing of multicast traffic behind an AMT GW\
Was removed in the last draft.
> 	c. Section 6.4 use the term message not packet
I understand the reasoning, but I don't see the need to qualify every 
reference to a protocol message, when the context makes the meaning of 
"request", "query", "report", etc. pretty obvious. We'll look at it.
> 4) Section 4.5 - be specific that operators should be allowed to use their own Anycast address
Though, I believe that already appeared in the last draft, I have 
expanded upon this topic in the proposed changes for the next draft.
> 6) Section 6.5 - The change to Membership Query can occur with or without the Membership Teardown,  but is required for the Memebership Teardown message
Sure.
> 7) Section 6.5.2 - Add text "The AMT Membership Query Message SHOULD contain the GW information fields"
I agree. Though I think new relay implementations MUST include the 
gateway address fields though we'll have to leave the text as "SHOULD".
> 8) Section 6.8 - Add text " This message required that the MAT Membership Query Message" passed the GW address and port"
OK.
> 9) Section 7.1 - proposes that GW may do discovery at startup and SHOULD do periodic rediscovery.   The periodic rediscovery should be left up to GW implementation. Rather see "may do periodic redi…
I'm pretty sure we already ruled this out, and might have already been 
corrected in the last draft. It makes no sense for a GW to do a 
discovery "at start-up". A gateway configured to use discovery should 
only do so just prior to sending a request to create group membership 
state when none existed at that point, or if the GW has determined that 
it may have lost communication with the relay whose address was returned 
in response to the last discovery. If the gateway receives no response 
to a request (timeout is vendor/configuration specific), and the gateway 
is configured/designed to do discovery, then it should perform discovery 
to locate a new relay.
> 10) Section 7.4 - Only includes example where ICMP unreachable message is received to indicate Relay is down.   ICMP messages may not be received because network routers do not always return ICMP m…
I agree that we should include an informational discussion on handling 
of ICMP "unreachable" messages (at either end) and gateway timeouts and 
retransmission. However, as discussed at the last IETF, the spec will 
not impose any sort of requirements with respect to these topics.
> 11) Section 10 - more explicit and stronger language around the Quiese-like feature.     Currently, it says the Relay "may" stop advertising the anycast.    If Relay has reached its capacity it "mu…
Yes.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 18 Oct 2011 11:19:35 +0200

Hi Bob, Greg,

Greg Bumgardner :
> SAYKO, ROBERT J: 

Indeed, it's suppose to have been removed completely already.
If you found a place where it still is mentioned, please point it out.

>>     a. Section 5.3 prefix the term AMT or GW to messages (do not say 
>> Query,  but be specific - AMT Query Message
>>     b. Section 5.3 suffix the message correctly (do not say AMT 
>> Request,  but be specific - AMT Request Message)

It's certainly reasonable to prefer "message" to "packet", but for the 
rest, I'd keep readability as a guideline and decide on a case-by-case 
basis.

> expanded upon this topic in the proposed changes for the next draft.

I think that what is key is to be clear on what is required for the 
protocol to work (and which parts of the protocol). This is the interop 
part, and has to be clear. The text in -11 does not do this yet and only 
explain one way to do things, which is not the only possible one. Beyond 
this, we can design different types of deployments, some of which  the 
specs can provide as examples; the current Anycast address based on an 
IANA reserved prefix should I think just become one of many ways of 
using AMT.

You remind above that operators could use "their own anycast Address"; I 
would add that you can also design deployments where the Relay discovery 
address is not even an anycast address, and even deployments where 
discovery is not used at all. I'm not saying you should, this is another 
question, but the key point is that the key part to get right is to 
describe the role of the discovery phase, how gateway may send discovery 
messages and how relay should answer them, and be clear that whatever 
path was taken to identify a workable relay, the request/query/update 
cycle can happen.

>> 6) Section 6.5 - The change to Membership Query can occur with or 
>> without the Membership Teardown,  but is required for the Memebership 
>> Teardown message
> Sure.

6.8 says "Hence, a Relay supporting the Teardown mechanism SHOULD 
include the Gateway information fields in the Query messages it sends.".

> gateway address fields though we'll have to leave the text as "SHOULD".

If/When the Teardown procedures aren't used, AMT can work without the 
Gateway information fields in the AMT Query message, so "MUST" would be 
excessive. In such a context, I think we should say that the Relay "MAY" 
include these fields, since it can help tracing/logging/stats, but is 
not necessary for AMT in itself.

>> 8) Section 6.8 - Add text " This message required that the MAT 
>> Membership Query Message" passed the GW address and port"
> OK.

It seems to me that the following paragraph of 6.8 already implies this:

    In order for the Relay to verify the Teardown message, this message
    must contain the original source address and source port in addition
    to the Original Request Nonce and Original Response MAC.  In
    situations where NAT is used, this information can be known by the
    Gateway thanks to the optional Gateway information fields in the
    Query message (Section 6.5.6  <http://tools.ietf.org/html/draft-ietf-mboned-auto-multicast-11#section-6.5.6>).  Hence, a Relay supporting the
    Teardown mechanism SHOULD include the Gateway information fields in
    the Query messages it sends.

>> 9) Section 7.1 - proposes that GW may do discovery at startup and 
>> SHOULD do periodic rediscovery.   The periodic rediscovery should be 
>> left up to GW implementation. Rather see "may do periodic 
>> rediscovery".   May also do Discovery at start of every tunnel and to 
>> Not do periodic rediscovery as it could be disruptive to streams that 
>> are in progress.
> state when none existed at that point, or if the GW has determined 
> that it may have lost communication with the relay whose address was 
> returned in response to the last discovery. If the gateway receives no 
> response to a request (timeout is vendor/configuration specific), and 
> the gateway is configured/designed to do discovery, then it should 
> perform discovery to locate a new relay.

Clarifying the above is related to clarifying the role of the discovery 
procedure, and the text needs to be improved; but by and large, since we 
make discovery optional, I don't think we have any strong rule to impose 
for when the discovery will be done: obviously, if discovery is wanted 
it needs to happen before a Request, but whether its done right before, 
or a long-time before, the Requst, should be left up to the 
implementation. Doing the discovery at Relay startup and then 
periodically may allow to reduce, on average, the join-latency, at the 
cost of increasing the worst case (case where the Relay dies between the 
discovery and the first request).

>> 10) Section 7.4 - Only includes example where ICMP unreachable 
>> message is received to indicate Relay is down.   ICMP messages may 
>> not be received because network routers do not always return ICMP 
>> messages.   To be clear the message should include the example where 
>> there the GW fails to receive an expected AMT Query message from the 
>> Relay within some period of time.
> of ICMP "unreachable" messages (at either end) and gateway timeouts 
> and retransmission. However, as discussed at the last IETF, the spec 
> will not impose any sort of requirements with respect to these topics.

We already identified the need for clarifying how/when gateway may 
retransmit and/or rediscover.
If we do this, we probably don't need to expand on ICMP unreachable... 
right ?

>> 11) Section 10 - more explicit and stronger language around the 
>> Quiese-like feature.     Currently, it says the Relay "may" stop 
>> advertising the anycast.    If Relay has reached its capacity it 
>> "must" withdraw the Anycast or will black-hole traffic.
> Yes.

Questions:
- does the above address the case where discovery is not used and the 
Relay reaches its capacity ?
- isn't there an alternative to treat this case, such as not answering 
to Request messages ?  (or, if we want to avoid a delay for detecting an 
out-of-resources relay, we could add a special case of Query message 
with a flag carrying this semantic)
- isn't this alternative better suited to allow a Relay to have, for 
instance, a set of higher priority customer with a subset of dedicated 
ressources ? would we be ok with not allowing this ?

Let's be cautious about adding too much "MUSTs"...

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Tue, 18 Oct 2011 18:17:15 +0200

(replying to myself...)

>>>> "must" withdraw the Anycast or will black-hole traffic.

Well, for sure, we need to spell out that when discovery is used, and an 
anycast address is used just for this, then, if its known that the 
status is that the equipment will ignore any Discovery or Request, not 
withdrawing it will prevent the discovery mechanism to provide any fallback.

However, there is more to say if we look more closely. Withdrawing at 
once or starting to readvertise as soon as the equipment can handle more 
may create uncontrolled load on routing protocols. Also, withdrawing the 
prefix may not be the only option (higher metric comes to mind, although 
not applicable in all contexts).

So, I think we need more than "MUST withdraw anycast address if out of 
resources", and have a quite open text hinting that withdrawing the 
anycast address and relying on discovery is one way of handling Relay 
out-of-resources cases, but not necessarily the only one.

>> Relay reaches its capacity ?

Nope.

>> - isn't there an alternative to treat this case, such as not 
>> answering to Request messages ?  (or, if we want to avoid a delay for 
>> detecting an out-of-resources relay, we could add a special case of 
>> Query message with a flag carrying this semantic)

There would remain one issue: how do clients fall-back and try another 
Relay ?

>> instance, a set of higher priority customer with a subset of 
>> dedicated ressources ? would we be ok with not allowing this ?

Allowing some fallback in this case could be done with, additionally to 
the above (request timeout or query flag), some DNS round-robin.

-Thomas

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Thu, 20 Oct 2011 18:44:39 +0000

Thomas,

Here is feedback (primarily from Pat McCrink and myself) on your response.

1) Original comment 2 (Regarding the text about sourcing of MC behind a GW) - this comment I think referred to some text in section 2.  However, upon re-reading section 2 I think it is fine (it explains the history and differences) so ignore this comment.

2) Original comment 3 (consistent use of terminology) - the reasoning is to absolutely remove any and all ambiguity.  Not all readers will have the same level of expertise,  and even those that do might apply a slightly different interpretation based on context.  This is a standards document and being precise and admittedly even slightly pedantic is the safer course to take.

4) Original comment 4 (using operators Anycast) - OK,  it sounds like you are addressing it.  Based on your comments,  with which I agree,  it is an example of a way to do it.  Any clarification of that point would probably suffice.

5) Original comment 7 (section 6.5.2) - I had the same thought about it being a MUST,  but as you say leave as a SHOULD

6) Original comment 8 - OK 

7) Original comment 9 - IF the text is general and allows for different GW implementations that is fine.  GW implementers will need to understand the implications of different approaches and perhaps this should be noted in the text.

8) Original comment 10  - the issue we have is that the spec has a specific example that is not all inclusive. We don't need the IGMP specifics,  just a generic explanation that if GW determines that Relay is not responding it can attempt a Discovery again.

Regarding your questions:
- does the above address the case where discovery is not used and the 
Relay reaches its capacity ?
RJS/PM>> If GW attempts to join an S,G without using discovery and the Relay is at capacity, the Relay may choose to not reply to the AMT Request message.   In this case, it looks like a Relay failure case and the GW can do discovery to find an available Relay.   Alternatively, the Relay may reply to the AMT Request message but not deliver the S,G stream.   In this case, it would be up to the application to handle the failure.   This is why our GW will do a Discovery at the beginning of every new S,G request but this behavior can be left up to the GW implementer.

RJS/PM>> We do not favor the idea of any additional flags in Query message for this version.

- isn't this alternative better suited to allow a Relay to have, for 
instance, a set of higher priority customer with a subset of dedicated 
resources ? would we be ok with not allowing this ?
RJS/PM>>This is a new topic - prioritization of customers.   This is out of scope for this version.   Also, there could be other approaches to handling high priority customers (e.g. such as using a different anycast, etc).   In any case, we don't think this is a topic that should be incorporated into this version that we are trying to firm up and move to RFC

Regards,
Bob and Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Morin
Sent: Tuesday, October 18, 2011 5:20 AM
To: [email-masked]
Subject: Re: [MBONED] AMT Tunneling Draft 11

Hi Bob, Greg,

Questions:

-Thomas

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Thu, 20 Oct 2011 18:53:06 +0000

Thomas, Greg,

In the case where the Relay doesn't respond to the AMT Request, the text already covers the failover.   The only case that is left is where the Relay responds to the AMT Request but then does not deliver the S,G stream.

We discourage the use of additional flags or anything that changes the AMT Control messages at this point.   Our suggestion is to  leave the text open for implementers.  We now have significant implementation experience here and based on that we would like to suggest a best-practices (based on our experience) that includes the following:

1) A GW implementation should always Discover at the start of each new S,G join.   This will add a little to the join latency but will ensure that the GW reaches the optimal Relay that has capacity.
2) A Relay implementation should withdraw its anycast address when it reaches its predetermined threshold.   Of course, this can have some mechanisms to prevent route flapping.
3) An application that is requesting the multicast S,G should have its own failover mechanism (e.g. switching or filling in with unicast) in case there is no S,G stream delivered or there is packet loss on the S,G stream.

These do not need to be MUSTs or requirements in the AMT draft - it can be left open to implementor with the exception that:  if the Relay is relying upon Discovery than it should withdraw its anycast address in the event that it is at capacity.  

Regards,
Pat and  AT&T AMT Team.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Morin
Sent: Tuesday, October 18, 2011 12:17 PM
To: [email-masked]
Subject: Re: [MBONED] AMT Tunneling Draft 11

(replying to myself...)

Nope.

-Thomas

---

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Thu, 20 Oct 2011 18:55:20 +0000

Will be this draft be able to go to IESG at next IEFT?

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 20 Oct 2011 13:33:37 -0700

Bob,

I hope so. I think we're solidly on track to consensus on the final
changes. When Greg & Thomas incorporate and send the diffs to the
list, we can then have a final list review before reving and
publishing. One of them can present in Taipei and we go WGLC w/ the
rest of the WG support.

Thanks!,
Greg

---

From: Greg Bumgardner <[email-masked]>
Date: Thu, 20 Oct 2011 15:02:05 -0700

Robert, et. al.,

Again, thanks for the feedback. Comments in line...

-g.b.

> We discourage the use of additional flags or anything that changes the AMT Control messages at this point.   Our suggestion is to  leave the text open for implementers.  We now have significant imp…
The next version of the draft will include a couple of new flags in the 
control messages. Existing implementations will not be affected by the 
addition of these flags, but they are required to address issues related 
to the choice of group membership protocol and teardown. This topic was 
discussed in the mboned session at the last IETF meeting.
> 1) A GW implementation should always Discover at the start of each new S,G join.   This will add a little to the join latency but will ensure that the GW reaches the optimal Relay that has capacity.
I will have to disagree with you on this one. Some gateway 
implementations/deployments may chose not to employ any sort of 
discovery process. This topic was also addressed at the last IETF 
session (and the one before that). Whether a gateway should attempt 
discovery prior to sending a new request is an implementor/vendor 
decision. Some gateway implementations may choose to use an alternative 
method for acquiring a relay address that does not involve the AMT 
protocol at all. The spec can address this issue in an informative 
manner or use some qualified requirements language (e.g. "MAY" do 
something). AT&T has chosen one possible solution - the spec should 
allow for others.

Additionally, the protocol as described in the current draft does not 
require a new request for each S,G join. A gateway may continue to use 
the same nonce/mac to send membership updates without executing a new 
three-handshake. There are several advantages to requiring a new 
request->query->update exchange for every membership state change, but 
that is not how the spec is currently written.
> 3) An application that is requesting the multicast S,G should have its own failover mechanism (e.g. switching or filling in with unicast) in case there is no S,G stream delivered or there is packet…
You guys have a nice solution to this problem, but I don't think this 
topic even needs to be mentioned in the spec as this functionality would 
be provided by the application-layer.
Yes.