Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09

[t.petch <[e-mail]>]

At the end ...

----- Original Message -----
From: "Jonathan Hardwick" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, August 18, 2014 3:36 PM
Subject: RE: [Pce] Regarding draft-ietf-pce-pcep-mib-09


Tom, many thanks for your comments.  See [jon]... [/jon] inline below.
Cheers
Jon


-----Original Message-----
From: t.petch [mailto:[e-mail]]
Sent: 15 August 2014 12:33
To: Jonathan Hardwick
Cc: [e-mail]; [e-mail]
Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09

Jon

Picking up two of Adrian's points:

- I would never have known the idea was to have multiple entities in a
single 'box' modelled in the one MIB  module - I think this unusual and
while fine to do it, I would like to see it spelt out in s.4.1.  It is
often a source of confusion what an instance of an 'object class'
actually is, which I think confused Adrian as well as me

[jon] Agreed, I will spell it out more clearly as this has obviously
caused some confusion. [/jon]


- on the question of how many supported protocols, there used to be an
enumeration
" ipV4: PceRoutingDomainID is an InetAddressIPv4 ..
  ipV6:  PceRoutingDomainID is an InetAddressIPv6
  nsap:  PceRoutingDomainID type is OCTET STRING (SIZE (0..20)),
               corresponding to the name of an ISIS area
  asNumber:  PceRoutingDomainID type is OCTET STRING (SIZE (2))
               corresponding to the name of an Autonomous System."
but I assume that such concepts are long gone.

[jon] Yes, the TC MIB has expired and is not needed by the current MIB.
I don't think this TC was ever used by the PCEP MIB. [/jon]


A trivial point of my own
 s/estbalished./established./

[jon] Thanks - will fix. [/jon]


And does pcePcepSessState need to reflect the various contortions a
shutdown can go through

[jon] We decided to keep the states in line with RFC 5440 which does not
specify any additional states during shutdown (the FSM goes straight to
"idle").  It is possible that implementations may use intermediate
shutdown states such as "quiescing" but I think these are probably best
done in an implementation-specific field which modifies the "sessionUp"
state. [/jon]


, or all the various wait states of no interest?

[jon] I think the wait states are useful. If a session is stuck not
coming up, the operator will find it helpful to know if this is because
the session is stuck in tcpPending, openWait or keepWait. [/jon]

A sometime practice with other models of sessions is to keep information
around for a while so that it is possible to tell what caused the
shutdown.

[jon] I think that the relevant information (which may be quite
detailed) should be available in logs, and that logging interfaces would
be better suited to it.  Is it common to provide this type of thing in
MIBs - can you point me to any examples? [/jon]

<tp>

Jon

There are not that many session protocols to choose from in the IETF but
TCP is richly endowed with information about its sessions, as in RFC4898
and RFC4022, but more humble protocols also tend to follow the practice,
such as draft-ietf-forces-mib or RFC7331 (bfd).

In the current climate, I expect that we should be grateful for anything
in a MIB module:-(

Tom Petch

----- Original Message -----
From: "Jonathan Hardwick" <[e-mail]>
To: "Dhruv Dhody" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, August 14, 2014 12:27 PM
Subject: Re: [Pce] Regarding draft-ietf-pce-pcep-mib-09
<snip>