Hi,
I think that Ramon captures the potential set of functions, but I remain uneasy
with the concept of a PCE with instantiation capabilities.
I actually think that the cake has to be cut a different way because I see no
reason why a stateless PCE should not be equally capable of being active (not
withstanding that it is likely to be less useful). So it is probably better to
make a 2d table.
I also think that there are three subdivisions of b.2, not just 2.
I think
b.2.1) Active stateful PCE without instantiation capabilities
can be split into
- issue recommendations for delegated and extant LSPs
- issue recommendations for new LSPs
And I would note that neither of these results automatically in a PCE/LSR
attempting to modify or set up an LSP.
Thus, my second bullet here is very different from "instantiation".
So my table looks like (sorry for using html in an email) ...
| Stateless | Stateful |
------------------------+-----------+-----------+
Passive | 1 | 2 |
Active delegated LSPs | 3 | 4 |
Active new LSPs | 5 | 6 |
Active instantiate LSPs | 7 | 7 |
Notes:
1. Normal for stateless
2. Has value for many more complex environments and for protection
3. Relatively pointless, but can add value at moment of delegation
4. Normal for stateful
5. Marginal potential
6. Has potential for recommending new LSPs
7. Out of scope for PCE
And to add to what Cyril said, just because you use PCEP as communications
protocol, does not mean the thing that speaks is a PCE. PCEP was designed to be
the protocol used by PCEs, but that does not require that only PCEs can speak
PCEP. Also, PCE is a functional component not a product or a box. The function
of PCE is pretty clear. It is OK to invent new functions and new functional
components, and it is OK to bind them closely to PCE both functionally and
within implementations, but let's try to keep the functional units distinct in
our descriptions. This is one of the purposes of this draft and the ABNO work.
Cheers,
Adrian
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Margaria, Cyril (NSN - DE/Munich)
> Sent: 26 February 2013 10:49
> To: ext Ramon Casellas; [email protected]
> Subject: Re: [Pce] 答复: Ramblings of two old dogs
>
>
> > 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
