Re: OSPF ASON Routing Solution

"Igor Bryskin" <ibryskin@movaz.com> Fri, 28 July 2006 20:12 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6YhB-0004ql-Sg for ccamp-archive@ietf.org; Fri, 28 Jul 2006 16:12:29 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6Yh9-0000Qv-Eg for ccamp-archive@ietf.org; Fri, 28 Jul 2006 16:12:29 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1G6Ydz-000P54-7k for ccamp-data@psg.com; Fri, 28 Jul 2006 20:09:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <ibryskin@movaz.com>) id 1G6Ydy-000P4o-3W for ccamp@ops.ietf.org; Fri, 28 Jul 2006 20:09:10 +0000
Received: from ib (unknown [172.16.50.21]) by jera.movaz.com (Postfix) with SMTP id EA397D44; Fri, 28 Jul 2006 16:09:08 -0400 (EDT)
Message-ID: <016501c6b281$af9e24a0$6501a8c0@movaz.com>
From: Igor Bryskin <ibryskin@movaz.com>
To: Dimitri.Papadimitriou@alcatel.be
Cc: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
References: <OF6A8D0B5C.57A44B93-ONC12571B9.0054F134-C12571B9.006B83C3@netfr.alcatel.fr>
Subject: Re: OSPF ASON Routing Solution
Date: Fri, 28 Jul 2006 16:09:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de

Dimitri,

Thanks for the answers. Please, see in-line.

Igor

----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Friday, July 28, 2006 3:34 PM
Subject: Re: OSPF ASON Routing Solution


> hi igor - see in-line
>
>
>
>
> "Igor Bryskin" <ibryskin@movaz.com>
> 28/07/2006 16:36
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "Adrian Farrel"
> <adrian@olddog.co.uk>
>         Subject:        Re: OSPF ASON Routing Solution
>
>
> Dimitri,
>
> I have a couple of questions. My understanding is that your draft now
> allows
> for 1:N relationship between a routing controller (OSPF speaker) and data
> switch(es) managed by the routing controller. However, I am unclear on
> what
> to be done with the Router_Address TLV? What is the relationship between
> Router Address advertised in this TLV and local TE Router identifier(s)
> advertised,say,  in type 17 Te Link Sub-TLV(s) introduced in 5.1 of the
> draft? When we considered only 1:1 relationship between routing controller
> and data switch, we always considered TE Router ID = Router Address. Is it
> still the case? If not, do you believe that Router_Address TLV is still
> necessary and for what purposes? Should it be modified to mandate
> advertising all TE Router IDs that appear as local TE Router IDs in
> locally
> generated TE Link TLVs? Or may be you believe that Router Address is
> simply
> a local routable IP address and does not have to match any of local TE
> Router IDs?
>
> [dp] in principle, the last alternative (a router_address TLV will be then
> associated and fulfill the function of RFC 3630); i am going to
> incorporate
> this in the next rev. to elevate any potential issue
>

IB>> In other words, you are saying that information advertised in the
Router_Address TLV is not needed for the TE purposes any longer.
I agree

> [dp] please remember that the RC doesn't control "data switches" but "a
> set
> of logical control plane entity that is associated to a single data plane
> (abstract) node" - cf. eval doc.
>
> Furthermore, do you consider N:1 (more than one routing controllers
> managing
> the same data switch, e.g. a controller per layer or region) or/and M:N (
> one controller managing several data switches within one layer of
> multi-layer devices) relationships? Do you believe associating multiple
> controllers (i.e. advertising Router IDs) with the same TE Router ID
> causes
> no problem ?
>
> [dp] per eval doc "The relationship between Ri and Li is simple at any
> moment
> in time: an Li may be advertised by only one Ri at any time." hence, you
> may have multiple Ri but each would advertize an non-overlapping set
>

IB>>Note that in N:1 and M;N configurations an OSPF speaker (and co-located
TE application maintaining TED) will find out that a TE LSA containing local
Te Router ID (in other words, LSA advertising local side of a TE link) was
not generated by the speaker, rather comes from the network (from some other
OSPF speaker associated with the same TE Router ID). On the other hand the
LSA will still have a distinct Advertising Router ID, hence there will be no
ambiguity.

Igor


> Thanks,
> Igor
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <adrian@olddog.co.uk>
> To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
> Sent: Wednesday, July 26, 2006 9:52 AM
> Subject: Re: OSPF ASON Routing Solution
>
>
> > Having seem some discussion of the mechanisms and debate about the
> details,
> > but no objections, we will take this as a WG document.
> >
> > Dimitri, please re-submit as
> draft-ietf-ccamp-gmpls-ason-routing-ospf-00.txt
> >
> > Thanks,
> > Adrian
> > ----- Original Message ----- 
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, July 19, 2006 2:27 PM
> > Subject: Re: OSPF ASON Routing Solution
> >
> >
> > > 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" <adrian@olddog.co.uk>
> > > To: <ccamp@ops.ietf.org>
> > > 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.
> >
> >
> >
>
>
>