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

[Acee Lindem <acee@cisco.com>]

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.

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.

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?

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.

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

  Finally, since this is going to require advertisement of more
  than a single area-ID, please allocate a separate opaque LSA
  for ASON purposes.

Section 6.2 - Are you suggesting a single area ID or an area ID
  path (similar to the BGP AS path)? 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?


Thanks,
Acee