Subject: [netext] Requests received for agenda slots

From: <[email-masked]>
Date: Mon, 8 Mar 2010 18:46:32 +0100

Hello,

We have received the following requests for a timeslot at the IETF77
Netext WG meeting. Please let me know if I have missed any.

-Raj

1. Sri Gundavelli, I-D: Virtual interface use, 15 Mins
2. Carlos Cano, I-D: draft-bernardos-netext-pmipv6-nemo-ps-01, 10 mins
3. Mohana Jeyataharan
   a. draft-jeyatharan-netext-pmip-partial-handoff-v01, 10mins
   b. draft-jeyatharan-netext-pmip-dormant-binding-v00, 10mins
   c. draft-jeyatharan-netext-pmip-bulkpbu-bitmap-v00, 5mins
4. Jouni Korhonen, draft-ietf-netext-redirect-01, 5 mins
5. Hidetoshi Yokota, draft-yokota-netlmm-pmipv6-mn-itho-support-03, 10
   mins
6. Anthony Chan, draft-chan-netext-distributed-lma-02, 15 mins
7. Frank Xia, draft-xia-netext-radius-00, 10 mins
8. Fuad Junior, draft-ietf-netext-bulk-re-registration-00, 10 mins

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 8 Mar 2010 13:00:09 -0500

Hi Raj,

There is http://tools.ietf.org/html/draft-koodli-netext-flow-handover-01
on flow mobility.

10 minutes would be good.

Thanks,

-Rajeev

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, March 08, 2010 9:47 AM
> To: [email-masked]
> Subject: [netext] Requests received for agenda slots
> 
> 
> Hello,
> 
> We have received the following requests for a timeslot at the 
> IETF77 Netext WG meeting. Please let me know if I have missed any.
> 
> -Raj
> 
> 1. Sri Gundavelli, I-D: Virtual interface use, 15 Mins 2. 
> Carlos Cano, I-D: draft-bernardos-netext-pmipv6-nemo-ps-01, 
> 10 mins 3. Mohana Jeyataharan
> 4. Jouni Korhonen, draft-ietf-netext-redirect-01, 5 mins 5. 
> Hidetoshi Yokota, draft-yokota-netlmm-pmipv6-mn-itho-support-03, 10
>    mins
> 6. Anthony Chan, draft-chan-netext-distributed-lma-02, 15 
> mins 7. Frank Xia, draft-xia-netext-radius-00, 10 mins 8. 
> Fuad Junior, draft-ietf-netext-bulk-re-registration-00, 10 mins
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 19:05:54 +0100

Okay. Revised list:

9. Rajeev Koodli, draft-koodli-netext-flow-handover-01, 10 mins

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Mon, 8 Mar 2010 19:08:58 +0100

Hi Raj,

There will be the updated version of draft-melia-netext-muho-solution-00 directly related to the charter. 10 mins will be enough.

Thanks
telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 8 mars 2010 18:47
À : [email-masked]
Objet : [netext] Requests received for agenda slots

Hello,

-Raj

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 19:23:31 +0100

10. Telemaco Melia, draft-melia-netext-flow-mob-solution-00, 10 mins

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Mar 2010 11:02:10 -0800 (PST)

Hi Raj,
  I think we need a whole session to discuss flow mobility solutions, I don't think presenting bits and pieces would solve the problem.

Cheers,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Sent: Mon, March 8, 2010 12:23:31 PM
> Subject: Re: [netext] Requests received for agenda slots
> 
> 
2. Carlos Cano, 
> I-D: draft-bernardos-netext-pmipv6-nemo-ps-01, 10 mins
3. Mohana 
> Jeyataharan
  a. draft-jeyatharan-netext-pmip-partial-handoff-v01, 
> 10mins
  b. draft-jeyatharan-netext-pmip-dormant-binding-v00, 
> 10mins
4. 
> Jouni Korhonen, draft-ietf-netext-redirect-01, 5 mins
5. Hidetoshi Yokota, 
> draft-yokota-netlmm-pmipv6-mn-itho-support-03, 10
  mins
6. Anthony 
> Chan, draft-chan-netext-distributed-lma-02, 15 mins
7. Frank Xia, 
> draft-xia-netext-radius-00, 10 mins
8. Fuad Junior, 
> draft-ietf-netext-bulk-re-registration-00, 10 mins
9. Rajeev Koodli, 
> draft-koodli-netext-flow-handover-01, 10 mins
10. Telemaco Melia, 
> draft-melia-netext-flow-mob-solution-00, 10 
> mins

netext 
> mailing list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/netext" target=_blank

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 20:03:48 +0100

Hi Behcet,

We will post the agenda shortly. The list below is not the agenda. It is
just a list of requests received.

-Raj

On 3/8/10 1:02 PM, "ext Behcet Sarikaya" <[email-masked]> wrote:

> Hi Raj,
>   I think we need a whole session to discuss flow mobility solutions, I don't
> think presenting bits and pieces would solve the problem.
> 
> Cheers,
> 
> Behcet
> 
> 
>

---

From: Frank Xia <[email-masked]>
Date: Mon, 08 Mar 2010 15:52:38 -0600

Hi Raj

Sorry for this late request.

Because I saw a lot of colleagues request
presenting flow mobility, I would also like
to bring my solution
http://tools.ietf.org/id/draft-xia-netext-flow-binding-00.txt.

10 minutes are enough.

BR
Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 08, 2010 12:24 PM
To: [email-masked]
Subject: Re: [netext] Requests received for agenda slots

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Mar 2010 14:06:51 -0800 (PST)

Hi Raj,
  I am curious if items 1 and 5 are not pointing to the same draft :-)?

Regards,

Behcet

----- Original Message ----
3. Mohana 
5. Hidetoshi Yokota, 
  mins
6. Anthony 
7. Frank Xia, 
8. Fuad Junior, 
9. Rajeev Koodli, 
10. Telemaco Melia,

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 8 Mar 2010 18:37:58 -0500

Hi Raj,
   Can you allocate 15 mins for the presentation of 
draft-krishnan-netext-pmip-lr-01.

Thanks
Suresh

---

From: Yong-Geun Hong <[email-masked]>
Date: Tue, 9 Mar 2010 09:29:54 +0900

Hi, Raj.

I would like to have 10 minutes for
http://tools.ietf.org/id/draft-hong-netext-hybrid-hnp-01.txt
for multihoming and inter-technology handoff in PMIPv6.

Best regards.

Yong-Geun.

2010/3/9 <[email-masked]>

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 9 Mar 2010 09:38:03 +0900

Hi Raij,

I would like to request  5-10 minutes for the I-D:
http://tools.ietf.org/html/draft-trung-netext-virtual-interface-01
It is necessary for supporting flow mobility.

Regards,
TrungTM

--
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 9 Mar 2010 09:46:53 +0900

Hi Raij,

Sorry, I sent wrong link.
The draft is: http://tools.ietf.org/html/draft-trung-netext-flow-tracking-00

Regards,
TrungTM

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 08 Mar 2010 17:40:45 -0800

Thanks Behcet.

Yes. Yokota-san will use the first slot to present:

http://tools.ietf.org/html/draft-yokota-netlmm-pmipv6-mn-itho-support-03

Yes, Slot 5 can be cleared.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 08 Mar 2010 17:44:48 -0800

The authors of both the drafts, draft-yokota-netlmm-pmipv6-mn-itho-support
and draft-trung-netext-virtual-interface have decided to do joint work and
hence merged the drafts. Please see the merged draft at:

Comments welcome ! Hidetoshi Yokota will present the draft in the next
meeting.

Sri

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 09 Mar 2010 12:13:45 +0800

Dear Sri and other authors,

I'm reading this draft and I have some questions,

1) section 3, 
   From the perspective of the IP stack and the applications, a virtual
   interface is just another interface.  ... [ignored] ...
      o  The link-layer identifier of the virtual interface is used in the
      link-layer header of the IP packets sent through this interface,
      and the link-layer address of the physical interface will not be
      used.
   It seems that the id of the virtual interface is used as the id of link 
   layer in the host, but is it still right from the perspective of MAG?
   I am asking this question because in the LMA's Binding Table of
   Figure 2, the LL-ID for both binding is zzz. Does the MAG see
   the physical interface id of the host? or the MAG knows both but 
   doesn't use the physical interface id?

2)    o  The host has path awareness for the hosted prefixes based on the
      received Router Advertisement messages.  Any packets with source
      address generated using HNP_1 will be routed through the interface
      if_1 and for packets using source address from HNP_2 will be
      routed through the interface if_2.
      This paragraph is still in the perspective of MN, in my understanding,
      handover between IF1 and IF2 means the session of 
      (HNP-1::zzz/128, CN) is moved to IF2 from IF1, so after the handover, 
      the packets (source ip = HNP-1::zzz/128, destination ip = CN) should
      be transmitted through IF2, that seems conflicting with the above rule?
      
      I supposed the virtual interface can only mapping the id of link layer,
      but not id of IP layer (i.e., IP address), so the application of the host
      can see the IP address of the IFs. If the virtual interface translates IP
      address, too, the application would see only one IP address of the 
      virtual interface, but can not see the real IP addresses of the IFs, at 
      this time, multihoming is not applicable for the application?
      Is that right?

3)  in the initiate registration, does MAG know the capability of multihoming
     of the mobile node? and explicitly indicate that to LMA? What is the value
     of HI in the Handoff Indicator Option?
     During the handover, is there any change in the parameter options of 
     PBU (I assumed the MAG use PBU to tell handover to the LMA)?

Thanks and regards
Xiangsong

---

From: liu dapeng <[email-masked]>
Date: Tue, 9 Mar 2010 12:27:06 +0800

Hi Raj,

We have posted a draft:
http://tools.ietf.org/search/draft-liu-netext-flow-pmip-01, it is
related to flow mobility which is in current charter's scope.

5 minutes will be sufficient if it is possible. thanks .

BR,
Dapeng Liu

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 09 Mar 2010 14:49:00 +0900

Hi Xiangsong,

Thanks for your reading our draft so quickly:-). The basic standpoint of
this draft is to specify the behavior of the MN when the virtual
interface approach is taken. Those of the PMIP nodes (either MAG or LMA)
are not mentioned and there is no signaling or protocol defined between
the MN and other nodes. This does not mean that such signaling is not
needed, but this draft just does not cover that aspect.

Please also see inline:

(2010/03/09 13:13), Xiangsong Cui wrote:
> 1) section 3, From the perspective of the IP stack and the applications, 
> a virtual
> the physical interface id of the host? or the MAG knows both but doesn't 
> use the physical interface id?

The MAG only sees one link-layer ID, i.e., ZZZ. The assumption here is
that both if_1 and if_2 use ZZZ as the LL_ID for sending packets and can
receive ones destined for that LL_ID as well.

> This paragraph is still in the perspective of MN, in my understanding,

Yes, that is our intention.

> handover between IF1 and IF2 means the session of (HNP-1::zzz/128, CN) 
> is moved to IF2 from IF1, so after the handover, the packets (source ip 
> = HNP-1::zzz/128, destination ip = CN) should

Section 4.1 describes the multihoming case, not the handover one, for
which Section 4.2 is that.

> can see the IP address of the IFs. If the virtual interface translates IP

The assumption here is that an IP address is assigned only to the
virtual interface. There is no need to assign one to the physical
interface(s). When you use Linux, for instance, you can set up a
(virtual) bridge interface and bind it to one or more physical
interface(s). Then the above configuration can be done disarmingly
easily. See [Net:Bridge] for more information. Note that this is only
one implementation example and not exclusive.

> this time, multihoming is not applicable for the application?

IP addresses assigned to the virtual interface are visible to upper
layer applications. If multiple IP addresses are assigned to the VI,
then such addresses can be seen and used by those applications.

> During the handover, is there any change in the parameter options of PBU 
> (I assumed the MAG use PBU to tell handover to the LMA)?

This document does not specify how the LMA and MAG should behavior. Any
protocol or signaling for the capability exchange between the MN and MAG
is not mentioned, either. So far, those are beyond the scope of this
document. However, we should discuss it on the ML and in the meeting and
strive to sort them out.

Regards,
-- 
Hidetoshi

> Thanks and regards
> Xiangsong
> 
> ----- Original Message ----- From: "Sri Gundavelli" <[email-masked]>
> To: <[email-masked]>
>> The authors of both the drafts, 
>> draft-yokota-netlmm-pmipv6-mn-itho-support

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 09 Mar 2010 14:32:10 +0800

Hi Hidetoshi,

Also thanks for your quick response :)
please see my comments inline.

Regards
Xiangsong

----- Original Message ----- 
From: "Hidetoshi Yokota" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 09, 2010 1:49 PM
Subject: Re: [netext] Virtual Interface Drafts - Merged draft

[skip]

> receive ones destined for that LL_ID as well.

OK, get it!

> Yes, that is our intention.

Sorry for the confusion, I wanted to say: 
This paragraph is still in the perspective of MN.
And, in my understanding, blabla.......

> which Section 4.2 is that.

Yes, section 4.2 is for handover, but I still don't understand that.
The beginning of section 4.2 says:
  "The Proxy Mobile IPv6 protocol enables a mobile node with multiple
   network interfaces to move between access technologies, but still
   retaining the same address configuration on its attached interface."
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does the attached interface means virtual interface of physical interface?
And, after the handover, does IF2 of MN still use HNP-2::zzz/128 
which is assigned to IF2 in Figure 2?
Or in figure 3, MAG2 advertises HNP-1 to IF2 and the IP address
of the physical interface IF2 changes to HNP-1::zzz/128?
If  IF2 sitll use HNP-2, the physical interface can not transimit 
packets of HNP-1 as the rule of section 4.1.
So my question: is there some uncompatibility between section 4.1 and 4.2?

[skip]

> document. However, we should discuss it on the ML and in the meeting and

I see.

Thanks, Xiangsong

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 09 Mar 2010 22:30:21 +0900

Hi Xiangsong,

Please see inline:

(2010/03/09 15:32), Xiangsong Cui wrote:
> ----- Original Message ----- From: "Hidetoshi Yokota" <[email-masked]>
> To: <[email-masked]>
> Sorry for the confusion, I wanted to say: This paragraph is still in the 
> perspective of MN.
>>> handover between IF1 and IF2 means the session of (HNP-1::zzz/128, 
>>> CN) is moved to IF2 from IF1, so after the handover, the packets 
>>> (source ip = HNP-1::zzz/128, destination ip = CN) should

The assumption here is that the physical interface attaches to the
physical link, but the address is configured on the virtual interface.
Therefore, even if the physical interfaces are switched, the same
address configuration can be maintained.

Please note that from the perspective of the MAG and LMA, they would not
know if the MN uses a virtual interface or not.

> And, after the handover, does IF2 of MN still use HNP-2::zzz/128 which 
> is assigned to IF2 in Figure 2?

I think this may fall into the flow mobility case in Section 4.3.
Anyway, if flow mobility is supported, the MN should be able to keep
using HNP-2::zzz/128 regardless of the migration of other addresses.

> If IF2 sitll use HNP-2, the physical interface can not transimit packets 
> of HNP-1 as the rule of section 4.1.

I would put it that IP address is assigned to the virtual interface not
to the physical ones, and in your case, both HNP-1::zzz/128 and
HNP-2::zzz/128 can be used via IF_2.

> So my question: is there some uncompatibility between section 4.1 and 4.2?

A combination of section 4.1 and 4.2 may become the flow mobility
case... If the virtual interface can have multiple addresses, which is
no brainer nowadays, and knows which interface should be used for each
flow, then there should not be any ambiguity. I admit that things are
getting complex and there could be something I overlooked. Any further
question is welcome to help us clarify the applicability of the virtual
interface.

Regards,
-- 
Hidetoshi

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 10 Mar 2010 09:51:42 +0800

Dear Hidetoshi,

Thank you very much for your detailed explanation,
I think I have understood the draft, and I will read 
more material about virtual interface. 

Best regards
Xiangsong