Subject: Re: OSPF ASON Routing Solution

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 21 Jul 2006 11:01:30 -0400

See  in-line.
Igor

----- Original Message ----- 
From: <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;
<[email-masked]>; <[email-masked]>
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" <[email-masked]>
> 21/07/2006 16:04
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     "Acee Lindem" <[email-masked]>, "Adrian Farrel"
> <[email-masked]>, <[email-masked]>, <[email-masked]>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Dimitri,
>
> Please, see in line.
>
> Igor
>
> ----- Original Message ----- 
> From: <[email-masked]>
> To: "Igor Bryskin" <[email-masked]>
> Cc: "Acee Lindem" <[email-masked]>; "Adrian Farrel" <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> 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" <[email-masked]>
> > Sent by: [email-masked]
> > 21/07/2006 00:05
> >
> >         To:     "Acee Lindem" <[email-masked]>, "Adrian Farrel"
> > <[email-masked]>
> >         cc:     <[email-masked]>
> >         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" <[email-masked]>
> > To: "Adrian Farrel" <[email-masked]>
> > Cc: <[email-masked]>
> > 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"
> > <[email-masked]>
> > > > To: <[email-masked]>
> > > > 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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> >
>
>
>

---

From: Acee Lindem <[email-masked]>
Date: Fri, 21 Jul 2006 12:30:28 -0400

Hi Jonathan,

Sadler, Jonathan B. wrote:
> Hi Acee,
>
> I agree that the hierarchy used by ASON can be implemented by specifying
> how redistribution (i.e. import/export) is done between parent/child
> Routing Areas.  In fact, that's captured appendix I of G.7715.
>
> What I am unclear on is what you mean by "OSPF instances".  Since the
> import/export is done between ASON areas, this can also be done between
> OSPF areas. 
NO. OSPF areas are part of a single OSPF routing domain with very 
precise protocol
specification of the duties of an OSPF router connecting to multiple 
areas (an ABR or
Area Border Router). This document doesn't even come close to specify 
what needs to be
done to support an area hierarchy other the existing backbone with a 
single layer
of non-backbone areas.

Furthermore, if OSPF is  to undertake an alternate area hierarchy as a 
requirement than
that work MUST be done in the OSPF WG.
> If you mean "OSPF instance" in the context of a single OSPF
> area, then we are in complete agreement.
>   
An OSPF instance can have multiple areas. However, I believe the GMPLS TE
extensions have only been standardized for a single area.

Thanks,
Acee

>
> Looking forward to productively moving this work forward,
>
> Jonathan Sadler
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Acee Lindem
> Sent: Thursday, July 20, 2006 4:40 PM
> To: Adrian Farrel
> Cc: [email-masked]
> No objection on my part. However, I wanted to make a clarification that
> document references). Rather, it should be conceptually viewed as rules
> for my comment on restating the inter-RA advertisement rules in term of
>>> There is agreement from the OSPF WG chair that we are not treading on
>>>       
>
>   
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>       
>>     
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================
>
>