Re: OSPF ASON Routing Solution

["Igor Bryskin" <[e-mail]>]

Acee,

I obviously interpreted your comment the way I wanted to :=) - in a broader
way that you meant. I apologize for that. Please, see my response to
Dimitri.

Igor

----- Original Message ----- 
From: "Acee Lindem" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: "Adrian Farrel" <[e-mail]>; <[e-mail]>
Sent: Thursday, July 20, 2006 9:44 PM
Subject: Re: OSPF ASON Routing Solution


> Hi Igor,
>
> Igor Bryskin wrote:
> > Hi Acee,
> >
> > I agree with your comment 100%. OSPF IGP developed and maintained in the
> > OSPF WG  and
> > ASON OSPF have just one thing in common - they share the same transport
,
> > but, otherwise, have 0 in common. In particular, I believe ASON OSPF
should
> > not be considered as an extension to OSPF
> > and should not be objected or supported by OSPF WG.
> >
> I don't believe I said that (at least that's not what I meant). The OSPF
> ASON extensions
> build on the existing OSPFv2 (RFC 2328), opaque LSA (RFC 2370), OSPF TE
> (RFC 3630),
> and GMPLS (RFC 4203) specificatoins. What  I said was that  the ASON
> extension for
> leaking routing information vertically within the RA hierarchy should
> not be construed to imply
> a new OSPF area hierarchy. Rather, an RC supporting RAs at multiple
> levels should
> view these as separate OSPF instances with leaking between levels
> described by
> import/export rules.
>
> Thanks,
> Acee
>
> > Igor
> >
> > ----- Original Message ----- 
> > From: "Acee Lindem" <[e-mail]>
> > To: "Adrian Farrel" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Thursday, July 20, 2006 5:40 PM
> > Subject: Re: OSPF ASON Routing Solution
> >
> >
> >
> >> Hi Adrian, Dimitri, et al,
> >>
> >> No objection on my part. However, I wanted to make a clarification that
> >> may or may not be obvious to everyone. In Montreal, Dimitri
> >> and I sat down and discussed my comments on the hierarchical
> >> dissemination of ASON routing information between RAs (Routing Areas
> >> in ASON parlance).
> >>
> >> Today OSPF does not support an area hierarchy other than the
> >> backbone and non-backbone areas. This specification for ASON  should
> >> not be considered a partial specification of support in OSPF for a new
> >> area hierarchy (specific requirements are stated in the CCAMP
> >> document references). Rather, it should be conceptually viewed as rules
> >> for importing and exporting GMPLS TE data between separate
> >> OSPF instances  (one instance per ASON RA). This was the motivation
> >> for my comment on restating the inter-RA advertisement rules in term of
> >> import/export rather than flooding.
> >>
> >> Thanks,
> >> Acee
> >>
> >> Adrian Farrel wrote:
> >>
> >>> Just a refresh in case you were travelling.
> >>>
> >>> I am seeking objections to this draft becoming a WG document.
> >>>
> >>> Adrian
> >>> ----- Original Message ----- From: "Adrian Farrel"
<[e-mail]>
> >>> To: <[e-mail]>
> >>> Sent: Wednesday, July 12, 2006 8:10 PM
> >>> Subject: OSPF ASON Routing Solution
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>> On Monday in CCAMP we discussed
> >>>> draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt the solutions
> >>>> draft for OSPF in ASON routing.
> >>>>
> >>>> There is agreement from the OSPF WG chair that we are not treading on
> >>>> toes, and the meeting seemed to say that this was pretty stable.
> >>>>
> >>>> So a this is a quick poll to see if anyone objects to this becoming a
> >>>> WG draft.
> >>>> NB, this is a charter item and we have an obligation to work on this
> >>>> for the ITU-T.
> >>>>
> >>>> Thanks,
> >>>> Adrian
> >>>>
> >>>> PS Note that a solution does not have to be 100% perfect to become a
> >>>> WG draft.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >
> >
>