Subject: [nemo] AW: Nemo digest, Vol 1 #38 - 10 msgs

From: Ingo Rübe <[email-masked]>
Date: Thu, 3 Jul 2003 11:43:53 +0200

In 5 minuten 
		-ingo

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Juli 2003 11:42
An: [email-masked]
Betreff: Nemo digest, Vol 1 #38 - 10 msgs

Send Nemo mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/nemo
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Nemo digest..."

Today's Topics:

   1. Re: The question about NEMO basic support (Vijay Devarapalli)
   2. Re: Design Team draft for NEMO Basic Solution (William D Ivancic)
   3. Re: Vienna Agenda (William D Ivancic)
   4. Re: Design Team draft for NEMO Basic Solution (Vijay Devarapalli)
   5. Re: experiments (was: Vienna Agenda) (Alexandru Petrescu)
   6. RE: Re: The question about NEMO basic support (Jongkeun Na)
   7. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] (Eun Kyoung Paik)
   8. Re: Re: I-D  ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt (Henrik Petander)
   9. [email-masked] (Conferencia ew2004)
  10. Re: I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt] (Alexandru Petrescu)

--__--__--

Message: 1
Date: Wed, 02 Jul 2003 09:58:51 -0700
From: Vijay Devarapalli <[email-masked]>
To: Jongkeun Na <[email-masked]>
CC: [email-masked]
Subject: [nemo] Re: The question about NEMO basic support

> 
> Hello Vijay,
> 
>  
> 
> I have a question for prefix table described in the draft.
> 
> In case that prefix table is not pre-configured in HA, MR should use 
> explicit or combined binding mode. Right?

right. 

> 
> Let's assume that MR and HA can run dynamic routing protocol and 
> prefix table is not pre-configured.

when the MR and HA run a dynamic routing protocol there is
no need to include an prefix information in the Binding
Update. infact the HA should not try to determine the 
prefix from the Binding Update. the routing protocol updates will carry the prefix information. do you think we need an explicit flag in the Binding Update for this? 

Vijay

> 
> If MR try to do implicit binding, by the draft, MR cannot set up the 
> bi-directional tunnel with its HA because HA will send BACK with `143' 
> status code(Mobile Network Prefix Information information unavailable) 
> for the requested BU.
> 
> I think HA should allow the implicit BU from MR that runs dynamic 
> routing protocol because the draft says that prefix table is an 
> optional data structure from the terminology description of section 2. 
> Or, the draft should say prefix table MUST be maintained by HA.
> 
>  
> 
> It looks like unclear to me. Could you explain that for me?
> 
>  
> 
> Best Regards,
> 
> /Jongkeun

--__--__--

Message: 2
Date: Wed, 02 Jul 2003 13:35:35 -0400
To: "T.J. Kniveton" <[email-masked]>
From: William D Ivancic <[email-masked]>
Subject: Re: [nemo] Design Team draft for NEMO Basic Solution
Cc: <[email-masked]>

Very nice work on the Basic Support.

Sorry, I cannot make it out to Vienna, but I should be at the next 
meeting.   Also,  I have a draft completed on issues related to mobile-ip 
and routing protocols when using encryption devices.  I could not get it in 
before closeout of Internet Drafts.  However I will as soon as IETF opens 
for new submissions.

Here are a few questions and some minor corrections:

1)  Question regarding section 8. Support for Dynamic Routing Protocols "In the solution described so far, forwarding to the Mobile Network at the 
Home Agent is set up when the Home Agent receives a Binding Update from the 
Mobile Router. An alternative to this is for the Home Agent and the Mobile 
Router to run a intra-doamin routing protocol like RIPng [6] and OSPF [7] 
through the bi-directional tunnel."

I believe the hop limit is usually set to 1 for routing 
protocols.   Encapsulation will decrement by 1.  Do we need to state 
anything here regarding the need to not decrement the Hop Limit field here 
or is this obvious?  ( I am wary of this as it is definitely an issue with 
encryption devices.)

1.1)  Has anyone given some though to policy base routing over tunnels that 
are coming up and going down?   The aeronautics community still has this on 
their wish list.

2)  Many places in  the document is state "MUST not."   Should those be 
changed to "MUST NOT"?

Typographic and Spelling Mistakes
=========================
Page 17.
home link. At this point, Mobile Router MAY try try to obtain and own a 
prefix by the same means that it initially got attributed the Invalid 
Prefix in question. Alternatively, Mobile Router MAY send Binding Updates 
in another mode (e.g. implicit mode) to a Home Agent on the same home link.

MAY try try  >>>   MAY try

The bi-directional tunnel between Mobile Router and Home Agent allows 
packets to flow in both directions between these entities, while the Mobile 
Router is connected to a Visisted Link.

Visisted Link. >>> Visited Link

Page 18

A Mobile Router MAY use the received Router Advertisements on the interface 
connected to the home link, but only for logging and administrative 
purposes. Only when that interface is connected to a A Mobile Router MAY 
use the received Router Advertisements on the interface connected to the 
home link, but only for logging and administrative purposes. Only when that 
interface is connected to a visisted link,

visisted link >>>  visited link

Page 26
8. Support for Dynamic Routing Protocols In the solution described so far, 
forwarding to the Mobile Network at the Home Agent is set up when the Home 
Agent receives a Binding Update from the Mobile Router. An alternative to 
this is for the Home Agent and the Mobile Router to run a intra-doamin routing

intra-doamin  >>> intra-domain

Will Ivancic

--__--__--

Message: 3
Date: Wed, 02 Jul 2003 13:55:46 -0400
To: [email-masked]
From: William D Ivancic <[email-masked]>
Subject: Re: [nemo] Vienna Agenda
Cc: Chan-Wah Ng <[email-masked]>, Thierry Ernst <[email-masked]>,
        IETF NEMO WG <[email-masked]>, "T.J. Kniveton" <[email-masked]>

Vijay

>it would be good to nail down what exactly NEMO is supposed
>to support with respect to mutlihoming at this IETF. I have seen too 
>many multihoming scenarios, some of which are not practical at all 
>(IMHO).

I work with mobile networks daily using Cisco's IPv4 implementation.  The 
multihoming we utilize is one router with multiple "roaming" interfaces 
connected to various links.  Some of those links may have foreign agents 
and others may use collocated-care-of-address (CC0A).  For example I have 
one mobile router that has an 802.11 interface (foreign agent); one 
satellite link using static CCOA and one G2.5 general packet radio service 
(GPRS) link using dynamic CCOA over PPP.  The mobile router is configured 
to choose links in the following order of 
preference:  1st  WiFi,  2nd  GPRS, 3rd Satellite.  Although all links may 
be active and register as available, only one link can be used at a 
time.  Although some may wish (or at least think they wish) to use multiple 
links or all links (as with the aeronautical community) the practicality of 
this is questionable.

The following are real measured numbers for some services we have used.

Link     Practical Data 
Rate      RTT  Delay                                                Cost
===========================================================================
WiFi            >1.0 Mbps              100 msec       Free after 
infrastructure or approximately equal to GPRS

GPRS           ~30 kbps        300 - 1000 msec    $30 - $70 per 
month  Unlimited Volume

Satellite          ~ 40 kbps          1 - 2 seconds    $1.00 per minute !!!!

Will Ivancic

--__--__--

Message: 4
Date: Wed, 02 Jul 2003 11:08:06 -0700
From: Vijay Devarapalli <[email-masked]>
To: William D Ivancic <[email-masked]>
CC: "T.J. Kniveton" <[email-masked]>, [email-masked]
Subject: Re: [nemo] Design Team draft for NEMO Basic Solution

William D Ivancic wrote:
> 
> Very nice work on the Basic Support.
> 
> Sorry, I cannot make it out to Vienna, but I should be at the next
> meeting.   Also,  I have a draft completed on issues related to mobile-ip
> and routing protocols when using encryption devices.  I could not get 
> it in before closeout of Internet Drafts.  However I will as soon as 
> IETF opens for new submissions.
> 
> Here are a few questions and some minor corrections:
> 
> 1)  Question regarding section 8. Support for Dynamic Routing 
> Protocols "In the solution described so far, forwarding to the Mobile 
> Network at the Home Agent is set up when the Home Agent receives a 
> Binding Update from the Mobile Router. An alternative to this is for 
> the Home Agent and the Mobile Router to run a intra-doamin routing 
> protocol like RIPng [6] and OSPF [7] through the bi-directional 
> tunnel."
> 
> I believe the hop limit is usually set to 1 for routing
> protocols.   Encapsulation will decrement by 1.  Do we need to state
> anything here regarding the need to not decrement the Hop Limit field 
> here or is this obvious?  ( I am wary of this as it is definitely an 
> issue with encryption devices.)

the way I see it is, both the HA and MR run a routing protocol through the bi-directional tunnel. this tunnel is treated as 
a singe hop link. both MR and HA use link local addresses for routing protocol messages inside the tunnel. these messages are processed at each end and are not forwarded onto the other links.

forwarding packets with link local address raises a lot of 
issues and also makes the HA implementation difficult.

> 
> 1.1)  Has anyone given some though to policy base routing over tunnels that
> are coming up and going down?   The aeronautics community still has this on
> their wish list.

I am not sure I read any previous mails on this. can you tell me more?

> 
> 2)  Many places in  the document is state "MUST not."   Should those be
> changed to "MUST NOT"?

fixed

> 
> Typographic and Spelling Mistakes
> =========================
> Page 17.
> home link. At this point, Mobile Router MAY try try to obtain and own 
> a prefix by the same means that it initially got attributed the 
> Invalid Prefix in question. Alternatively, Mobile Router MAY send 
> Binding Updates in another mode (e.g. implicit mode) to a Home Agent 
> on the same home link.
> 
> MAY try try  >>>   MAY try
> 
> The bi-directional tunnel between Mobile Router and Home Agent allows 
> packets to flow in both directions between these entities, while the 
> Mobile Router is connected to a Visisted Link.
> 
> Visisted Link. >>> Visited Link
> 
> Page 18
> 
> A Mobile Router MAY use the received Router Advertisements on the 
> interface connected to the home link, but only for logging and 
> administrative purposes. Only when that interface is connected to a A 
> Mobile Router MAY use the received Router Advertisements on the 
> interface connected to the home link, but only for logging and 
> administrative purposes. Only when that interface is connected to a 
> visisted link,
> 
> visisted link >>>  visited link
> 
> Page 26
> 8. Support for Dynamic Routing Protocols In the solution described so 
> far, forwarding to the Mobile Network at the Home Agent is set up when 
> the Home Agent receives a Binding Update from the Mobile Router. An 
> alternative to this is for the Home Agent and the Mobile Router to run 
> a intra-doamin routing
> 
> intra-doamin  >>> intra-domain

thanks.

Vijay

--__--__--

Message: 5
Date: Thu, 03 Jul 2003 04:16:22 +0200
From: Alexandru Petrescu <[email-masked]>
To: William D Ivancic <[email-masked]>
CC: [email-masked], Chan-Wah Ng <[email-masked]>,
        Thierry Ernst <[email-masked]>, IETF NEMO WG <[email-masked]>,
        "T.J. Kniveton" <[email-masked]>,
        Alexandru Petrescu <[email-masked]>
Subject: [nemo] Re: experiments (was: Vienna Agenda)

William D Ivancic wrote:
> Vijay
> 
> 
>> it would be good to nail down what exactly NEMO is supposed to
>> support with respect to mutlihoming at this IETF. I have seen too 
>> many multihoming scenarios, some of which are not practical at all 
>> (IMHO).
> 
> 
> I work with mobile networks daily using Cisco's IPv4 implementation.
> The multihoming we utilize is one router with multiple "roaming" 
> interfaces connected to various links.  Some of those links may have 
> foreign agents and others may use collocated-care-of-address (CC0A). 
> For example I have one mobile router that has an 802.11 interface 
> (foreign agent); one satellite link using static CCOA and one G2.5 
> general packet radio service (GPRS) link using dynamic CCOA over PPP.
>  The mobile router is configured to choose links in the following 
> order of preference:  1st  WiFi,  2nd  GPRS, 3rd Satellite.  Although
>  all links may be active and register as available, only one link can
>  be used at a time.  Although some may wish (or at least think they 
> wish) to use multiple links or all links (as with the aeronautical 
> community) the practicality of this is questionable.

Thanks for the description, I'm happy to see these kinds of experiments happen.  Just to show similarity, we call a "roaming" interface a "mobile" interface.

We started with the same kind of idea for a mobile router prototype that has several mobile interfaces connected to various access systems (but behaviour was so difficult to maintain that we preferred to isolate ppp connections on a "FrontBox").  For example, when a GPRS mobile interface is used, and the mobile router enters a tunnel (a real tunnel like under a river) then that PPP connection goes down, the corresponding interface disappears, routing entries disappear.  When the mobile router exits that tunnel, re-establishing the PPP connection involved relaunching many other things.  So we considered designing "FrontBoxes" that would isolate this behaviour from Mobile IPv6 software:

A GPRS FrontBox runs PPP on an interface and attaches to a GPRS Base Station.  It also has a WLAN interface w1 on which it sends IPv6 RAs towards MR.  If the PPP connection goes down, this can be repaired locally withouth MR noticing it.  A WLAN FrontBox has two WLAN interfaces, one of them attaching to a hotspot WLAN AP, and the other is named w2.  (A third _potential_ DVB FrontBox would use a terestrial DVB link as well as a return path on another GPRS phone, such as to still provide bidirectional IPv6 connectivity on a WLAN iface w3 towards the MR.)

Each FrontBox uses private IPv4 to connect to GPRS or to hotspots respectively.  They also dynamically maintain IPv6-in-UDP/v4 tunnels towards a special machine in the home network that has connectivity to both IPv4 and IPv6 Internets.  Each FB provides IPv6-only bidirectional connectivity to MR, each sending different RA's with unique prefixes.

A Mobile Router has only one WLAN "mobile" interface that switches attachment between w1 and w2, as well as another WLAN interface towards the mobile network link.  The Mobile Router and the nodes in the mobile network exclusively run IPv6 with network mobility based on Mobile IPv6 (no IPv4).  Mobile Router switches attachment by means of a visual interface (GUI), with manual buttons.  When I see the hotspot access point approaching I push the "WLAN" button; when I see it in the rear view mirror I push "GPRS".  Of course, better can be done to automate this with some preferences, as your experiments report.

In this way, all access technologies are separated (read deterministic and controllable), from the Mobile IPv6 behaviour.

> The following are real measured numbers for some services we have
> used.
> 
> Link     Practical Data Rate      RTT Delay Cost
> 
===========================================================================
> WiFi            >1.0 Mbps              100 msec       Free after 
> infrastructure or approximately equal to GPRS
> 
> GPRS           ~30 kbps        300 - 1000 msec    $30 - $70 per month
>  Unlimited Volume
> 
> Satellite          ~ 40 kbps          1 - 2 seconds    $1.00 per 
> minute !!!!

Confirms most of my expectations with respect to GPRS rates/delays/dollar_cost.  I'm suprised though to see "satellite" being 40kb/s (I was thinking it would be much less(?).  Does the satellite link have a sort of return path?  Could I imagine acquiring  sattelite link somehow somewhere to make a FrontBox with it?

In our experiments, the data rates as shown by vic between LFN and a CN placed in the home network varies between 11-45Kb/s (when GPRS) and about 60kb/s (when WLAN).  Ping delays over GPRS are little over 1s. The direct communication between WLAN FrontBox and hotspot AP is standard 11mb/s. All relevant delays and latencies largely depend on the higly variable number of many hops between MR and HA as well as between CN and HA and CN and MR.

Billing was not taken into consideration since the billing scheme of the access providers were themselves a moving ground (WLAN hotspots were free but business model changing as we speak, including targetting a "mixed" GPRS+WLAN billing; GPRS was only making pay the number of bytes transferred, not the time length, not flat; to complicate things further some GPRS operators make pay more if the given IPv4 address is publicly routable non-NAT'ed, and less if NAT'ed).  Ask me for more information, or the operators themselves.

There was not any form of multi-homing in our experiments, even if several access systems were indeed used, or some other times in the laboratory several Home Agents were used.  Only one connection was used at a time, and I don't see exactly how a "one-size-fits-all" means to reasonably use simultaneously these three access systems can be conceived.

And yes, I would very much appreciate if clarifications are sought at the live meeting with respect to multi-homing requirements and the practical scenarios in relation to network mobility.  Looking forward...

Alex
GBU

--__--__--

Message: 6
From: "Jongkeun Na" <[email-masked]>
To: "'Vijay Devarapalli'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [nemo] Re: The question about NEMO basic support
Date: Thu, 3 Jul 2003 10:33:28 +0900

> > I have a question for prefix table described in the draft.
> >
> > In case that prefix table is not pre-configured in HA, MR should use
> explicit or combined binding mode. Right?
> 
> right.
> 
> >
> > Let's assume that MR and HA can run dynamic routing protocol and
prefix
> table is not pre-configured.
> 
> when the MR and HA run a dynamic routing protocol there is
> no need to include an prefix information in the Binding Update. infact 
> the HA should not try to determine the prefix from the Binding Update. 
> the routing protocol updates will carry the prefix information. do you 
> think we need an explicit flag in the Binding Update for this?
> 

Yes, I thought an explicit flag is required for HA to properly handle this situation.

/Jongkeun
> 
> Vijay
> 
> >
> > If MR try to do implicit binding, by the draft, MR cannot set up the
bi-
> directional tunnel with its HA because HA will send BACK with `143'
status
> > code(Mobile Network Prefix Information information unavailable) for
the
> requested BU.
> >
> > I think HA should allow the implicit BU from MR that runs dynamic
> routing protocol because the draft says that prefix table is an
optional
> data structure
> > from the terminology description of section 2. Or, the draft should
say
> prefix table MUST be maintained by HA.
> >
> >
> >
> > It looks like unclear to me. Could you explain that for me?
> >
> >
> >
> > Best Regards,
> >
> > /Jongkeun

--__--__--

Message: 7
Date: Thu, 3 Jul 2003 14:59:18 +0900
From: Eun Kyoung Paik <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt]

Thank you for your kind reply.
Please see inlines. 
> > And I have another question on the implementation of nested mobile
> > networks. For example, let's think about following topology.
> > 
> > Internet | AR | Parent MR | Child MR
> > 
> > In the figure, Parent MR may autoconfigure its CoA after it listens
> > RA of AR. Then, Child MR may autoconfigure its CoA after it listens 
> > RA of Parent MR. After that, if Parent MR listens Child MR's RA, 
> > Parent MR configures new CoA according to Child MR's RA ?
> 
> In this particular configuration, I do not think that Parent MR 
> configures a CoA based on the Child MR RA.  There are two reasons for 
> that.
> 
> One is that according to the stateless autoconfiguration mechanisms a 
> router will not autoconfigure an address on an interface based on 
> received RA's.  Parent MR is a router, so.

Then, how MR's egress interface configures its CoA 
when it moves into a foreign link ?
Doesn't it need RA from foreign link ?  

> 
> The other is that Child MR is, in fact, visiting the network of Parent
> MR; when a MR is visiting, it acts as a host on its egress interface, 
> not as a router.  Thus it will not send RA's on its egress interface 
> if it is not at home, so Parent MR does not get RA's from Child MR.

I wonder if parent MR's egress interrface listen the RA of child MR's ingress interface. (Child MR's ingress interface may broadcast its RA for its VMNs.)

And how can we distinguish egress interface from ingress interface physically ?

> There is also a widely acknolwedged problem of "disconnected" 
> operation that was mentioned very early.
> 
> Have you encountered some similar problems?
 
Could you breifly explain about "disconnected" operation ?

Regards,
Eun Kyoung

--__--__--

Message: 8
Date: Thu, 3 Jul 2003 10:52:00 +0300 (EEST)
From: Henrik Petander <[email-masked]>
To: Alexandru Petrescu <[email-masked]>
Cc: Ralph Droms <[email-masked]>, <[email-masked]>
Subject: Re: [nemo] Re: I-D  ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt

On Wed, 2 Jul 2003, Alexandru Petrescu wrote:

> Ralph Droms wrote:
> > Following up on our conversation a couple of months ago about using 
> > DHCPv6 PD for prefix delegation to mobile routers, I've published 
> > "DHCPv6 Prefix Delegation for NEMO" 
> > <draft-droms-nemo-dhcpv6-pd-00.txt>.  This draft describes the use 
> > of  DHCPv6 to meet my understanding of the requirements for prefix 
> > delegation to mobile routers.  Comments welcome...
>
> I'm happy this draft exists and is up for comments. I think that the 
> way it suggests behaviour of PD between MR and HA is very good for the 
> simplest mobile network configurations.

Yes, this seems like an easy way to allow a mobile node to become a mobile router e.g. when user attaches a PDA to her mobile phone.

>
> > Other updates to the HA data structures required as a side effect of  
> > prefix delegation are specified by the particular network mobility 
> > protocol.  For example, in the case of "Basic Network Mobility 
> > Support" [8], the HA would add an entry in its binding cache 
> > registering the delegated prefix to the MR to which the prefix was 
> > delegated.
>
> I don't think that any proposed solution would involve triggering 
> additions of BC entries as a result of PD operations.  Adding entries 
> in the BC is exclusively a result of Binding messaging, in my 
> understanding.

I guess the prefix should be added to the prefix table instead. Then the HA could authenticate MR as being authorized to send BUs for the delegated prefix and MR could also send BUs without including explicit prefix information.

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		[email-masked]
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------

--__--__--

Message: 9
From: Conferencia ew2004 <[email-masked]>
To: [email-masked]
Date: Thu, 3 Jul 2003 10:47:09 +0200 (MEST)
Subject: [nemo] [email-masked]

--__--__--

Message: 10
Date: Thu, 03 Jul 2003 11:41:21 +0200
From: Alexandru Petrescu <[email-masked]>
To: Eun Kyoung Paik <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [nemo] I-D ACTION:draft-lach-nemo-experiments-overdrive-00.txt]

Eun Kyoung Paik wrote:
> Thank you for your kind reply. Please see inlines.
> 
>>> And I have another question on the implementation of nested
>>> mobile networks. For example, let's think about following 
>>> topology.
>>> 
>>> Internet | AR | Parent MR | Child MR
>>> 
>>> In the figure, Parent MR may autoconfigure its CoA after it
>>> listens RA of AR. Then, Child MR may autoconfigure its CoA after 
>>> it listens RA of Parent MR. After that, if Parent MR listens 
>>> Child MR's RA, Parent MR configures new CoA according to Child 
>>> MR's RA ?
>> 
>> In this particular configuration, I do not think that Parent MR
>> configures a CoA based on the Child MR RA.  There are two reasons 
>> for that.
>> 
>> One is that according to the stateless autoconfiguration mechanisms  
>> a router will not autoconfigure an address on an interface based on 
>> received RA's.  Parent MR is a router, so.
> 
> Then, how MR's egress interface configures its CoA when it moves into  
> a foreign link ? Doesn't it need RA from foreign link ?

Yes, exactly, it does need one.  That's why the egress interface of a MR will act as if it were belonging to a host (not a router) when visiting a foreign network.

>> The other is that Child MR is, in fact, visiting the network of
>> Parent MR; when a MR is visiting, it acts as a host on its egress 
>> interface, not as a router.  Thus it will not send RA's on its 
>> egress interface if it is not at home, so Parent MR does not get 
>> RA's from Child MR.
> 
> 
> I wonder if parent MR's egress interrface listen the RA of child MR's  
> ingress interface.

A picture would help.  My picture is that Parent MR uses its egress to connect to AR and ingress to connect to Child MR.  Child MR uses its egress to connect to Parent and its ingress to connect to its mobile link.

In general, I think the MR's _ingress_ interface will listen for RA's but will not use it to autoconfigure addresses.  The MR's _egress_ interface, when in a foreign link, will listen to RA's from AR and will autoconfigure CoA.

Since the Child MR is acting like the parent MR, and child's egress interface does not send RA (because it acts as a host on that interface) then parent will not see any RA's coming from child MR.

> (Child MR's ingress interface may broadcast its RA for its VMNs.)

Yes, Child MR's ingress interface MUST broadcast RA (but not the egress).  Right?

> And how can we distinguish egress interface from ingress interface
> physically ?

That's a good question and in one implementation that is a "knob", that is like a turning button, like a kernel variable that says which interface is "egress".

> Could you breifly explain about "disconnected" operation ?

Ok, maybe "disconnected operation" is my name for it, but the issue was mentioned under other names, where two nested mobile networks can't talk to each other if their respective HA's are not available.  Many discussions in the archives.  Many pros and cons of this being or not being a problem.

Alex
GBU

--__--__--

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

End of Nemo Digest

---

From: Ingo Rübe <[email-masked]>
Date: Thu, 3 Jul 2003 11:43:53 +0200

In 5 minuten 
		-ingo

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Donnerstag, 3. Juli 2003 11:42
An: [email-masked]
Betreff: Nemo digest, Vol 1 #38 - 10 msgs

Today's Topics:

--__--__--

Message: 1

right. 

Vijay

--__--__--

Message: 2

MAY try try  >>>   MAY try

Page 18

Page 26

Will Ivancic

--__--__--

Message: 3

Vijay

Link     Practical Data 
Rate      RTT  Delay                                                Cost

Will Ivancic

--__--__--

Message: 4

fixed

thanks.

Vijay

--__--__--

Message: 5

Alex
GBU

--__--__--

Message: 6

prefix

/Jongkeun
bi-
status
the
optional
say

--__--__--

Message: 7

 

Regards,
Eun Kyoung

--__--__--

Message: 8

Henrik

--__--__--

Message: 9

--__--__--

Message: 10

Alex
GBU

--__--__--

End of Nemo Digest