Re: OSPF ASON Routing Solution

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

See  in-line.
Igor

----- Original Message ----- 
From: <[e-mail]>
To: "Igor Bryskin" <[e-mail]>
Cc: "Acee Lindem" <[e-mail]>; "Adrian Farrel" <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Friday, July 21, 2006 10:36 AM
Subject: Re: OSPF ASON Routing Solution


> igor -
>
>
> i don't think that someone claimed that OSPF-TE is a superset of OSPF or
> whatsover the former (as other applications) just build on existing OSPF
> RFCs (and mechanisms)
>
> note that RFC 2370 states "The information contained in Opaque LSAs may be
> used directly by OSPF

IB>> I aggree that IFF OSPF uses Opaque LSAs for its *own* purposes, that
whatever comes out of such use *is* an extension to OSPF

 or indirectly by some application
> wishing to distribute information throughout the OSPF domain."

IB>> And I claim that such application is not an extension to OSPF, rather,
it is exactly what is stated above - an application using OSPF opaque LSAs


reason why
> GR, Router capabilities and TE like applications can make use of opaque
> LSAs (that you restrict to TE only btw); hence your assertion "RFC2370
> does not provide a way for extending OSPF" is not correct
>
> this said your digression falls imho outside the scope of the present poll
> (if you want to re-discuss GMPLS/OSPF-TE vs OSPF i suggest you start from
> the beginning not from the middle and probably direct your concern at the
> owning WG)

I disagree with that. I have joined this discussion when Adrian asked Acee
whether he as a chair of OSPF WG had any objections wrt ASON OSPF document,
and my point is why OSPF WG should care about this solution one way or the
other.

Igor
>
> ps: all this remembers me the discussion we had 3 years ago in Vienna (but
> was on BGP at that time) and we all know where and how such discussions
> end
>
>
> -d.
>
>
>
>
>
>
> "Igor Bryskin" <[e-mail]>
> 21/07/2006 16:04
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Acee Lindem" <[e-mail]>, "Adrian Farrel"
> <[e-mail]>, <[e-mail]>, <[e-mail]>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Dimitri,
>
> Please, see in line.
>
> Igor
>
> ----- Original Message ----- 
> From: <[e-mail]>
> To: "Igor Bryskin" <[e-mail]>
> Cc: "Acee Lindem" <[e-mail]>; "Adrian Farrel" <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, July 20, 2006 8:05 PM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > 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
> ?
>
> RFC2370 does not provide a way for extending OSPF, rather, it exposes OSPF
> advertising, flooding and synchronization mechanisms to be used by other
> (non-OSPF) applications. OSPF-TE, ASON OSPF, L1VPN OSPF. mesh membership,
> node capability discovery, etc. are such applications. To answer your
> question OSPF-TE is not an extension to OSPF, rather, it is a separate
> protocol.
>
> Let me prove you this point. Consider RSVP (RFC2205) and RSVP-TE. The
> latter
> *is* an extension of the former, because it understands and uses all basic
> elements, objects (e.g. SESSION, SENDER_TEMPLATE, etc.) and *in addition*
> it
> introduces new elements/objects (e.g. SESSION_ATTRIBUTES, LABEL, etc.).
> You
> can say that RSVP-TE is a superset of RSVP. likewise, GMPLS RSVP is a
> superset of RSVP-TE.
> Let us now consider OSPF and OSPF-TE. The latter neither understands nor
> uses basic OSPF LSAs type 1,2,3,4,5. Rather it understands only opaque
> LSAs
> (type 10) with semantics specifically designed for the TE application.
> These
> semantics are not understood by OSPF. You surely can not claim that
> OSPF-TE
> is a superset of OSPF, hence OSPF-TE is not an extension to OSPF.
> Furthermore, TE routing areas do not have to match IP routing areas and
> may
> have completely different area hierarchies. ASON OSPF (I forgot the name
> of
> the author) is a shining proof to that.
>
> >
> > 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
>
> I can see how OSPF can use opaque LSAs for experimantation purposes and
> for
> extending itself, but this is not what,say, OSPF-TE is about.
>
> >
> > ps: i forgot the name of the author of OSPF ext. for L1VPN
>
> If you are talking about L1VPN-OSPF, this is not OSPF ext for L1VPN,
> rather,
> OSPF based L1VPN auto-discovery solution
>
> Igor
>
> >
> >
> >
> >
> > "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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
>
>
>