Subject: [Mipshop] draft-ietf-mipshop-transient-bce-pmipv6-05

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Aug 2010 13:49:31 +0300

I talked to Marco at the IETF and we came up with a way forward. The new 
text is in the I-D that is in the directories, here are the changes:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-mipshop-transient-bce-pmipv6-06.txt

This satisfies, in principle, my earlier complaints. I would ask though 
the following text to be changed:

OLD:
Where no support from the link layer exists and no such indication can 
be provided to the nMAG by the network, the host and the network may 
need to inform each other about the intended movement. The method by 
which this is accomplished is outside the scope of this specification.
NEW:
Where no support from the link layer exists and no such indication can 
be provided to the nMAG by the network, the nMAG MUST assume that the 
host is incapable of this mode of operation, and employ standard 
behaviour as specified in RFC 5213. In other words, provide a new 
attachment rather than move an existing attachment to a new point or 
interface.

I have asked for IETF last call to be initiated.

Jari

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 9 Aug 2010 15:41:10 +0200

Hi Jari,

thanks for your feedback. I am ok with a further revision of the new 
text, but I have
a comment to your proposal below. Please see inline.

Jari Arkko wrote:
> I talked to Marco at the IETF and we came up with a way forward. The 
> new text is in the I-D that is in the directories, here are the changes:
>
> This satisfies, in principle, my earlier complaints. I would ask 
> though the following text to be changed:
>
> OLD:
I think the last sentence is not what RFC5213 will do, as we're talking 
about indications about the host's
capability to support transient BCEs. Fallback is not to assume a new 
attachment, but still there may
be knowledge about a change of an interface (HI = 2), hence a regular 
RFC5213 dual radio handover
will be performed. What about just omitting the last sentence and stop 
after "...RFC5213"?

marco

> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 09 Aug 2010 10:31:17 -0700

This specific block of text is fine, w.r.t to the default multihoming
behavior in the absence of link-layer triggers.

Sri

---

From: "BLUME, Oliver" <[email-masked]>
Date: Tue, 24 Aug 2010 13:31:39 +0200

Thanks, Jari, for the proposal of the new text. 

I am fine to explicitely state the fall back to RFC5213 if the network does not have indication of tBCE support. However it should be clear that this refers to a RFC5213 handover and does not imply to handle the attachment as a new session. So I support Marco's request to drop the last sentence. I tried to modify the replacement text to capture this:

OLD:
Where no support from the link layer exists and no such
indication can be provided to the nMAG by the network, the host
and the network may need to inform each other about the intended
movement.  The method by which this is accomplished is outside the
scope of this specification.  

NEW:
Where no support from the link layer exists and no such 
indication can be provided to the nMAG by the network, the nMAG
MUST assume that the host is incapable of this mode of operation,
and employ standard behaviour as specified in RFC 5213. In other 
words, nMAG initiates a regular RFC5213 handover.

[then continue with ] The nMAG is also a suitable ...

I hope this settles the issue.

Thanks,

Oliver

>-----Ursprüngliche Nachricht-----
>Von: [email-masked] 
>[mailto:[email-masked]] Im Auftrag von Sri Gundavelli
>Gesendet: Montag, 9. August 2010 19:31
>An: Jari Arkko; Marco Liebsch; Mipshop
>Betreff: Re: [Mipshop] draft-ietf-mipshop-transient-bce-pmipv6-05
>
>This specific block of text is fine, w.r.t to the default 
>multihoming behavior in the absence of link-layer triggers.
>
>Sri
>
>
>
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-mipshop-transient
>-bce-pmipv6-06.
>> txt
>>