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

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

Dimitri.Papadimitriou@alcatel.be wrote:
hi acee - thanks for commenting 
Hi Dimitri,
Please see inline.
one or two hints below such as to clarify some point you mentioned here below 




Acee Lindem <acee@cisco.com>
Sent by: owner-ccamp@ops.ietf.org
06/07/2006 03:12

       To:     ccamp@ops.ietf.org
cc: Subject: 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. 


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.


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.


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.
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.



  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.


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.

Thanks,
Acee



Thanks,
Acee