> From: Ramon Casellas > Sent: Tuesday, February 26, 2013 8:45 AM > > > Dear Xian, Adrian, all, > > Sorry for chiming in, this was one of the points discussed in Atlanta > and, IMHO, the taxonomy that I feel comfortable with after discussing > with some involved authors > > a) Stateless PCE > > b) Stateful PCE [LSPDB] > > b.1) Passive stateful PCE [ ~LSPDB for the purposes of path > computation ] > > b.2) Active stateful PCE [can affect state of delegated LSPs...] > > b.2.1) Active stateful PCE without instantiation capabilities > > b.2.2) Active stateful PCE with instantiation capabilities > [... > and can instantiate new LSPs. Instantiated LSPs are automatically > delegated] >
Dear Ramon,all I think that this classification is very useful and all those should be distinguished. The security and policy implications of each kind of PCE are very different. > > It seems to me that there is no agreement regarding whether b.2.2 > should > be a function of a PCE. If I remember correctly, it has been mentioned > that this is (at least for now) out of charter > > Adrian (correct me if wrong!) has stated his personal preference to > _not_ include such function. Oscar, Ina, Jan, Cyril, Ed. etc. have also > discussed about this ( I cannot comment on their preferences). > Arguments > given against is that this should be a function of an NMS, a VNTM, a > provisioning manager, etc. On the other hand, accepting it to be a > function of the PCE seems to build on top of the existing PCEP to > define > what otherwise would be an undefined interface ? I do not completely agree, having a well separated component and responsibility does not imply the protocol is not strongly PCEP based. I think it should be possible to survive having 2 protocol running side-by-side and having the same SESSION object to correlate things. > I don't have a strong opinion, but instantiation of LSPs being a > function of an NMS does not necessarily exclude a PCE from being able > to > do so. This goes in both direction, having a provisioning manager does not exclude an PCE to include it, > > An NMS could use a (to be defined) PCE northbound interface and > the active stateful with instantiation capabilities can use the PCEP > session to instantiate such LSPs. I think this is exactly why the abno architecture is needed. The NMS can already use the PCEP to calculate route, it can use the PCEP "provisioning" extensions to instantiate the LSPs too. You do not need another interface. From an arch. Point of view the PCE is still acting as the provisioning manager, I do fail to see a good reason not to have a separated provisioning manager. > > Comments or thoughts? Given that Ina, Ed, Xian are leading the work on > stateful PCE and that there are a couple of drafts discussion > instantiation of LSPs (i.e. PCCreate) both in MPLS and GMPLS networks, > it would be interesting to know the wg opinion about this. It would be > great it we could gather arguments for and against. > I think we could allow the LSP-DB update protocol, and provisioning manager <-> Network protocol to be separated "stateful PCEP" sessions, or even separated protocols. I think those protocol should be based on PCEP. This would allow to have separated protocol or all multiplexed into one PCEP session. > Thanks and best regards > R, > > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
