Subject: [NSIS] Some More Suggestions on Multi-homing (section 5.2.5) of Mobility Draft

From: "Shivanajay Marwaha" <[email-masked]>
Date: Thu, 16 Feb 2006 19:49:09 +0800

Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors and other
NSIS WG members, 
 
Some more comments on Multi-homing section in Mobility draft:-
 
--------------------------------------------------------------------
Comment 1:- Section 5.2.5, Change title to "Host multihoming"
 
Discussion - 
We think that the above title would be more meaningful if it's
changed to Host Multihoming, since Issue discussed here applies to
host multihoming in general (where multiple connection between MN and
CN are possible, either via different physical interfaces or a single
interface). So, the discussion in this section should not be limited
to load balancing, which is just a use case of multihoming. In view
of this, the title "Host multihoming" would be more suitable.
 
-------------------------------------------------------------------
 
Comment 2:- Section 5.2.5, reference to external drafts
 
Original Text - 
   "There may be a situation where an MN may need to distribute its
traffic load to multiple paths via multiple interfaces.  In this
case, the MN can send multiple QUERY messages to multiple interfaces
to establish NSIS state on multiple paths."
 
Discussion - 
As load balancing represents only one of the many reasons for doing
multihoming, for better understanding, it is better to refer to the
draft "Goals and Benefits of Multihoming"
(draft-ernst-generic-goals-and-benefits-02). So we suggest to replace
the above paragraph of section 5.2.5 with following text:-

Suggested Text:-
    "There may be a situation where an MN may need to distribute its
traffic load to multiple paths via multiple interfaces.  In this
case, the MN can send multiple QUERY messages to multiple interfaces
to establish NSIS state on multiple paths. There are many other
scenarios and applications in multi-homing as mentioned in [x] ".
[x] Goals and Benefits of Multihoming
draft-ernst-generic-goals-and-benefits-02 
 
--------------------------------------------------------------------
 
Comment 3:- Section 5.2.5, 2nd para: add description on mobility problem
with multihoming
 
Original Text - 
   " Suppose that an MN wants to set up NSIS state on a path which is
able to support the specific bandwidth requirement for a certain
application in the multihomed environment.  It may not be possible to
 find a feasible path for such a requirement.  In this case, multiple
paths can be used at the same time so that the bandwidth requirement 
can be met.  Note that the flow identifier on each path may be
different although the session identifier is unchanged. "
 
Discussion - 
With the scenario described above, there would be a problem for NSIS
signalling when mobility happens. Please refer to draft  "Path type
support for NSIS signalling" (draft-sanda-nsis-path-type-03.txt) for
details of the problem analysis. So we suggest inserting the
following paragraph after the 2nd paragraph of section 5.2.5:-
 
Suggested Text:-
"When multiple paths are used for the same session, mobility support
may pose a problem for the NSIS signalling. For example, if Path-1
and Path-2 are used for the same session, signalling for these two
paths would use different flow identifier, say FID-1 and FID-2, with
the same session identifier, say SID. In the case a mobility event
causes the Path-1 to be replaced by Path-3 for communication,
signalling for the Path-3 will be also using a different flow
identifier, say FID-3, and the same session identifier, SID. With
this, current NSIS signalling may fail, e.g. CRN discovery, and
tearing of the old path. This is due to the lack of information to
differentiate Path-1 from Path-2. Detail analysis of the problem can
be find in draft [x]
[x] "Path type support for NSIS signalling"
(draft-sanda-nsis-path-type-03.txt) 

Regards,
Shivanajay 
(On Behalf of Takako Sanda, Toyoki Ue and Cheng Hong)

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Seong-Ho Jeong" <[email-masked]>
Date: Wed, 22 Feb 2006 14:34:52 +0900

Hi Shivanajay,

Thanks for your comments.
Please see my comments inline.

Regards,
Seong-Ho

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Shivanajay Marwaha
>Sent: Thursday, February 16, 2006 8:49 PM
>To: Seong-Ho Jeong; Sung-Hyuck Lee; [email-masked]; 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: [NSIS] Some More Suggestions on Multi-homing (section 
>5.2.5) ofMobility Draft
>
>Dear Sung-Hyuck, Seong-Ho, Mobility Applicabilty Draft Authors 
>and other NSIS WG members, 
> 
>changed to Host Multihoming, since Issue discussed here 
>applies to host multihoming in general (where multiple 
>connection between MN and CN are possible, either via 
>different physical interfaces or a single interface). So, the 
>discussion in this section should not be limited to load 
>balancing, which is just a use case of multihoming. In view of 
>this, the title "Host multihoming" would be more suitable.

This subsection is not the only one which discusses host multihoming.
Other subsections in Section 5.2 are also related to host multihoming. 

>   "There may be a situation where an MN may need to 
>distribute its traffic load to multiple paths via multiple 
>interfaces.  In this case, the MN can send multiple QUERY 
>messages to multiple interfaces to establish NSIS state on 
>multiple paths."
> 
>Discussion -
>As load balancing represents only one of the many reasons for 
>doing multihoming, for better understanding, it is better to 
>refer to the draft "Goals and Benefits of Multihoming"
>(draft-ernst-generic-goals-and-benefits-02). So we suggest to 
>replace the above paragraph of section 5.2.5 with following text:-
>
>Suggested Text:-
>    "There may be a situation where an MN may need to 
>distribute its traffic load to multiple paths via multiple 
>interfaces.  In this case, the MN can send multiple QUERY 
>messages to multiple interfaces to establish NSIS state on 
>multiple paths. There are many other scenarios and 
>applications in multi-homing as mentioned in [x] ".

I also think that it would be good to mention the draft as a
relevant reference. We already have the reference in the 
References section although the version needs to be changed.

>Comment 3:- Section 5.2.5, 2nd para: add description on 
>mobility problem with multihoming
> 
>Original Text - 
>   " Suppose that an MN wants to set up NSIS state on a path 
>which is able to support the specific bandwidth requirement 
>for a certain application in the multihomed environment.  It 
>may not be possible to  find a feasible path for such a 
>requirement.  In this case, multiple paths can be used at the 
>same time so that the bandwidth requirement can be met.  Note 
>that the flow identifier on each path may be different 
>although the session identifier is unchanged. "
> 
>Discussion -
>With the scenario described above, there would be a problem 
>for NSIS signalling when mobility happens. Please refer to 
>draft  "Path type support for NSIS signalling" 
>(draft-sanda-nsis-path-type-03.txt) for details of the problem 
>analysis. So we suggest inserting the following paragraph 
>after the 2nd paragraph of section 5.2.5:-
> 
>Suggested Text:-
>"When multiple paths are used for the same session, mobility 
>support may pose a problem for the NSIS signalling. For 
>example, if Path-1 and Path-2 are used for the same session, 
>signalling for these two paths would use different flow 
>identifier, say FID-1 and FID-2, with the same session 
>identifier, say SID. In the case a mobility event causes the 
>Path-1 to be replaced by Path-3 for communication, signalling 
>for the Path-3 will be also using a different flow identifier, 
>say FID-3, and the same session identifier, SID. With this, 
>current NSIS signalling may fail, e.g. CRN discovery, and 
>tearing of the old path. This is due to the lack of 
>information to differentiate Path-1 from Path-2. Detail 
>analysis of the problem can be find in draft [x] [x] "Path 
>type support for NSIS signalling"

Could you clarify further why the current CRN discovery may fail?