Re: OSPF ASON Routing Solution

[[e-mail]]

the comment of acee will be addressed - stated already in previous e-mail 
b/f IETF 66 meeting -

as ASON RC(PC) are OSPF engines defined in RFC 2328, routing info exchange 
makes use of RFC 2370 mechanism (which afaik is an intrinsic part of 
OSPF), etc., information encoding (in top-level TLVs) are defined in RFC 
3630 and co. whereas all these are under OSPF WG resp. ... this leads me 
to the question if not extensions to OSPF - extensions of which protocol ?

the main point is that RFC 2370 stating "The information contained in 
Opaque LSAs may be used directly by OSPF or indirectly by some application 
wishing to distribute information throughout the OSPF domain." puts your 
comment in the old battle field bucket since Opaque LSAs have been applied 
since many years to (OSPF-)TE, and GR applications ... hence, are you also 
objecting to these and suggest to have a specific and dedicated protocol 
mechanism per application 

ps: i forgot the name of the author of OSPF ext. for L1VPN





"Igor Bryskin" <[e-mail]>
Sent by: [e-mail]
21/07/2006 00:05
 
        To:     "Acee Lindem" <[e-mail]>, "Adrian Farrel" 
<[e-mail]>
        cc:     <[e-mail]>
        Subject:        Re: OSPF ASON Routing Solution


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.

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.
> >>
> >>
> >>
> >>
> >>
> >
> >
>