Re: Comments on draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt

[Acee Lindem <[e-mail]>]

Ong, Lyndon wrote:

>Hi Dimitri, Acee,
>
>Just a small comment on the Link_ID - I think Dimitri is right that the
>Link_ID and the Local/Remote TE_Router_ID have different meanings and
>must not be confused.  On the other hand, Acee may have a point that the
>Link_ID actually is no longer necessary once you have the Local/Remote
>TE_Router_ID - we found in some prototyping that with the separation
>of the Router_ID and TE_Router_ID that it became somewhat arbitrary as
>to what value you gave as the remote Router_ID, this was not used in
>  
>

>path computation at all.
>  
>
Hi Lyndon,

Exactly my point but I seemed to be getting into a circular argument. 
 From the standpoint of TE,
you only care about the entity to which link actually connects.  Also, 
is there any reason why
the TE router ID space and router-id space wouldn't overlapp? I don't 
see one.

Thanks,
Acee

>Cheers,
>
>Lyndon 
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of [e-mail]
>Sent: Thursday, July 06, 2006 11:12 AM
>To: Acee Lindem
>Cc: [e-mail]; [e-mail]
>Subject: Re: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>acee - see inline
>
>
>
>
>Acee Lindem <[e-mail]>
>Sent by: [e-mail]
>06/07/2006 18:36
> 
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>        cc:     [e-mail]
>        Subject:        Re: Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>  
>
>>Dimitri,
>>
>>Here are my comments on the subject document:
>>
>>  General - Describe the relationship of OSPF areas to ASON RAs.
>>  Section 6.1 references     OSPF area ID but the relationship
>>  is implied.
>>
>>[dp] point taken (i guess we did not do a sufficiently good job in RFC 
>>4258 and in the eval doc. as still some questioning remains about 
>>information map)
>>
>>Section  3.2 - The length calculation is simply wrong.  You
>> really don't know how many prefixes you've got until you've
>> parsed them.
>>
>>[dp] which length are you referring to ? the prefix or the sub-TLV ?
>>
>>
>>    
>>
>The TLV length, the nonesense below:
>
>The Length is set to Sum[n][4 + #32-bit words/4] where n is the 
>   number of local prefixes included in the sub-TLV. 
>
>[dp] 4 x n as defined in the node i-d is ok - why not this one 
>
>  
>
>>Section 5.1 - RFC 3620 specifies that the Link-ID Sub-TLV
>> specifies the router-id. Why do you need the remote router-id
>> in this sub-TLV? Could the 5.2 sub-TLV satisfy the
>> requirement?
>>
>>[dp] it is not the router_id but the TE router_ID
>>    
>>
>
>  
>
>>[dp] the issue is that there is no more a there is no more a 1:1 
>>relationship between the Router_ID and the TE Router_ID in the present 
>>context
>>    
>>
>
>I surmised that. Why wouldn't the link ID be the remote TE router ID in
>this case? The advertising router seems irrelevant from a TE standpoint.
>
>[dp] because the router_id is not linked on a 1:1 basis to the TE
>router_id when space is per TE_router_id you need to seggregate this
>information
>
>  
>
>>Section 6.0 - You should NOT need to change OSPF flooding rules.
>> In other words, I don't see the need to specify the following:
>>
>> The Opaque TE LSA re-origination is governed as follows:
>>   - If the target interface is associated to the same area as the
>>     one associated with the receiving interface, the Opaque LSA MUST
>>     NOT be re-originated out that interface.
>>   - If a match is found between the Advertising Router ID in the
>>     header of the received Opaque TE LSA and one of the Router ID
>>     belonging to the area of the target interface, the Opaque LSA
>>     MUST NOT be re-originated out that interface.
>>   - If these two conditions are not met the Opaque TE LSA MAY be re-
>>     originated.
>>
>> Rather you should specify rules for importing/exporting  information 
>>between OSPF instances at different levels.
>>
>>[dp] your proposal is thus to revise these as import/export rules ?
>>in order to prevent having specific flooding rules between levels the 
>>point was to not expand too much on the communication process (inside 
>>the entity) between level adjacent RCs but if this makes you more 
>>confortable i can revise as import/export rules
>>    
>>
>
>The existing RFC 3620 TE opaque LSAs are area scoped LSAs. Area scoped
>LSAs have very well defined flooding rules and, IMHO, you should not be
>trying to roll-your-own flooding rules for this application. Just think
>what a mess we'd have if every party proposed an opaque LSA also
>proposed some flooding hack for their opaque LSA type.
>
>[dp] i don't have any issue to express LSA processing with import and
>export rules (even if there is nothing in 3640 to pass LSA between
>routing
>instance)
>
>  
>
>>Section 6.1 While an RA is completely contained within a single
>>  parent layer RA. A given    RA may have multiple child RAs. 
>>Hence, the election algorithm is broken. 
>>
>>[dp] to make it clear this is not an "election" process
>>
>>At a minimum,
>>  you must advertise all your child areas.  Also, you MUST state
>>  that reachability is a precondition for considering a router
>>  eligible to pass information between levels.
>>
>>[dp] upper not lower (it is a discovery from a given to an upper parent
>>    
>>
>
>  
>
>>viewpoint, where a child has a unique parent)
>>
>>
>>    
>>
>I get from RFC 4258 that a child RA will be contained within a single
>parent RA. However, no where do I that a parent RA can have a single
>child RA. So, if a single RC in a parent RA has multiple child RAs, you
>need to advertise more than one area ID.
>
>[dp] the parent is unique why multiple parent area id
>
>Also, you did not address the requirement for reachability. What if the
>RA becomes partitioned or the advertising RC goes down without
>withdrawing its advertisements. 
>You MUST deal
>this - it is simply broken the way it is.
>
>[dp] situation is the same as with a single ABR case, in case of
>multiple RC's you are expected to be aware of the broken RC -
>
>  
>
>>  Finally, since this is going to require advertisement of more
>>  than a single area-ID, please allocate a separate opaque LSA
>>  for ASON purposes.
>>
>>[dp] having clarified the above is that still needed ?
>>
>>
>>    
>>
>You only clarified that it is wrong.
>
>[dp] not sure to capture your point - but ok - 
>
>  
>
>>Section 6.2 - Are you suggesting a single area ID or an area ID
>>  path (similar to the BGP AS path)? 
>>
>>[dp] the former
>>
>>I guess this may work if you
>>  always advertise you own area ID when redistributing between
>>  areas (relying on the fact that a child area is completely
>>  contained by its parent). I'm going to think more about this
>>  encourage others to do the same.
>>
>>General: Have you considered aggregation?
>>
>>[dp] at which level - reachability can be aggregated for inst.
>>
>>
>>    
>>
>Than the rules for aggregation should be specified.
>
>[dp] can add base guidelines if needed
>
>Thanks,
>Acee
>
>  
>
>>Thanks,
>>Acee
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>