Subject: Re: [Pce] Ramblings of two old dogs

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Feb 2013 21:50:14 -0000

Hi Xian,

I was just going through everyone's comments to update the draft and I had a
question about one of the points you raised...

> Q19:
> Is there a reason why the other sub-type of an active PCE is left out? IMHO,
an
> active PCE with the ability to issue new route recommendations would be also,
> maybe even more, like an NMS, as compared to the case mentioned. For an
> active PCE with LSP delegation, at least the LSP is initiated by the head-end
nodes
> and it has the root control when needed. :-)

I wondered what you meant by "sub-type of an active PCE".
Possibly you mean stateful vs stateless. Or maybe you are suggesting that there
are two types "recommend paths" and "provision paths".

In the first case, I don't think there is any distinction to be made. As the
current text notes, an Active PCE is likely to hold state for at least the LSPs
for which it can issue route recommendations.

In the second case you would be suggesting an option I personally don't consider
is allowable. That is, a PCE cannot, IMHO, provision paths. It can only issue
recommendations for rerouting of LSPs that have been delegated to it.

Thus you have drawn out an important distinction between an NMS and an Active
PCE. That is, the NMS can provision new LSP and has control over existing LSPs.
The Active PCE cannot provision new LSPs and can only suggest changes to
existing LSPs. I have added a little text about this to Section 19.

Cheers,
Adrian

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 25 Feb 2013 23:18:43 +0000

Hi, Dear Adrian, 
  
   I am confused by the explanation you provided below. 

   My question originated from the definition of an active PCE provided in section 17(copied in below). 

An Active PCE is one that issues provisioning "recommendations" to
   the network.  These recommendations may be new routes for existing
   LSPs, or routes for new LSPs.

   In Section 19, it only talks about LSP delegation(which means "new routes for existing LSPs"). Thus, the second part, i.e. "routes for new LSPs" is ruled out. So, my question was about why that second part is left out, (which i call another sub-type of an active PCE). From your explanation below, it seems to me that an active PCE should not even provide routes for new LSPs?

   I understand that for a passive PCE, it is ineed a recommendation since the PCC can decide it can discard the route suggestion from a PCE and use a complete different route. But I do not see the difference in the active PCE case(recommendations=provisioning). If the control of a LSP is handed over to the PCE, then when it returns the "recommendations" to the PCC, the PCC has to start the provisioning straightaway. So, no matter whatever we call it, it has the same effect, i.e. a new LSP will be set up, right?  

Regards,

Xian
________________________________________
发件人: Adrian Farrel [[email-masked]]
发送时间: 2013年2月22日 5:50
到: Zhangxian (Xian)
Cc: [email-masked]
主题: RE: [Pce] Ramblings of two old dogs

Hi Xian,

an
nodes

Cheers,
Adrian

---

From: Ramon Casellas <[email-masked]>
Date: Tue, 26 Feb 2013 08:44:59 +0100

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]

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 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. 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.

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.

Thanks and best regards
R,

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 26 Feb 2013 10:48:56 +0000

> From: Ramon Casellas
> Sent: Tuesday, February 26, 2013 8:45 AM
> 
> 
> Dear Xian, Adrian, all,
> 

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.

> 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.

> 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

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. 

> 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-masked]
> https://www.ietf.org/mailman/listinfo/pce