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

[Acee Lindem <[e-mail]>]

Hi Lyndon,
Ong, Lyndon wrote:

>hi dimitri,
>
>I agree regarding the existing LSA, it needs to retain the link_ID.
>I thought that Acee was perhaps suggesting a new LSA
>where link_id would not be mandatory.   
>  
>
I blieve you mean making the link_id optional when the new sub-TLV was 
advertised -
we certainly don't want a new LSA. But no, I was suggesting defining 
link_id as the
end point of the link rather than the advertising router (which I don't 
is contrary to
RFC 3630)
Thanks,
Acee

>Lyndon 
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] 
>Sent: Friday, July 07, 2006 5:14 AM
>To: Ong, Lyndon
>Cc: Acee Lindem; [e-mail]; [e-mail]
>Subject: RE: Comments on
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>hi lyndon
>
>the link_id remains the mandatory sub-tlv including the remote router_id
>from 3630 - 
>
>the link_id remains thus as defined in that rfc - translated into the
>terminology used in ason it represents the remote RC_ID
>
>does it change something in terms of TE/computation - in principle not -
>even if some engines where not able to process such mix of identifiers
>
>thanks,
>- dimitri.
>
>
>
>
>
>
>
>"Ong, Lyndon" <[e-mail]>
>Sent by: [e-mail]
>06/07/2006 23:18
> 
>        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Acee Lindem" 
><[e-mail]>
>        cc:     <[e-mail]>, <[e-mail]>
>        Subject:        RE: Comments on 
>draft-dimitri-ccamp-gmpls-ason-routing-ospf-00.txt
>
>
>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.
>
>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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>  
>