Subject: [Mipshop] Section 4.3.1 of draft-ietf-mipshop-transient-bce-pmipv6

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 09 Sep 2010 11:30:10 -0700

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

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 10 Sep 2010 10:37:29 +0200

Hi Vijay,

Vijay Devarapalli wrote:
> transient BCE functionality. This text was added in the previous 
> version after discussions between you and Marco.
>
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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Sep 2010 13:59:51 +0300

Is some document change needed?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Sep 2010 15:07:08 -0700

> 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

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 10 Sep 2010 15:20:55 -0700

Vijay Devarapalli wrote:
> 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.
> 
> 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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 10 Sep 2010 15:49:23 -0700

On 9/10/10 3:20 PM, Laganier, Julien wrote:
> 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.

> 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

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 10 Sep 2010 16:07:05 -0700

Vijay Devarapalli wrote:
> > 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:
> >
> > 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:
> 

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. 

> > 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.
> 

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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Sep 2010 12:08:52 +0200

Hi Vijay,

Vijay Devarapalli wrote:
> 1. If its a single radio handover, nothing needs to be supported on 
> the MN. Just whatever is needed according to RFC 5213.
>
> 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 
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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Sep 2010 15:46:30 +0200

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

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 09:46:26 -0700

Hi Marco,

>   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"

--julien

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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Sep 2010 19:13:36 +0200

Hi Julien,

> "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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Sep 2010 19:13:44 +0200

Hi Julien,

marco

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 10:20:00 -0700

Hi Marco,

Marco Liebsch:
> 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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 13 Sep 2010 19:29:27 +0200

Julien,

Am 13.09.2010 19:20, schrieb Laganier, Julien:
> 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.
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 10:50:13 -0700

Marco Liebsch wrote:
>   [...]
> >> 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

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

> 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

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Sep 2010 14:48:40 -0700

> 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].

> 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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Sep 2010 09:30:20 +0300

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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 14 Sep 2010 09:23:31 +0200

>   any additional functionality on the mobile node, when compared to
ok

> draft for the virtual interface (see Julien's email).
ok. Will post a version 8 then with that text and the reference.
marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 14 Sep 2010 09:27:51 +0200

Hi Jari,

> 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

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 14 Sep 2010 09:36:59 +0200

Julien,

Am 13.09.2010 19:50, schrieb Laganier, Julien:
> 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.
>
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.

> 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

ok

marco

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Sep 2010 13:26:20 +0300

OK

Marco Liebsch kirjoitti:
> I guess you refer to the new text in 4.3.1, which came in since 
> version 7. Yes. I think it