Subject: [MBONED] Discuss on draft-ietf-mboned-auto-multicast-14

From: Greg Bumgardner <[email-masked]>
Date: Mon, 1 Apr 2013 12:13:47 -0700

Hi All,

I've attached the draft I had intended to submit prior to the last IETF
meeting (missed cutoff by 20 mins - forgot about UTC). I have been asked to
distribute this text for review by the ISEG discussion participants prior
to submission as additional changes may be required. This version of the
document corrects various typos, etc., and includes new text in which I
attempted to address concerns raised by several reviewers. I have been told
that there have been some off-line discussions (in Orlando) regarding some
open issues in which some consensus has been reached regarding how these
should be addressed in the document. I would appreciate feedback as to
whether the new text is acceptable and suggestions as to what might be
added or changed as a result of any off-line discussions.

I've copied the mboned group so that they may see the latest changes -
group members should reply to me and [email-masked] if they have questions
or comments.

Thanks,

-g.b.

-- 
Greg Bumgardner
Eugene, OR

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 Apr 2013 11:32:06 +0200

Hi Greg,

I will read through it until Friday evening.

Thanks!

   Martin

On 04/01/2013 09:13 PM, Greg Bumgardner wrote:
> meeting (missed cutoff by 20 mins - forgot about UTC). I have been asked
> to distribute this text for review by the ISEG discussion participants
> prior to submission as additional changes may be required. This version
> of the document corrects various typos, etc., and includes new text in
> which I attempted to address concerns raised by several reviewers. I
> have been told that there have been some off-line discussions (in
> Orlando) regarding some open issues in which some consensus has been
> reached regarding how these should be addressed in the document. I would
> appreciate feedback as to whether the new text is acceptable and
> suggestions as to what might be added or changed as a result of any
> off-line discussions.
>
> group members should reply to me and [email-masked]
> <mailto:[email-masked]> if they have questions or comments.
>
> Thanks,
>
> -g.b.
>
> --
> Greg Bumgardner
> Eugene, OR

-- 
[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 8 Apr 2013 13:04:53 +0200

Hi Greg,

- Section 4.1.4.2. is a good start and documents the challenges. 
However, there has been also the proposal from Gorry/me (sent in a 
private email) about adding a circuit breaker to the protocol. E.g., 
adding a protocol mechanism that allows relays to exchange some basic 
information such as x packet sent in the last second, so that the other 
end can detect if it has received less than x or x packets.

- Section 4.2.2.4 looks rather incomplete as it basically only describes 
the IPv4 case. Is this intentionally?

   Martin

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: "Greg Shepherd (shep)" <[email-masked]>
Date: Mon, 8 Apr 2013 13:43:23 +0000

Martin,

Any circuit-breaker mechanism should be described in its own draft, and not within this one. Gorry and I agreed in Orlando that a paragraph warning of non-CG traffic would be sufficient. I hope this view has not changed.

Thanks,
Greg

On Apr 8, 2013, at 4:04 AM, Martin Stiemerling <[email-masked]>
 wrote:

> Hi Greg,
> 
> - Section 4.1.4.2. is a good start and documents the challenges. However, there has been also the proposal from Gorry/me (sent in a private email) about adding a circuit breaker to the protocol. E.g., adding a protocol mechanism that allows relays to exchange some basic information such as x packet sent in the last second, so that the other end can detect if it has received less than x or x packets.
> 
> - Section 4.2.2.4 looks rather incomplete as it basically only describes the IPv4 case. Is this intentionally?
> 
>  Martin
>

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 22 Apr 2013 17:44:12 +0200

On 04/08/2013 03:43 PM, Greg Shepherd (shep) wrote:
> Martin,
>
> Any circuit-breaker mechanism should be described in its own draft,
> and not within this one. Gorry and I agreed in Orlando that a
> paragraph warning of non-CG traffic would be sufficient. I hope this
> view has not changed.

The current statement is ok.

What about this question:
- Section 4.2.2.4 looks rather incomplete as it basically only describes 
the IPv4 case. Is this intentionally?

Otherwise, please post an updated version of the draft.

   Martin

>
> Thanks, Greg
>
> On Apr 8, 2013, at 4:04 AM, Martin Stiemerling
> <[email-masked]> wrote:
>
>> Hi Greg,
>>
>> private email) about adding a circuit breaker to the protocol.
>> E.g., adding a protocol mechanism that allows relays to exchange
>> some basic information such as x packet sent in the last second, so
>> that the other end can detect if it has received less than x or x
>> packets.
>>
>> - Section 4.2.2.4 looks rather incomplete as it basically only
>> describes the IPv4 case. Is this intentionally?
>>
>> Martin
>>
>>> I've attached the draft I had intended to submit prior to the
>>> last IETF meeting (missed cutoff by 20 mins - forgot about UTC).
>>> I have been asked to distribute this text for review by the ISEG
>>> discussion participants prior to submission as additional changes
>>> may be required. This version of the document corrects various
>>> typos, etc., and includes new text in which I attempted to
>>> address concerns raised by several reviewers. I have been told
>>> that there have been some off-line discussions (in Orlando)
>>> regarding some open issues in which some consensus has been
>>> reached regarding how these should be addressed in the document.
>>> I would appreciate feedback as to whether the new text is
>>> acceptable and suggestions as to what might be added or changed
>>> as a result of any off-line discussions.
>>>
>>> I've copied the mboned group so that they may see the latest
>>> changes - group members should reply to me and [email-masked]
>>> -- Greg Bumgardner Eugene, OR
>>
>> -- [email-masked]
>>
>> NEC Laboratories Europe NEC Europe Limited Registered Office:

NEC Laboratories Europe
NEC Europe Limited
Registered Office:

---

From: Greg Bumgardner <[email-masked]>
Date: Thu, 25 Apr 2013 10:14:46 -0700

Martin,

IPv6 is mentioned in the second paragraph though the description is pretty
vague - basically implying that, just as an IPv6 router is not supposed to
(re)fragment IPv6 datagrams, an AMT relay should not fragment data messages
that encapsulate non-fragmented datagrams.

I'll expand on this in the the paragraph in question, and will review the
normative description to see if it is adequate.

Thanks,

-g.b.

-- 
Greg Bumgardner
Eugene, OR

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 25 Apr 2013 19:19:22 +0200

On 04/25/2013 07:14 PM, Greg Bumgardner wrote:
> Martin,
>
> IPv6 is mentioned in the second paragraph though the description is
> pretty vague - basically implying that, just as an IPv6 router is not
> supposed to (re)fragment IPv6 datagrams, an AMT relay should not
> fragment data messages that encapsulate non-fragmented datagrams.
>
> I'll expand on this in the the paragraph in question, and will review
> the normative description to see if it is adequate.

ok, thanks and resubmit the updated version to see where we are.

Thanks,

   Martin

>
> Thanks,
>
> -g.b.
>
>
> On Mon, Apr 22, 2013 at 8:44 AM, Martin Stiemerling
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Greg,
>
>                 changes - group members should reply to me and
>                 [email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>> if
>                 they have questions or comments.
>
>                 Thanks,
>
>                 -g.b.
>
>             <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>
>     NEC Laboratories Europe
>     NEC Europe Limited
>     Registered Office:

NEC Laboratories Europe
NEC Europe Limited
Registered Office: