RE: [nemo] new requirement for draft-ietf-nemo-requirements

["Vijay Devarapalli" <[e-mail]>]

> Maybe I have lost too much context on NEMO, but I thought the 
> base protocol does support dynamic routing protocols between 
> the MR and HA to update the MNPs. In that case, any routing 
> changes to the MNPs are expected to propagate via the routing 
> protocols to the rest of the network. 

even then the routes are aggregated under the home network.
the route changes are only propoaged to the link the home
agent the attached to. not beyond the home network.

see draft-ietf-nemo-home-network-models-06.txt for more
information. it is in the RFC Editor queue.

Vijay

> 
> I would not expect these updates to be as frequently changing 
> as in the RO case, but, nevertheless, the capability for 
> propagation through routing protocols does exist. 
> 
> Independent of this, the requirement suggested by Ross seems 
> perfectly reasonable to me. 
> 
> Vidya 
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[e-mail]] 
> > Sent: Wednesday, December 06, 2006 10:30 AM
> > To: marcelo bagnulo braun; [e-mail]
> > Cc: IETF NEMO WG
> > Subject: Re: [nemo] new requirement for draft-ietf-nemo-requirements
> > 
> > Marcelo and Alex,
> > 
> > note that draft-ietf-nemo-requirements only lists 
> > requirements for the NEMO Basic support protocol not for any 
> > route optimization solution that might come out of the NEMO WG.
> > 
> > the requirement by itself is fine with me. but it is in the 
> > wrong document. :) perhaps we can add a sentence to the 
> > charter saying that any route optimization solution should 
> > have minimal impact on Internet routing. then the requirement 
> > becomes really applicable to any route optimization solution.
> > 
> > Vijay
> > 
> > marcelo bagnulo braun wrote:
> > > Hi,
> > > 
> > > 
> > > El 04/12/2006, a las 16:47, Jari Arkko escribió:
> > > 
> > >> I have not looked into HAHA yet, but from your description 
> > below it 
> > >> does not seem to cause routing problems. It is common to 
> advertise 
> > >> prefixes from multiple locations.
> > >>
> > > 
> > > agree that this is common, but announcing a specific 
> > routing entry for 
> > > each home network (i.e. end site, not ISP)  does seem to pose 
> > > scalability issues for the routing system, imho
> > > 
> > > I mean, we have discussed this before in this ml. If 
> global HAHA is 
> > > deployed as a global mobility provider i.e. there is a 
> single home 
> > > prefix that aggregates all the home networks from different 
> > end sites, 
> > > then, this seems similar to the provider aggregation 
> > However, if each 
> > > home network of each nemo is announced seaprately, then the 
> > number of 
> > > announced routes increases considerably and i am not sure if thi 
> > > contribution to the global routing tables is acceptable.
> > > 
> > > Anyway, i think the requirement is perfectly ok, we just need to 
> > > understand what is the intended deployment scenarios for 
> > global HAHA 
> > > and if those scale well.
> > > 
> > > Regards, marcelo
> > > 
> > > 
> > >> --Jari
> > >>
> > >> RYUJI WAKIKAWA kirjoitti:
> > >>> Hi Jari,
> > >>>
> > >>> I want to make sure one item whether it breaks new 
> > requirements or not.
> > >>>
> > >>> We have been discussing multiple HAs usage (global-haha) 
> > in NEMO WG.
> > >>> It is not clear yet whether we will pick this in a WG item, but 
> > >>> maybe in future.
> > >>> This global HAHA advertises block of home prefixes to BGP 
> > in anycast 
> > >>> fashion, but dynamic change of BGP entries is not occurred.
> > >>>
> > >>> regards,
> > >>> ryuji
> > >>>
> > >>>
> > >>> On 2006/12/04, at 23:45, Jari Arkko wrote:
> > >>>
> > >>>> Hi all,
> > >>>>
> > >>>> We reviewed this draft in the IESG, and Ross raised a 
> > requirement 
> > >>>> that he thinks is important but is not listed in the current 
> > >>>> document. It is about the effect to the Internet 
> routing tables. 
> > >>>> Please find a suggested edit below. We thought that this 
> > change is 
> > >>>> large enough that the WG needs to be consulted, even if the 
> > >>>> requirement is fulfilled by NEMO BSP. So, if you have 
> a problem 
> > >>>> with this change let us know by the end of the week (Dec 8th).
> > >>>>
> > >>>> NEW Section 3.12:
> > >>>>
> > >>>> 3.12  Minimal Impact on Internet Routing
> > >>>>
> > >>>> Any NEMO solution(s) needs have minimal negative effect on the 
> > >>>> global Internet routing system. The solution must 
> > therefore limit 
> > >>>> both the amount of information that must be injected 
> > into Internet 
> > >>>> routing, as well as the dynamic changes in the 
> > information that is 
> > >>>> injected into the global routing system.
> > >>>>
> > >>>> As one example of why this is necessary, consider the 
> > approach of 
> > >>>> advertising each mobile network's connectivity into 
> BGP, and for 
> > >>>> every movement withdrawing old routes and injecting new routes.
> > >>>> If there were tens of thousands of mobile networks each 
> > advertising 
> > >>>> and withdrawing routes, for example, at the speed that 
> > an airplane 
> > >>>> can move from one ground station to another, the 
> > potential effect 
> > >>>> on BGP could be very unfortunate. In this example the 
> > total amount 
> > >>>> of routing information advertised into BGP may be 
> > acceptable, but 
> > >>>> the dynamic instability of the information (ie, the number of 
> > >>>> changes over time) would be unacceptable.
> > >>>>
> > >>>> NEW requirement to be added to the end of Section 4:
> > >>>>
> > >>>> R17: The solution should have a minimal impact on the global 
> > >>>> Internet routing system.
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > > 
> > > 
> > 
> > 
> > 
>