[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Questions on GMPLS ASON OSPF-TE ID



hi  - see inline




"Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
Sent by: owner-ccamp@ops.ietf.org
07/11/2006 06:56
 
        To:     <dpapadimitriou@psg.com>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "ccamp" <ccamp@ops.ietf.org>, <rabbat@alum.mit.edu>
        Subject:        RE: Questions on GMPLS ASON OSPF-TE ID


Hi Dimitri,
 
Thanks for your responses. Please see in-line for [SCB]
 
Snigdho
 
 

From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
Sent: Mon 11/6/2006 6:12 PM
To: Bardalai, Snigdho
Cc: ccamp; rabbat@alum.mit.edu
Subject: Re: Questions on GMPLS ASON OSPF-TE ID

hi - see inline

Bardalai, Snigdho wrote:

> Hi Dimitri,
> 
> As mentioned in today's meeting I have the following questions on this
> ID:
> 
> 1. The Addressing Draft requires that the TERouterID to be an 
addressable IP
>     address i.e. one can ping this address.
> 
>     The ID needs to clearly state what is the requirement for ASON.

isn't section 5.1 clear enough concerning this TE Router ID usage ?
[SCB] I am a bit confused because as per RFC3630 each router can only
           advertise one router address top level TLV. In case a router
           represents "N" TE nodes then there can be multiple TE Router 
IDs.
           My question is - which TE Router ID can be set in the router 
address
           TLV ?

[dp] and this document does also advertize one router_address top level 
TLV (not multiple per TE LSA), not because there is a TE router ID 
associated to each Li that multiple router_address TLV are being used 
within a given TE LSA - 

note that ASON does not list requirements on TE Router ID itself (since
implementation independent)
[SCB] OK.

> 2. Upward / downward LSA transformation
> 
>     When LSAs are exported from one level to another then these LSAs 
need to be
>     transformed. The ID does not clearly specify how the transformation 
takes place.
> 
>     The specific scenarios are:
>     + Upward LSA transformation - what values are used for the adv 
Router ID, Router Address
>        and LINK ID ?

see below

>     + Downward LSA transformation - what values are used (for above 
mentioned fields) ?

only case where there is any information processing is in case of
reachability such as to aggregate information

for the rest everything there is no processing of the opaque LSA
information -
[SCB] What about downward dissemination of higher level topology elements 
? 
[dp] i don't catch the exact point here - would you clarify
concerning the adv.router_id i will add a statement in next revision
(without any surprise here)
[SCB] OK, and what about the associated TE Router ID for the reachability 
information ?
[dp] do you mean in case you would be aggregating reachability from 
multiple TE router ID, how the latter would be aggregated - note that the 
reachability information is part of a separate sub-TLV than the TE router 
ID sub-TLV - meaning aggregation could be performed on behalf of the 
advertizing node leaving the answer here quite straightforward
> 3. TE Links LSAs
> 
>     From reading the ID I can infer that every TE link advertised at a 
particular level
>     needs to be a link between 2 routers i.e. Router ID, because the 
LINK ID MUST
>     be set to the neighboring router's Router ID as per RFC 3630.

yes - there is no need to change anything from that perspective

>     In that case when there is only one router for a set of TE nodes 
then how will
>     the TE link LSAs look like when they get advertised by that single 
router. Or is it
>     expected that these TE link LSAs never get advertised by that single 
router
>     (i.e. all TE nodes must get represented as an abstract node) ?

ok i see ... there is no advertizement of internal structure of abstract
nodes otherwise make use of the logical link case - see RFC 4652
 
[SCB] So are we saying logical links are limited to cases 1 & 2 ?

[dp] logical links case only holds when a configuration like depicted in 
Fig. 2 of RFC 4652 holds

> 4. Upward / downward discovery and selection
> 
>    The ID describes a procedure by which routers can automatically 
discover and select
>    the upward and downward speaker router.
> 
>    It is quite clear that when the current speaker sees a router with a 
router ID larger than
>    its own and the U or D bit set it will stop importing or exporting 
LSAs.
> 
>    What is not clear is that how does the router with the highest router 
ID know when to
>    start importing or exporting LSAs, because it has no knowledge which 
is the current
>    speaker and there is no clear way to figure out when it has stopped 
importing or exporting
>    LSAs.
> 
>    Could you please explain how this works ?

hysteresis mechanisms is expained in section 6.2.1 prevents from
disturbing the routing information dissemination process once selection
has been performed - so the condition you are describing does not occur
if import/export is already in place.
 
[SCB] There are 2 types of information that is being discussed here -
            1. regular routing information being flooded in the area
            2. upward / downward routing information
 
           The rule is that the router with the highest router ID will 
disseminate
           the upward / downward information. The router with the highest 
router ID
           is identified using the regular routing information being 
flooded in the area.
 
           Now a new router is added which is the highest router ID. This 
router
           must NOT disseminate upward/downward routing information even 
though it
           has the highest router ID because another router is already 
selected. How does
           it figure out that it must NOT disseminate the upward / 
downward routing information
           i.e. another router is already selected for the job ?

[dp] your question boils down to: how does the highest router_id that pops 
up know whether there is an already selected router_id already operating - 
here a couple of lines will be added because the default process was menat 
to allow manual control of the switchover but i can automate the process 
by planning a release (by MaxAging previous selection)

hope this clarifies
- d.



> Thanks,
> Snigdho
>