Dear Cyril,
It's great that we are having a discussion on this. See my replies inline, look for # Dhruv #. 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: Thursday, December 16, 2010 1:14 AM To: ext Dhruv Dhody; [email protected] Cc: [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 Dhruv, Thanks for your prompt reply, Please see inline > -----Original Message----- > From: ext Dhruv Dhody [mailto:[email protected]] > Sent: Wednesday, December 15, 2010 10:42 PM > To: Margaria, Cyril (NSN - DE/Munich); [email protected] > Cc: [email protected]; [email protected]; [email protected]; > Sprecher, Nurit (NSN - IL/Hod HaSharon) > Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00 > > 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. > I think it should be added in another document, the GMPLS-TE-STD-MIB does not cover several objects, PKS being one of them (lsp attribute is also not covered). <cut timers> > > - 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. The intent of the PKS object is so, but strickly speaking it based on a policy, so non-inter domain is not forbidden. > > - 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. > I think having a string open to the following problem: - arbitrary limit on the path - what is the format?, per RFC5440 it can contain any object represented in a RSVP ERO, which can be: Unnumbered interface (lets say ip address in dotted format and a 0x%08x format) and forward and reverse label (max size:63*4) printed in Hex -> string size is already 1035 : it cannot be represented in the existing string - string parsing without well defined format is prone to have different representation and create parsing problem (already you can represent an Ipv4 address in dotted, hex, decimal, ... format) Its quite likely to have a control plane together with PCE for inter-domain provisioning, so an implementation for ARHop table on the agent and manager side is known. # Dhruv # : We have two option, (1) Keep string but define parsing rules for all possible cases; (2) follow the MIB design for HopTable followed by MPLS-TE. But we should keep in mind the use-case of these two MIBs are different. For PathKey once a PathKey and Confidential Path Segment are generated the Hops will not be modified at all, which is not the case for MPLS-TE-MIB. What is the opinion of others in WG on this? > - 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. I would see the following scenario : a protecting LSP is starting in another domain, excluding the PKS of the working LSP, in that case you might have another client. This is conceptually not excluded. # Dhruv # : I am working under the assumption that PathKey will be expanded only during the signaling (RSVP); so in case of primary or backup, PathKey will always be expanded by the Boundary Node which is also the starting point of the CPS. Can others in WG comment on this. MIB can be extended if there is a use-case for the scenario mentioned by Cyril. > > - 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. I understand a difference between the time the PKS is discarded and it can be reused, for instance it can be discarded after 10 minutes but cannot be reused before 30 minutes as stated in the PKS RFC. This indicate that they could be configured separately # Dhruv # : The global Timers pcePcepPathKeyDiscardTimer (10) pcePcepPathKeyReUseTimer (30) can be modified and are not read-only in the MIB. But the objects which are in the PathKey table [PKS - CPS] - pcePcepPathKeyReuseTime are the value at real-time based on when the PathKey was generated and what is the value of the global timers and thus is always read only. > > - 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
