Subject: Re: [MEXT] correspondent router drafts

From: "Roberto Baldessari" <[email-masked]>
Date: Fri, 1 Aug 2008 11:39:54 +0200

Hi All,
 
Thanks to Ryuji for submitting the draft.
 
I agree with Wesley. The issues raised in the draft exist and we need to take them into account, but those issues might not be that relevant in the deployments we are considering. I see the obvious benefits of targeting a general solution, but if a general solution that fitted every scenario was simple to find we would not be talking about specific industry requirements. 
 
For example the C2C-CC deployment scenario (draft-ietf-mext-nemo-ro-automotive-req-01) is not that problematic for CR solutions (CR is on the path, 1 CR per CN, static policies can also be used to trigger RO...). I know ISO CALM has a slightly different view on that (see HA switch requirement) and harmonization is needed, but we have some scenarios on the table and I would like to have the issues of proposed solutions compared to the scenario described in the requirement drafts.

Ryuji, if you plan to update this draft, would you consider this?

Roberto

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Eddy, Wesley M. (GRC-RCN0)[VZ]
	Sent: Monday, July 28, 2008 1:04 AM
	To: [email-masked]
	Subject: [MEXT] correspondent router drafts

	This includes comments on draft-bernardos-mext-nemo-ro-cr-00 and
	draft-wakikawa-mext-cr-consideration-00.
	 
	Both of these are great contributions, in my opinion, the first gives a
	requirement-by-requirement analysis of the CR approach for aero
	use, that I largely agree with.
	 
	For the CR solution possibility, I was thinking there would be a small
	number of CRs with each ANSP, with under a hundred total.  I think
	it would be possible to configure the list of these in an MR initially as
	a static configuration, and update it using some new message from
	the HA that informs it of changes to the set of CRs.  This would assume
	that as operational entities bring CRs online or take them offline that
	they communicate those changes to each other, and the changes
	would be pushed from the HAs to the MRs.  The nice thing about this
	is that it is much less overhead than trying to have the MR discover
	CRs itself, or having the CRs somehow discover the MR's traffic, both
	of which seem doomed to me.
	 
	The criticisms with the CR approach that Ryuji's draft brings forward
	are all credible, but I see most of them as more related to general
	Internet use of the CR approach, rather than specific to aviation.  I
	believe the CR approach is feasible for the aviation world's constraints.
	HOWEVER, if it doesn't work for other industries, it violates one of
	our listed "desirable features", so I believe that finding out if CR can
	be made to work for other industries needs to be explored now.  As
	I understand, the global HAHA approach has some desirability to
	other (larger) industries, which gives it a major advantage.
	 
	One idea I had after reading Ryuji's explanation of the problem of
	selecting an egress CR from a site is that it may be possible to
	leverage the possibility to aggregate aero IPv6 addresses in order
	to reduce the impact of routing advertisements for the MNPs.  I
	know at one point Terry Davis was working with ICAO to request
	an IPv6 allocation to be used for aeronautics, and this block would
	be cut up between the various stakeholders.  It might be possible
	to have all the MNPs drawn from the same block so that the routes
	would aggregate.  This doesn't totally remove the problem, though,
	but it may make it simpler.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext