Hi Adrian I owe you a reply on the requirement for the entity table - my apologies for the delay.
The entity table was a feature of the PCEP MIB before I took over editorship of it, so I will defer to the original authors for their motivation in including it. However, speaking purely for my own implementation, we do need it for the reasons I gave below and it is used in practice. I don't think this MIB structure is inconsistent with RFC 4750 as it does not prevent an implementation from having one SNMP subagent per routing instance, as RFC 4750 would seem to require. (I am not sure I understand the RFC 4750 model though. As it stands, wouldn't you need one subagent per PE/CE routing instance, or per network layer routing instance in a multi-layer router? Is that really the normal case?) I'm currently in the process of clarifying the text regarding the entity table and will get back to you on that. Best regards Jon -----Original Message----- From: Adrian Farrel [mailto:[email protected]] Sent: 20 August 2014 10:42 To: Jonathan Hardwick Cc: [email protected]; [email protected] Subject: RE: [Pce] AD review of draft-ietf-pce-pcep-mib 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
