Re: [Pce] AD review of draft-ietf-pce-pcep-mib

["Adrian Farrel" <[e-mail]>]

Jon,

Thanks for the work.

Very few responses from me.

> That previous point does cause me to wonder about "PCE capabilities".
> I can see that you have tried to limit this module to describing the
> features that are core to 5440, but I wonder whether that is wise.
> 
> For example, RFCs 5088 and 5089 define a set of PCE capabilities that
> may be advertised in the IGPs and are surely relevant to the model of
> a PCE that speaks PCEP. That information might usefully be seen in the
> module at the PCE, and also at the PCC so that an operator can check
> "why does that PCC keep sending these requests to the wrong PCE?"
> 
> Similarly, the Open Object can carry TLVs that indicate further
> capabilities. Obviously you can't just include all future capabilities
> TLVs since you don't know what they are (well, you know some, but that
> have already been defined, but you can't know the undefined ones). But
> you might want to to look at how those capabilities will be hooked in
> for future accessibility.
> 
> Of particular interest will be the OF-list TLV of RFC 5541.
> 
> >> The scope of the PCEP MIB is currently limited to objects that are core to
RFC
> 5440 only.
> -  The capabilities from RFC 5088/5089 belong in the PCE discovery MIB.
> -  The OFs in the OF-list TLV deserve their own MIB table, which could be
defined
> in a separate MIB if anyone wants it.
> -  There are lots of other PCEP RFCs that we could bring into the scope of
this
> document, but it is already quite large.
> 
> Our preference is to clarify the scope of this document, provide an
informational
> reference to the discovery MIB, and allow other documents to augment /
> supplement the tables we have defined. <<

OK. Sure.
So make sure you have the cross-pointer to the disco MIB module, and think about
how future modules might be able to extend/augment without high price.
For example, a TC that is the bit flags for capability is easily extended (if it
is in a separate module).

> ---
>
> I'm wondering under what circumstances the pcepEntityTable has more than
> one entry. You might describe that in 4.1 and also in the Description
> clause for the table.
> 
> That would tie in with explaining why you have an index of
> Unsigned32 (1..2147483647) which allows for quite a lot of entities!
> 
> >> There is one row in this table for each local PCEP entity, of which there
may be
> multiple.
> 
> One scenario is partitioning a physical router into multiple virtual routers,
each
> with its own PCC. Another scenario is managing a device which front-ends
> multiple PCE compute resources, each with a different set of capabilities that
are
> accessed via different IP addresses.
> 
> Although there clearly won't be billions, we feel there's no point in placing
an
> arbitrary upper limit on the number of local PCEP entities. Our proposal,
> therefore, is to remove the artificial restriction on the entity index range.
<<

OK, I have a bit of a hope that you are doing this because you have a need, not
because it looks like a cool idea! If your text above is just you scraping
around for reasons that might justify the structure you have documented, well,
then you know what you should do :-)

I am trying to compare the case of six physically diverse nodes each with their
own instance of the MIB module, and one physical node hosting 6 virtual
pcepEntities each as a separate entry in the pcepEntityTable.

In the first case, SNMP would use a different IP address to Get each entry in
each pcepEntityTable.

In the second case you are suggesting, I think, that there is one SNMP agent on
the physical node that maintains one copy of the pcepEntityTable, but that each
entry in the table is a separate virtual node. This, I suppose, saves you from
having to run a separate SNMP agent on each virtual node even though those
virtual nodes are separately addressable.

I have no experience of building virtual nodes in this way. I went back to 4750
to see how this is modelled in OSPF and found that it looks to me that in that
case you would run a separate agent for each router instance (of course how you
manage the code and executables -- and even the data -- is up to you, but the
structure of the MIB module is for a single agent per router instance). That is
clearly shown by the fact that ospfRouterId is a member of ospfGeneralGroup
(what you might call a global variable).

Because I have no experience in this, I am not going to require you to change
this structure, but I will ask you to explain how "One scenario is partitioning
a physical router into multiple virtual routers, each
with its own PCC" integrates with 4750.

Bottom line: if you intend that multiple local PC* instantiations can appear in
the same table, please make this a bit clearer in the text.

Anyway, I still think that Unsigned32 (1..2147483647) may be generous.

> Actually, I'm a bit confused about the indexing of the three tables.

OK, we can snip here. Given your use of the pcepEntityTable, the remaining
indexing makes sense. You will, however, need to add text to explain it.

Cheerio,
Adrian