Subject: Re: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 15 Dec 2010 15:14:41 +0100

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-masked] [mailto:[email-masked]] On Behalf Of
> ext Julien Meuric
> Sent: Saturday, November 20, 2010 5:03 PM
> To: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 15 Dec 2010 13:42:00 -0800

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-masked]] 
Sent: Wednesday, December 15, 2010 6:15 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Subject: RE: [Pce] Status of draft-dhody-pce-pcep-pathkey-mib-00

Hi Pcers, authors

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

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

added.

>>>>> Same as above.

- pcePcepPathKeyConfig : 

not scalar.

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

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

RFC5520, section 2.1. : 

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. 

time?

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. 

believe.

>>>>> I agree, thanks, I will add this. 

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

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 16 Dec 2010 10:13:48 +0100

Hi Dhruv, 

Thanks for your prompt reply, 
Please see inline

> From: ext Dhruv Dhody [mailto:[email-masked]]
> Sent: Wednesday, December 15, 2010 10:42 PM
> To: Margaria, Cyril (NSN - DE/Munich); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Sprecher, Nurit (NSN - IL/Hod HaSharon)
> 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!
> 
> >>>>> 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>

>       - the comment state that this is the configuration for inter-
> domain, is there a particular reason to restrict the PKS to inter
> "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
> >>>>> 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.

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

> 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

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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 16 Dec 2010 11:14:26 -0800

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

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 1:14 AM
To: ext Dhruv Dhody; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

Hi Dhruv, 

Please see inline

> From: Margaria, Cyril (NSN - DE/Munich)

[mailto:[email-masked]]

can

also not covered).

<cut timers>

> domain?, if not remove the inter-domain reference would be more

> generic.

a

> HopTable, like the one in rfc3812  : mpls tunnel mib,

> mplsTunnelHopTable

size:63*4) 

# 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? 

> should be a pointer to a table listing all the nodes that retrieved

the

retrieval

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

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

> > From: [email-masked] [mailto:[email-masked]] On Behalf

Of

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