Re: OSPF ASON Routing Solution

[[e-mail]]

hi igor - see in-line




"Igor Bryskin" <[e-mail]>
28/07/2006 16:36
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[e-mail]>, "Adrian Farrel" 
<[e-mail]>
        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

[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

Thanks,
Igor

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
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" <[e-mail]>
> To: <[e-mail]>
> 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" <[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.
>
>
>