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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Mar 2013 20:46:52 -0000

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-masked] [mailto:[email-masked]] On Behalf Of
> Margaria, Cyril (NSN - DE/Munich)
> Sent: 26 February 2013 10:49
> To: ext Ramon Casellas; [email-masked]
> 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-masked]
> > https://www.ietf.org/mailman/listinfo/pce
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Mar 2013 12:31:43 -0000

Hello Oscar,

> I fully agree it is important to keep functional elements separated. That
> does not mean a vendor cannot sell a single box with several
> functionalities... 

sell != try_to_sell  :-)

[snip]

> ergo PCEP can be used to provide topology information to the
> PCE... Wait! Heresy!!! IGP does that! TED seems sacred and
> forbidden for PCEP... Syllogism failed... But it seems reporting
> LSP state information is OK....   

Hold on a moment.
Where does it say that the IGP is (MUST be) used for the collection of information in the TED?
In 4655 we have:
   The TED may be fed by Interior
   Gateway Protocol (IGP) extensions or potentially by other means.

Does that mean it makes sense to have each node in the network reporting TED information "northbound"? That depends. It doesn't make sense to me to have two protocols simultaneously doing the same thing in a network. But see BGP-LS.

[snip]

> Finally, Adrian, I would like to ask what would be the process of
> defining extensions of the PCEP protocol to be used by non-PCE
> boxes (and thus, out of current PCE charter).

That's two "finally"s in one email, but we'll let you off because you used "syllogism" in an IETF email, and that surely gains you some points.

The process would be easy...

If there is a WG for the work
   do the work there
   ensure PCE WG review for risks of breaking PCE
Elsif there is IETF support for the work
   do the work as AD sponsored
   ensure PCE WG review for risks of breaking PCE
Else the work to the ISE
   ensure PCE WG review for risks of breaking PCE
Endif

In general, re-use of protocols is a fine thing. Issues are only:
- breakage of existing uses (especially deployments)
- confusion in the market
- twisting or crowding that makes extensions for the
   primary use difficult.

Approaches used in the past for this type of thing have included:
- no distinction at all
- distinct ranges of TLV/message identifiers
- separation of protocol instances
- use of a new protocol number or port numbers even when the
   core protocol is the same

A