Hi Pcers, authors

I  have the following technical comments to the draft:

- in current MIB described EROs or RROs (rfc3812, rfc4802) there is no
representation of PKS, this should be added I believe.


- Several timers are defined in the draft, all of them use minutes, 
  I think that using a textual convention for those (like the
LmpInterval in RFC4631) would make the MIB more consistent. 
  In addition I would think that protocol timers are usually using
milliseconds as unit, Is there a specific reason to use minutes?

- pcePcepPathKeyReUseTimer  :  the minimum reuse time is equivalent to
30 minutes (RFC5520, section 2.1.), unit (I would propose ms) should be
added.


- pcePcepPathKeyConfig : 
        - I believe MAX-ACCESS read-create make only sense for tables,
not scalar.
      - the comment state that this is the configuration for
inter-domain, is there a particular reason to restrict the PKS to inter
domain?, if not remove the inter-domain reference would be more generic.

- pcePcepPathKeyPath : this is currently a string, to be consistent with
exiting ERO representation I believe this should be a pointer to a
HopTable, like the one in rfc3812  : mpls tunnel mib, mplsTunnelHopTable
and rfc4802  : gmpls  tunnel MIB gmplsTunnelHopTable.            

- pcePcepPathKeyRetrieveSource : only one entry here, but according to
RFC5520, section 2.1. : 
" A local policy SHOULD be used to determine for how long
  to retain such stored information, and whether to discard the
information after it has been
  queried using the procedures described below.  It is RECOMMENDED for
  a PCE to store the PKS for a period of 10 minutes"

As retention is allowed, more than one PCC (for diversity/route
exclusion purpose for instance) could request a given PKS, so this
should be a pointer to a table listing all the nodes that retrieved the
PKS.

- pcePcepPathKeyReuseTime :
- pcePcepPathKeyDiscardTime : is it a time, an absolute or relative
time?
Why are those object read-only, one could expect that the
pcePcepPathKeyReUseTimer is the policy, but it could be overwritten on a
individual PKS based

- a pcePcepPathKeyCreationTime  TimeStamp, would also be usefull I
believe.
- I am missing a row status, I think it should be possible to manually
delete PKS,  
 

Best Regards


> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> ext Julien Meuric
> Sent: Saturday, November 20, 2010 5:03 PM
> To: [email protected]
> Subject: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00
> 
> Hi all.
> 
> During our meeting in Beijing, draft-dhody-pce-pcep-pathkey-mib was
> presented. Not only defines this I-D a MIB module that is useful for
> the path key mechanism, but also it adresses a requirement explicitly
> stated in our standard track RFCs (RFC 5520), which means the item has
> already been through IETF consensus. All the same, as said during the
> meeting, if you have good reasons to be opposed to take it as WG item,
> you still have a few days to speak before we move forward.
> 
> As usual, technical discussion about the content of the I-D is still
> very welcome.
> 
> Regards,
> 
> JP & Julien
> 
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce

Reply via email to