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

[dimitri papadimitriou <dpapadimitriou@psg.com>]

dean

thanks for commenting - see in-line

Dean Cheng (dcheng) wrote:

> Dimitri,
>  
> I've some comments now as follows:
>  
> 1) The third paragraph of section 6.1, it says, "....However, an
>     additional restriction MUST be applied such that the RC 
>     selection process takes into account that an upper level may
>     be adjacent to one or more lower levels."
>
>     It would be good to clarify the words "one or more lower levels"
>     here. From the sentence after that, it actually means one or 
>     more areas at the lower levels.

ok

> 2) In section 6.1, it says that the D bit is used together with the
>    "Associated Area ID" sub-tlv, as "an additional restriction". In
>     the same section, it does not mention the use of that sub-tlv
>     along with U bit.
>  
>    But in section 6.2.1 and 6.2.2, it explicitly says that the
> "Associated
>    Area ID" sub-tlv is included when re-originating the opaque LSA 
>    downward or upward. 
>  
>    It would require clarification and consistency here.

i will split this section 6.1 into two parts and refer to section 6.2 
for the case addressed by that section

> 3) In section 6.1 (Discovery and Selection), it describes a method
>     for "selecting" the RC that performs the upward/downward
> dissemination
>     of routing information. 
>  
>     What happens if RC1 is currently the RC that doing the upward
> advertising
>     but RC2 just becomes active with U-bit set and a higher Router ID ? 
>  
>     I guess the same handling as OSPF DR's election can be used for
>     stability purpose, and also for consistency, and if so, needs to be
> stated 
>     in this section. 

indeed hysteresis mechanism is needed in such condition

> And for that matter, the word "selection" vs.
> "election" does not really make much difference.
>  
> 4) In section 7.2, it is also useful to add that the number of levels be
> under
>     policy control.

ok

> 5) It would be useful to add an interoperability section, which
> describes how
>     an traditional OSPF node/network interoperates (if need to) with an
> OSPF 
>     node/network with extensions as described in this ID. E.g., a
> reachable
>     address (prefix) is advertised by an ABR normally but with this ID,
> can also
>     be advertised through hierarchy.

i guess you mean a GMPLS LSR not implementing these extensions ?

thanks,
- dimitri.

> Thanks
> Dean 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   
>  
>  
>  
>  
>  
>  
>  
>