Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Vijay Devarapalli-4
Hi Jari, Marco,

Section 4.3.1 talks about the new MAG figuring out if the MN supports
transient BCE functionality. This text was added in the previous version
after discussions between you and Marco.

There is no text currently in the draft that exactly describes what is
it that the MN needs to support. AFAIK, transient BCE can work without
any explicit support on the mobile node.

My understanding is that in a single radio handover, the MN does not
need to support anything in addition to what is required in RFC 5213.
For a dual radio handover, there is an additional benefit if the MN is
able to receive packets both on the old and the new interface for a
short while.

Or am I missing something?

Vijay
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
Hi Vijay,

Vijay Devarapalli wrote:

> Hi Jari, Marco,
>
> Section 4.3.1 talks about the new MAG figuring out if the MN supports
> transient BCE functionality. This text was added in the previous
> version after discussions between you and Marco.
>
> There is no text currently in the draft that exactly describes what is
> it that the MN needs to support. AFAIK, transient BCE can work without
> any explicit support on the mobile node.
>
> My understanding is that in a single radio handover, the MN does not
> need to support anything in addition to what is required in RFC 5213.
> For a dual radio handover, there is an additional benefit if the MN is
> able to receive packets both on the old and the new interface for a
> short while.
>
> Or am I missing something?
No, actually you describe this well and according to the description in
the draft about the MN's operation.
For dual radio, the MN benefits also if it is able to use the previous
interface while setting up the
new one.

marco

>
> Vijay

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Jari Arkko-2
Is some document change needed?

Jari

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Vijay Devarapalli-4
On 9/10/10 3:59 AM, Jari Arkko wrote:
> Is some document change needed?

Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
only if it knows the MN supports transient BCE. Two issues with this.

1. If its a single radio handover, nothing needs to be supported on the
MN. Just whatever is needed according to RFC 5213.

2. For a dual radio handover, to get the true benefit from transient
BCE, the MN needs to be able to receive packets on two interfaces at the
same time for a short while. If it does not do this, transient BCE would
still work, and the MN does benefit, but there will be some packet loss.

This is not really captured in the draft.

For the actual text changes, it is going to be hard for me to suggest
text changes since its been a year since I read the draft. I have to go
through it again. Marco would probably be able to come up with text
changes much more quickly.

Perhaps we should add a section on the mobile node support for transient
BCE and explain clearly what needs to be supported on the mobile node.

Vijay
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Laganier, Julien
Vijay Devarapalli wrote:

>
> On 9/10/10 3:59 AM, Jari Arkko wrote:
> > Is some document change needed?
>
> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
> only if it knows the MN supports transient BCE. Two issues with this.
>
> 1. If its a single radio handover, nothing needs to be supported on the
> MN. Just whatever is needed according to RFC 5213.
>
> 2. For a dual radio handover, to get the true benefit from transient
> BCE, the MN needs to be able to receive packets on two interfaces at
> the same time for a short while. If it does not do this, transient BCE
> would still work, and the MN does benefit, but there will be some packet loss.
>
> This is not really captured in the draft.
>
> For the actual text changes, it is going to be hard for me to suggest
> text changes since its been a year since I read the draft. I have to go
> through it again. Marco would probably be able to come up with text
> changes much more quickly.
>
> Perhaps we should add a section on the mobile node support for
> transient BCE and explain clearly what needs to be supported on the mobile node.

All of the NETLMM work has happened under the premise that the host is unmodified, and NETEXT has pushed this a bit further with only mandating that the IP stack is unmodified, e.g., quoting current NETEXT charter:

  The work in this charter is entirely internal to the network and does
  not affect host IP stack operation in any way (except perhaps through
  impacting packet forwarding capacity visible to the hosts). The working
  group is not allowed to specify new IP layer protocol mechanisms to
  signal mobility related events between the host and the network.

We should adhere to the same guidelines in this situation. Thus the only way for the BCE to work in the dual radio case is to have a logical interface that hides to the IP layer the two physical interfaces, as described in this draft from the NETEXT WG:

http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support

Thus we should add to the BCE draft a sentence that explains that for BCE to be beneficial in dual radio case it requires support for the logical interface, and reference the NETEXT draft.

--julien
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Vijay Devarapalli-4
On 9/10/10 3:20 PM, Laganier, Julien wrote:

> Vijay Devarapalli wrote:
>>
>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>> Is some document change needed?
>>
>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>> only if it knows the MN supports transient BCE. Two issues with this.
>>
>> 1. If its a single radio handover, nothing needs to be supported on the
>> MN. Just whatever is needed according to RFC 5213.
>>
>> 2. For a dual radio handover, to get the true benefit from transient
>> BCE, the MN needs to be able to receive packets on two interfaces at
>> the same time for a short while. If it does not do this, transient BCE
>> would still work, and the MN does benefit, but there will be some packet loss.
>>
>> This is not really captured in the draft.
>>
>> For the actual text changes, it is going to be hard for me to suggest
>> text changes since its been a year since I read the draft. I have to go
>> through it again. Marco would probably be able to come up with text
>> changes much more quickly.
>>
>> Perhaps we should add a section on the mobile node support for
>> transient BCE and explain clearly what needs to be supported on the mobile node.
>
> All of the NETLMM work has happened under the premise that the host is unmodified, and NETEXT has pushed this a bit further with only mandating that the IP stack is unmodified, e.g., quoting current NETEXT charter:
>
>    The work in this charter is entirely internal to the network and does
>    not affect host IP stack operation in any way (except perhaps through
>    impacting packet forwarding capacity visible to the hosts). The working
>    group is not allowed to specify new IP layer protocol mechanisms to
>    signal mobility related events between the host and the network.
>
> We should adhere to the same guidelines in this situation.

I wasn't suggesting otherwise.

> Thus the only way for the BCE to work in the dual radio case is to have a logical interface that hides to the IP layer the two physical interfaces, as described in this draft from the NETEXT WG:

No, that goes too far. The Netext logical interface is *one* way to do it.

> http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support
>
> Thus we should add to the BCE draft a sentence that explains that for BCE to be beneficial in dual radio case it requires support for the logical interface, and reference the NETEXT draft.

Fine with me. But we should avoid a normative dependency to this draft,
mainly based on the fact that it is just one way to hide the two
physical interfaces.

Vijay
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Laganier, Julien
Vijay Devarapalli wrote:

>
> On 9/10/10 3:20 PM, Laganier, Julien wrote:
> > Vijay Devarapalli wrote:
> >>
> >> On 9/10/10 3:59 AM, Jari Arkko wrote:
> >>> Is some document change needed?
> >>
> >> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient
> BCE
> >> only if it knows the MN supports transient BCE. Two issues with this.
> >>
> >> 1. If its a single radio handover, nothing needs to be supported on
> the
> >> MN. Just whatever is needed according to RFC 5213.
> >>
> >> 2. For a dual radio handover, to get the true benefit from transient
> >> BCE, the MN needs to be able to receive packets on two interfaces at
> >> the same time for a short while. If it does not do this, transient
> BCE
> >> would still work, and the MN does benefit, but there will be some
> packet loss.
> >>
> >> This is not really captured in the draft.
> >>
> >> For the actual text changes, it is going to be hard for me to
> suggest
> >> text changes since its been a year since I read the draft. I have to
> go
> >> through it again. Marco would probably be able to come up with text
> >> changes much more quickly.
> >>
> >> Perhaps we should add a section on the mobile node support for
> >> transient BCE and explain clearly what needs to be supported on the
> >> mobile node.
> >
> > All of the NETLMM work has happened under the premise that the host
> > is unmodified, and NETEXT has pushed this a bit further with only
> > mandating that the IP stack is unmodified, e.g., quoting current NETEXT
> > charter:
> >
> >    The work in this charter is entirely internal to the network and does
> >    not affect host IP stack operation in any way (except perhaps through
> >    impacting packet forwarding capacity visible to the hosts). The working
> >    group is not allowed to specify new IP layer protocol mechanisms to
> >    signal mobility related events between the host and the network.
> >
> > We should adhere to the same guidelines in this situation.
>
> I wasn't suggesting otherwise.
>
> > Thus the only way for the BCE to work in the dual radio case is to
> > have a logical interface that hides to the IP layer the two physical
> > interfaces, as described in this draft from the NETEXT WG:
>
> No, that goes too far. The Netext logical interface is *one* way to do
> it.

Clarifying: I am not saying a logical interface is the only way for BCE to work with dual interfaces. One could of course modify an IP stack to get it to work. All I'm saying is that, to the extent that the IP layer is unmodified, you need a logical interface to hide the two physical interfaces for BCE, otherwise it can't work with a generic IP stack.

> > http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support
> >
> > Thus we should add to the BCE draft a sentence that explains that for
> > BCE to be beneficial in dual radio case it requires support for the
> > logical interface, and reference the NETEXT draft.
>
> Fine with me. But we should avoid a normative dependency to this draft,
> mainly based on the fact that it is just one way to hide the two
> physical interfaces.

Clarifying: I wasn't suggesting to add a normative dependency to the draft -- the logical interface draft is not normative anyway, it is meant to become an informational document that explains the requirements that needs to be satisfied when designing a logical interface.

--julien
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Vijay Devarapalli-4
Hi Vijay,

Vijay Devarapalli wrote:

> On 9/10/10 3:59 AM, Jari Arkko wrote:
>> Is some document change needed?
>
> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
> only if it knows the MN supports transient BCE. Two issues with this.
>
> 1. If its a single radio handover, nothing needs to be supported on
> the MN. Just whatever is needed according to RFC 5213.
>
> 2. For a dual radio handover, to get the true benefit from transient
> BCE, the MN needs to be able to receive packets on two interfaces at
> the same time for a short while. If it does not do this, transient BCE
> would still work, and the MN does benefit, but there will be some
> packet loss.
>
> This is not really captured in the draft.
>
> For the actual text changes, it is going to be hard for me to suggest
> text changes since its been a year since I read the draft. I have to
> go through it again. Marco would probably be able to come up with text
> changes much more quickly.
We had a section on MN operation in until version 03, but removed it
according to a proposal.
I am ok with including such section again and will propose text.

Thanks,
marco

>
> Perhaps we should add a section on the mobile node support for
> transient BCE and explain clearly what needs to be supported on the
> mobile node.
>
> Vijay

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Vijay Devarapalli-4
Hi Vijay,

please find some text for a revived section 4.7 MN Operation below.
Text in section 4.3.1 could then refer to this new section 4.7 to
link context.

4.7.  MN operation

  For single-radio handover, this specification does not require any
  extended mode of operation on the MN when compared to [RFC5213].

  During dual-radio handover, the MN benefits most from the transient
  BCE extension to PMIPv6 when it is able to keep communication on the
  previous interface while it is setting up its handover target
  interface with the configuration context which has been received as a
  result of the new interface's attachment to the nMAG.  Various
  techniques enable support for such operation, e.g. the use of a
  virtual interface on top of physical radio interfaces or
  implementation specific extensions to the MN's protocol stack.
  Details about how to enable such make-before-break support on the MN
  are out of scope of this document.


marco


Vijay Devarapalli wrote:

> On 9/10/10 3:59 AM, Jari Arkko wrote:
>> Is some document change needed?
>
> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
> only if it knows the MN supports transient BCE. Two issues with this.
>
> 1. If its a single radio handover, nothing needs to be supported on
> the MN. Just whatever is needed according to RFC 5213.
>
> 2. For a dual radio handover, to get the true benefit from transient
> BCE, the MN needs to be able to receive packets on two interfaces at
> the same time for a short while. If it does not do this, transient BCE
> would still work, and the MN does benefit, but there will be some
> packet loss.
>
> This is not really captured in the draft.
>
> For the actual text changes, it is going to be hard for me to suggest
> text changes since its been a year since I read the draft. I have to
> go through it again. Marco would probably be able to come up with text
> changes much more quickly.
>
> Perhaps we should add a section on the mobile node support for
> transient BCE and explain clearly what needs to be supported on the
> mobile node.
>
> Vijay

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Laganier, Julien
Hi Marco,

Marco Liebsch wrote:

>
> Hi Vijay,
>
> please find some text for a revived section 4.7 MN Operation below.
> Text in section 4.3.1 could then refer to this new section 4.7 to
> link context.
>
> 4.7.  MN operation
>
>   For single-radio handover, this specification does not require any
>   extended mode of operation on the MN when compared to [RFC5213].
>
>   During dual-radio handover, the MN benefits most from the transient
>   BCE extension to PMIPv6 when it is able to keep communication on the
>   previous interface while it is setting up its handover target
>   interface with the configuration context which has been received as a
>   result of the new interface's attachment to the nMAG.  Various
>   techniques enable support for such operation, e.g. the use of a
>   virtual interface on top of physical radio interfaces or

I suggest:

"logical interface on top of physical radio interfaces [I-D. ietf-netext-logical-interface-support] or"

>   implementation specific extensions to the MN's protocol stack.
>   Details about how to enable such make-before-break support on the MN
>   are out of scope of this document.

--julien

> Vijay Devarapalli wrote:
> > On 9/10/10 3:59 AM, Jari Arkko wrote:
> >> Is some document change needed?
> >
> > Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
> > only if it knows the MN supports transient BCE. Two issues with this.
> >
> > 1. If its a single radio handover, nothing needs to be supported on
> > the MN. Just whatever is needed according to RFC 5213.
> >
> > 2. For a dual radio handover, to get the true benefit from transient
> > BCE, the MN needs to be able to receive packets on two interfaces at
> > the same time for a short while. If it does not do this, transient
> BCE
> > would still work, and the MN does benefit, but there will be some
> > packet loss.
> >
> > This is not really captured in the draft.
> >
> > For the actual text changes, it is going to be hard for me to suggest
> > text changes since its been a year since I read the draft. I have to
> > go through it again. Marco would probably be able to come up with
> text
> > changes much more quickly.
> >
> > Perhaps we should add a section on the mobile node support for
> > transient BCE and explain clearly what needs to be supported on the
> > mobile node.
> >
> > Vijay
>
> _______________________________________________
> Mipshop mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
  Hi Julien,

Am 13.09.2010 18:46, schrieb Laganier, Julien:

> Hi Marco,
>
> Marco Liebsch wrote:
>> Hi Vijay,
>>
>> please find some text for a revived section 4.7 MN Operation below.
>> Text in section 4.3.1 could then refer to this new section 4.7 to
>> link context.
>>
>> 4.7.  MN operation
>>
>>    For single-radio handover, this specification does not require any
>>    extended mode of operation on the MN when compared to [RFC5213].
>>
>>    During dual-radio handover, the MN benefits most from the transient
>>    BCE extension to PMIPv6 when it is able to keep communication on the
>>    previous interface while it is setting up its handover target
>>    interface with the configuration context which has been received as a
>>    result of the new interface's attachment to the nMAG.  Various
>>    techniques enable support for such operation, e.g. the use of a
>>    virtual interface on top of physical radio interfaces or
> I suggest:
>
> "logical interface on top of physical radio interfaces [I-D. ietf-netext-logical-interface-support] or"
I am not sure why we should have a reference to NetExt, as the approach
how to realize this
is not NetExt specific. Examples are given in the text. And: If a
reference is needed,
why NetExt and not MIF?

marco


>>    implementation specific extensions to the MN's protocol stack.
>>    Details about how to enable such make-before-break support on the MN
>>    are out of scope of this document.
> --julien
>
>> Vijay Devarapalli wrote:
>>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>>> Is some document change needed?
>>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>>> only if it knows the MN supports transient BCE. Two issues with this.
>>>
>>> 1. If its a single radio handover, nothing needs to be supported on
>>> the MN. Just whatever is needed according to RFC 5213.
>>>
>>> 2. For a dual radio handover, to get the true benefit from transient
>>> BCE, the MN needs to be able to receive packets on two interfaces at
>>> the same time for a short while. If it does not do this, transient
>> BCE
>>> would still work, and the MN does benefit, but there will be some
>>> packet loss.
>>>
>>> This is not really captured in the draft.
>>>
>>> For the actual text changes, it is going to be hard for me to suggest
>>> text changes since its been a year since I read the draft. I have to
>>> go through it again. Marco would probably be able to come up with
>> text
>>> changes much more quickly.
>>>
>>> Perhaps we should add a section on the mobile node support for
>>> transient BCE and explain clearly what needs to be supported on the
>>> mobile node.
>>>
>>> Vijay
>> _______________________________________________
>> Mipshop mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Laganier, Julien
  Hi Julien,

Am 13.09.2010 18:46, schrieb Laganier, Julien:

> Hi Marco,
>
> Marco Liebsch wrote:
>> Hi Vijay,
>>
>> please find some text for a revived section 4.7 MN Operation below.
>> Text in section 4.3.1 could then refer to this new section 4.7 to
>> link context.
>>
>> 4.7.  MN operation
>>
>>    For single-radio handover, this specification does not require any
>>    extended mode of operation on the MN when compared to [RFC5213].
>>
>>    During dual-radio handover, the MN benefits most from the transient
>>    BCE extension to PMIPv6 when it is able to keep communication on the
>>    previous interface while it is setting up its handover target
>>    interface with the configuration context which has been received as a
>>    result of the new interface's attachment to the nMAG.  Various
>>    techniques enable support for such operation, e.g. the use of a
>>    virtual interface on top of physical radio interfaces or
> I suggest:
>
> "logical interface on top of physical radio interfaces [I-D. ietf-netext-logical-interface-support] or"
I am not sure why we should have a reference to NetExt, as the approach
how to realize this
is not NetExt specific. Examples are given in the text. And: If a
reference is needed,
why NetExt and not MIF?

marco


>>    implementation specific extensions to the MN's protocol stack.
>>    Details about how to enable such make-before-break support on the MN
>>    are out of scope of this document.
> --julien
>
>> Vijay Devarapalli wrote:
>>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>>> Is some document change needed?
>>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>>> only if it knows the MN supports transient BCE. Two issues with this.
>>>
>>> 1. If its a single radio handover, nothing needs to be supported on
>>> the MN. Just whatever is needed according to RFC 5213.
>>>
>>> 2. For a dual radio handover, to get the true benefit from transient
>>> BCE, the MN needs to be able to receive packets on two interfaces at
>>> the same time for a short while. If it does not do this, transient
>> BCE
>>> would still work, and the MN does benefit, but there will be some
>>> packet loss.
>>>
>>> This is not really captured in the draft.
>>>
>>> For the actual text changes, it is going to be hard for me to suggest
>>> text changes since its been a year since I read the draft. I have to
>>> go through it again. Marco would probably be able to come up with
>> text
>>> changes much more quickly.
>>>
>>> Perhaps we should add a section on the mobile node support for
>>> transient BCE and explain clearly what needs to be supported on the
>>> mobile node.
>>>
>>> Vijay
>> _______________________________________________
>> Mipshop mailing list
>> [hidden email]
>> https://www.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Laganier, Julien
Hi Marco,

Marco Liebsch:

>
>   Hi Julien,
>
> Am 13.09.2010 18:46, schrieb Laganier, Julien:
> > Hi Marco,
> >
> > Marco Liebsch wrote:
> >> Hi Vijay,
> >>
> >> please find some text for a revived section 4.7 MN Operation below.
> >> Text in section 4.3.1 could then refer to this new section 4.7 to
> >> link context.
> >>
> >> 4.7.  MN operation
> >>
> >>    For single-radio handover, this specification does not require
> any
> >>    extended mode of operation on the MN when compared to [RFC5213].
> >>
> >>    During dual-radio handover, the MN benefits most from the
> transient
> >>    BCE extension to PMIPv6 when it is able to keep communication on
> the
> >>    previous interface while it is setting up its handover target
> >>    interface with the configuration context which has been received
> as a
> >>    result of the new interface's attachment to the nMAG.  Various
> >>    techniques enable support for such operation, e.g. the use of a
> >>    virtual interface on top of physical radio interfaces or
> > I suggest:
> >
> > "logical interface on top of physical radio interfaces [I-D. ietf-
> netext-logical-interface-support] or"
>
> I am not sure why we should have a reference to NetExt, as the approach
> how to realize this is not NetExt specific. Examples are given in the text.

I do not propose a reference to netext, I propose a reference to a document that describes exactly what you need, i.e., a logical interface that hides multiple physical interfaces. The examples you have are vague and having an _informational_ reference to a document that describes what is need is, well, informative.
 
> And: If a reference is needed, why NetExt and not MIF?

Because AFAIK MIF has no document describing a logical interface hiding multiple physical interfaces. And the reference is to a document, not a WG.

--julien
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
  Julien,

Am 13.09.2010 19:20, schrieb Laganier, Julien:

> Hi Marco,
>
> Marco Liebsch:
>>    Hi Julien,
>>
>> Am 13.09.2010 18:46, schrieb Laganier, Julien:
>>> Hi Marco,
>>>
>>> Marco Liebsch wrote:
>>>> Hi Vijay,
>>>>
>>>> please find some text for a revived section 4.7 MN Operation below.
>>>> Text in section 4.3.1 could then refer to this new section 4.7 to
>>>> link context.
>>>>
>>>> 4.7.  MN operation
>>>>
>>>>     For single-radio handover, this specification does not require
>> any
>>>>     extended mode of operation on the MN when compared to [RFC5213].
>>>>
>>>>     During dual-radio handover, the MN benefits most from the
>> transient
>>>>     BCE extension to PMIPv6 when it is able to keep communication on
>> the
>>>>     previous interface while it is setting up its handover target
>>>>     interface with the configuration context which has been received
>> as a
>>>>     result of the new interface's attachment to the nMAG.  Various
>>>>     techniques enable support for such operation, e.g. the use of a
>>>>     virtual interface on top of physical radio interfaces or
>>> I suggest:
>>>
>>> "logical interface on top of physical radio interfaces [I-D. ietf-
>> netext-logical-interface-support] or"
>>
>> I am not sure why we should have a reference to NetExt, as the approach
>> how to realize this is not NetExt specific. Examples are given in the text.
> I do not propose a reference to netext, I propose a reference to a document that describes exactly what you need, i.e., a logical interface that hides multiple physical interfaces.
Now I am a bit lost. Why is the virtual interfase the only approach to
solve this? And why should we
specify in this document how to solve it? Examples are given, including
the virtual interface
approach, even if they are vague.. Details about what's needed are in as
requested, details
about how to solve it should not be in.
Also: What we need is the described behaviour of the MN, not internal
details about
hiding or not hiding physical interfaces.

marco


> The examples you have are vague and having an _informational_ reference to a document that describes what is need is, well, informative.
>
>> And: If a reference is needed, why NetExt and not MIF?
> Because AFAIK MIF has no document describing a logical interface hiding multiple physical interfaces. And the reference is to a document, not a WG.

> --julien


_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Laganier, Julien
Marco Liebsch wrote:

>
>   [...]
> >>>>     virtual interface on top of physical radio interfaces or
> >>> I suggest:
> >>>
> >>> "logical interface on top of physical radio interfaces [I-D. ietf-
> >>>  netext-logical-interface-support] or"
> >>
> >> I am not sure why we should have a reference to NetExt, as the
> >> approach how to realize this is not NetExt specific. Examples are
> >> given in the text.
> >
> > I do not propose a reference to netext, I propose a reference to a
> > document that describes exactly what you need, i.e., a logical
> > interface that hides multiple physical interfaces.
>
> Now I am a bit lost.

I don't know why but let's give it a try?

> Why is the virtual interfase the only approach to solve this?

Who said the virtual interface is the only approach to solve this? I've said in another note that to the extent that the IETF does not specify NETLMM extensions that require changes to the IP layer on a host, you have to hide the multiple physical interfaces under a logical interface. I thought we agree about this.

> And why should we specify in this document how to solve it?

We are not specifying how to solve it, we are giving an _informative_ reference that explains what is this logical interface that you cite as an example of how to solve the dual radio issue.

> Examples are given, including the virtual interface approach, even if
> they are vague.. Details about what's needed are in as requested, details
> about how to solve it should not be in.

I do not follow this dichotomy. There are no details, there is an informative reference on what constitutes a logical interface.

> Also: What we need is the described behaviour of the MN, not internal
> details about hiding or not hiding physical interfaces.

Exactly what the netext document is supposed to be doing. Not describe an implementation, but the external behavior in terms of the network on one hand, and the IP layer on the host on the other hand.

--julien
_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Vijay Devarapalli-4
In reply to this post by Marco Liebsch-3
On 9/13/10 6:46 AM, Marco Liebsch wrote:

> Hi Vijay,
>
> please find some text for a revived section 4.7 MN Operation below.
> Text in section 4.3.1 could then refer to this new section 4.7 to
> link context.
>
> 4.7. MN operation
>
> For single-radio handover, this specification does not require any
> extended mode of operation on the MN when compared to [RFC5213].

Replace the above with

   For a single-radio handover, this specification does not require
   any additional functionality on the mobile node, when compared to
   [RFC 5213].

> During dual-radio handover, the MN benefits most from the transient
> BCE extension to PMIPv6 when it is able to keep communication on the
> previous interface while it is setting up its handover target
> interface with the configuration context which has been received as a
> result of the new interface's attachment to the nMAG. Various
> techniques enable support for such operation, e.g. the use of a
> virtual interface on top of physical radio interfaces or
> implementation specific extensions to the MN's protocol stack.
> Details about how to enable such make-before-break support on the MN
> are out of scope of this document.

Looks ok. BTW, I think its ok to include the reference to the NETEXT
draft for the virtual interface (see Julien's email).

Vijay

>
>
> marco
>
>
> Vijay Devarapalli wrote:
>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>> Is some document change needed?
>>
>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>> only if it knows the MN supports transient BCE. Two issues with this.
>>
>> 1. If its a single radio handover, nothing needs to be supported on
>> the MN. Just whatever is needed according to RFC 5213.
>>
>> 2. For a dual radio handover, to get the true benefit from transient
>> BCE, the MN needs to be able to receive packets on two interfaces at
>> the same time for a short while. If it does not do this, transient BCE
>> would still work, and the MN does benefit, but there will be some
>> packet loss.
>>
>> This is not really captured in the draft.
>>
>> For the actual text changes, it is going to be hard for me to suggest
>> text changes since its been a year since I read the draft. I have to
>> go through it again. Marco would probably be able to come up with text
>> changes much more quickly.
>>
>> Perhaps we should add a section on the mobile node support for
>> transient BCE and explain clearly what needs to be supported on the
>> mobile node.
>>
>> Vijay
>

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Jari Arkko-2
Will the text that we added about the network only doing this if it
knows that the mobile node is BCE-PMIP capable still stay?

Jari

Vijay Devarapalli kirjoitti:

> On 9/13/10 6:46 AM, Marco Liebsch wrote:
>> Hi Vijay,
>>
>> please find some text for a revived section 4.7 MN Operation below.
>> Text in section 4.3.1 could then refer to this new section 4.7 to
>> link context.
>>
>> 4.7. MN operation
>>
>> For single-radio handover, this specification does not require any
>> extended mode of operation on the MN when compared to [RFC5213].
>
> Replace the above with
>
>   For a single-radio handover, this specification does not require
>   any additional functionality on the mobile node, when compared to
>   [RFC 5213].
>
>> During dual-radio handover, the MN benefits most from the transient
>> BCE extension to PMIPv6 when it is able to keep communication on the
>> previous interface while it is setting up its handover target
>> interface with the configuration context which has been received as a
>> result of the new interface's attachment to the nMAG. Various
>> techniques enable support for such operation, e.g. the use of a
>> virtual interface on top of physical radio interfaces or
>> implementation specific extensions to the MN's protocol stack.
>> Details about how to enable such make-before-break support on the MN
>> are out of scope of this document.
>
> Looks ok. BTW, I think its ok to include the reference to the NETEXT
> draft for the virtual interface (see Julien's email).
>
> Vijay
>
>>
>>
>> marco
>>
>>
>> Vijay Devarapalli wrote:
>>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>>> Is some document change needed?
>>>
>>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>>> only if it knows the MN supports transient BCE. Two issues with this.
>>>
>>> 1. If its a single radio handover, nothing needs to be supported on
>>> the MN. Just whatever is needed according to RFC 5213.
>>>
>>> 2. For a dual radio handover, to get the true benefit from transient
>>> BCE, the MN needs to be able to receive packets on two interfaces at
>>> the same time for a short while. If it does not do this, transient BCE
>>> would still work, and the MN does benefit, but there will be some
>>> packet loss.
>>>
>>> This is not really captured in the draft.
>>>
>>> For the actual text changes, it is going to be hard for me to suggest
>>> text changes since its been a year since I read the draft. I have to
>>> go through it again. Marco would probably be able to come up with text
>>> changes much more quickly.
>>>
>>> Perhaps we should add a section on the mobile node support for
>>> transient BCE and explain clearly what needs to be supported on the
>>> mobile node.
>>>
>>> Vijay
>>
>
>

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Vijay Devarapalli-4
  Am 13.09.2010 23:48, schrieb Vijay Devarapalli:

> On 9/13/10 6:46 AM, Marco Liebsch wrote:
>> Hi Vijay,
>>
>> please find some text for a revived section 4.7 MN Operation below.
>> Text in section 4.3.1 could then refer to this new section 4.7 to
>> link context.
>>
>> 4.7. MN operation
>>
>> For single-radio handover, this specification does not require any
>> extended mode of operation on the MN when compared to [RFC5213].
>
> Replace the above with
>
>   For a single-radio handover, this specification does not require
>   any additional functionality on the mobile node, when compared to
>   [RFC 5213].
ok

>
>> During dual-radio handover, the MN benefits most from the transient
>> BCE extension to PMIPv6 when it is able to keep communication on the
>> previous interface while it is setting up its handover target
>> interface with the configuration context which has been received as a
>> result of the new interface's attachment to the nMAG. Various
>> techniques enable support for such operation, e.g. the use of a
>> virtual interface on top of physical radio interfaces or
>> implementation specific extensions to the MN's protocol stack.
>> Details about how to enable such make-before-break support on the MN
>> are out of scope of this document.
>
> Looks ok. BTW, I think its ok to include the reference to the NETEXT
> draft for the virtual interface (see Julien's email).
ok. Will post a version 8 then with that text and the reference.
marco


>
> Vijay
>
>>
>>
>> marco
>>
>>
>> Vijay Devarapalli wrote:
>>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>>> Is some document change needed?
>>>
>>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>>> only if it knows the MN supports transient BCE. Two issues with this.
>>>
>>> 1. If its a single radio handover, nothing needs to be supported on
>>> the MN. Just whatever is needed according to RFC 5213.
>>>
>>> 2. For a dual radio handover, to get the true benefit from transient
>>> BCE, the MN needs to be able to receive packets on two interfaces at
>>> the same time for a short while. If it does not do this, transient BCE
>>> would still work, and the MN does benefit, but there will be some
>>> packet loss.
>>>
>>> This is not really captured in the draft.
>>>
>>> For the actual text changes, it is going to be hard for me to suggest
>>> text changes since its been a year since I read the draft. I have to
>>> go through it again. Marco would probably be able to come up with text
>>> changes much more quickly.
>>>
>>> Perhaps we should add a section on the mobile node support for
>>> transient BCE and explain clearly what needs to be supported on the
>>> mobile node.
>>>
>>> Vijay
>>
>


_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Jari Arkko-2
  Hi Jari,

Am 14.09.2010 08:30, schrieb Jari Arkko:
> Will the text that we added about the network only doing this if it
> knows that the mobile node is BCE-PMIP capable still stay?

I guess you refer to the new text in 4.3.1, which came in since version
7. Yes. I think it
will stay and Vijay requested an addition section where to describe
*what* the
MN actually needs to support to be tBCE capable.

So, we keep the current text in 4.3.1 and refer to section 4.7 in this
context.

Is that ok?

marco


>
> Jari
>
> Vijay Devarapalli kirjoitti:
>> On 9/13/10 6:46 AM, Marco Liebsch wrote:
>>> Hi Vijay,
>>>
>>> please find some text for a revived section 4.7 MN Operation below.
>>> Text in section 4.3.1 could then refer to this new section 4.7 to
>>> link context.
>>>
>>> 4.7. MN operation
>>>
>>> For single-radio handover, this specification does not require any
>>> extended mode of operation on the MN when compared to [RFC5213].
>>
>> Replace the above with
>>
>>   For a single-radio handover, this specification does not require
>>   any additional functionality on the mobile node, when compared to
>>   [RFC 5213].
>>
>>> During dual-radio handover, the MN benefits most from the transient
>>> BCE extension to PMIPv6 when it is able to keep communication on the
>>> previous interface while it is setting up its handover target
>>> interface with the configuration context which has been received as a
>>> result of the new interface's attachment to the nMAG. Various
>>> techniques enable support for such operation, e.g. the use of a
>>> virtual interface on top of physical radio interfaces or
>>> implementation specific extensions to the MN's protocol stack.
>>> Details about how to enable such make-before-break support on the MN
>>> are out of scope of this document.
>>
>> Looks ok. BTW, I think its ok to include the reference to the NETEXT
>> draft for the virtual interface (see Julien's email).
>>
>> Vijay
>>
>>>
>>>
>>> marco
>>>
>>>
>>> Vijay Devarapalli wrote:
>>>> On 9/10/10 3:59 AM, Jari Arkko wrote:
>>>>> Is some document change needed?
>>>>
>>>> Yes, IMO. Section 4.3.1 talks about the nMAG creating a transient BCE
>>>> only if it knows the MN supports transient BCE. Two issues with this.
>>>>
>>>> 1. If its a single radio handover, nothing needs to be supported on
>>>> the MN. Just whatever is needed according to RFC 5213.
>>>>
>>>> 2. For a dual radio handover, to get the true benefit from transient
>>>> BCE, the MN needs to be able to receive packets on two interfaces at
>>>> the same time for a short while. If it does not do this, transient BCE
>>>> would still work, and the MN does benefit, but there will be some
>>>> packet loss.
>>>>
>>>> This is not really captured in the draft.
>>>>
>>>> For the actual text changes, it is going to be hard for me to suggest
>>>> text changes since its been a year since I read the draft. I have to
>>>> go through it again. Marco would probably be able to come up with text
>>>> changes much more quickly.
>>>>
>>>> Perhaps we should add a section on the mobile node support for
>>>> transient BCE and explain clearly what needs to be supported on the
>>>> mobile node.
>>>>
>>>> Vijay
>>>
>>
>>
>

_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
Reply | Threaded
Open this post in threaded view
|

Re: Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

Marco Liebsch-3
In reply to this post by Laganier, Julien
  Julien,

Am 13.09.2010 19:50, schrieb Laganier, Julien:

> Marco Liebsch wrote:
>>    [...]
>>>>>>      virtual interface on top of physical radio interfaces or
>>>>> I suggest:
>>>>>
>>>>> "logical interface on top of physical radio interfaces [I-D. ietf-
>>>>>   netext-logical-interface-support] or"
>>>> I am not sure why we should have a reference to NetExt, as the
>>>> approach how to realize this is not NetExt specific. Examples are
>>>> given in the text.
>>> I do not propose a reference to netext, I propose a reference to a
>>> document that describes exactly what you need, i.e., a logical
>>> interface that hides multiple physical interfaces.
>> Now I am a bit lost.
> I don't know why but let's give it a try?
>
>> Why is the virtual interfase the only approach to solve this?
> Who said the virtual interface is the only approach to solve this?
When you write that 'this is what we need', it can be understood that way.


>   I've said in another note that to the extent that the IETF does not specify NETLMM extensions that require changes to the IP layer on a host, you have to hide the multiple physical interfaces under a logical interface. I thought we agree about this.
>
>> And why should we specify in this document how to solve it?
> We are not specifying how to solve it, we are giving an _informative_ reference that explains what is this logical interface that you cite as an example of how to solve the dual radio issue.
the document you refer to comprises text about solving certain things
with a virtual interface. So, it's a solution, isn't it?
But I have no problem with adding this.


>> Examples are given, including the virtual interface approach, even if
>> they are vague.. Details about what's needed are in as requested, details
>> about how to solve it should not be in.
> I do not follow this dichotomy.
I don't know why, but let's give it a try ;-) ..

>   There are no details, there is an informative reference on what constitutes a logical interface.
ok

>> Also: What we need is the described behaviour of the MN, not internal
>> details about hiding or not hiding physical interfaces.
> Exactly what the netext document is supposed to be doing. Not describe an implementation, but the external behavior in terms of the network on one hand, and the IP layer on the host on the other hand.
ok

marco

> --julien


_______________________________________________
Mipshop mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/mipshop
12