Dear Cyril,
Thanks for your detailed review. Please find my comments inline. Regards, Dhruv Dhruv Dhody Senior Technical Leader Huawei-Santa Clara, CA Work: (408) 330 4940 Cell: (408) 667 8127 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email protected]] Sent: Wednesday, December 15, 2010 6:15 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; Sprecher, Nurit (NSN - IL/Hod HaSharon) Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 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. >>>>> I agree there is a need for PKS; but though this MIB will not directly use this object, is it correct to add in this document? We can discuss on this. - 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? >>>>> This is kept consistent with other PCEP MIB drafts. It can be taken up along with other PCEP MIB drafts. PCEP MIB draft uses "seconds"; we kept minutes to keep more readable and consistent with RFC. Once PCEP main MIB would follow a standard the same can be applied here. - pcePcepPathKeyReUseTimer : the minimum reuse time is equivalent to 30 minutes (RFC5520, section 2.1.), unit (I would propose ms) should be added. >>>>> Same as above. - 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. >>>>> This is kept it consistent with PCEP MIB draft. Regarding use of "inter-domain"; path-key is applied only when we are sending path outside the domain. There is no impact on MIB either way. We can make it generic if needed. - 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. >>>>> We thought that use of HopTable is more useful in MPLS-TE MIB, where the Table exist in Ingress, Egress as well as on Transit Router Node. We wanted to have a simpler implementation like that of explicit path "mplsPathExplicitRoute" followed by some MIBs. Having HopTable would unnecessarily complicate the implementation. - 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. >>>>> PathKey would be retrieved from a particular PCC which is the starting hop of the confidential path (CPS); we don't think a retrieval of the exact same path key would happen from multiple PCC, there would be different path-keys in that case. - 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 >>>>> This is value based on the time the pathkey was generated; and overall time when a path-key can be reused "pcePcepPathKeyReUseTimer"; so we believe we cannot directly modify pcePcepPathKeyReuseTime values via MIB; this value can change based on the change on the above two parameters. - a pcePcepPathKeyCreationTime TimeStamp, would also be usefull I believe. >>>>> I agree, thanks, I will add this. - I am missing a row status, I think it should be possible to manually delete PKS, >>>>> I don't think we would have a case where path-key is either generated or deleted via MIB operation. What do others in WG think? Best Regards >>>>> I again thank you for the detailed reviews!!! > -----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
