Subject: [PEPPERMINT] Some comments on ESPP

From: Otmar Lendl <[email-masked]>
Date: Mon, 14 Apr 2008 16:45:39 +0200

I've meant to send a detailed review of ESPP for a while now, some
fragements of which have be languishing in my draft-mail folder.

To get things moving, here are my (incomplete) notes on ESPP:

---------------------

I've now read the ESPP drafts; these are valuable contributions both
to the peppermint bof, als well as to the speermint WG.

There are some good ideas in ESPP, as well as (IMHO) problems.

First of all, let's take a look at the data model which underpin ESPP:

-----

                                                      +----------------+
                           A Route is associated with |NAPTR:          |
        +----------------+ zero or more SBE NAPTRs.   |id,enterpriseId,|
        |                |--------------------------->|order,pref,     |
        |Route:          | NAPTRs associated with     |flags,svcs,regx,|
        |id,enterpriseId,| Routes are not User or TN  |repl,extension  |
        |routeName,      | specific. The user portion +----------------+
        |isLnService,    | of the regex will be "\\1".
        |sbeNAPTRs,      |                            +----------------+
        |extension       |                            |Egress Route:   |
        |                |<---------------------------|id,enterpriseId,|
        +----------------+ An EgressRoute is          |routeIds,pref,  |
                        ^  associated with zero or    |svcs,           |
         A Service Area |  more Routes.               |regxRewriteRule,|
         is associated  |                             |extension       |
         with 1 or more |                             +----------------+
         Routes         |
                    +----------------+
                    |Service Area:   |
                    |id,enterpriseId,|
               +--->|ServiceAreaName,|<---+
               |    |routeIds,       |    |
               |    |extension       |    |
               |    +----------------+    |
               |An LRN is   |A TNRange is |A Public
               |associated  |associated   |Identify is
               |with only 1 |with only 1  |associated
               |Service     |Service      |with zero or
               |Area.       |Area.        |1 Service Area.
               |            |             |
   +--------------++--------------++--------------+   +--------------+
   |LRN:          ||TNRange:      ||Public        |   |NAPTR:        |
   |id,           ||id,           ||Identity:     |   |id,           |
   |enterpriseId, ||enterpriseId, ||id,           |   |enterpriseId, |
   |lrn,          ||tnRangeStart, ||enterpriseId, |-->|order,pref,   |
   |serviceAreaId,||tnRangeEnd,   ||lrn,          |   |flags,svcs,   |
   |extension     ||serviceAreaId,||serviceAreaId,|   |regx,repl,    |
   |              ||extension     ||extension     |   |extension     |
   +--------------++--------------++--------------+   +--------------+
                                              |
                           A Public Identity  | Multiple Public
                           is associated with | Identities can
                           zero or 1 Private  | be associated
                           Identity           | with 1 Private
                                              | Identity
                                              |
                                              |
                                              |
                                              |
                                              |
                                              V
                                      +----------------+
                                      |Private         |
                                      |Identity:       |
                                      |id,             |
                                      |enterpriseId,   |
                                      |privateIdentity,|
                                      |extension       |
                                      +----------------+
-----

As I view this design, it has two parts:

(1) Mapping endpoint addresses to ServiceAreas
(2) Routing information for ServiceAreas

This separation is a good idea. You should never attach routing
information directly to phone numbers. You first apply some mapping step
to an aggregation object, to which the routing information is attached.

As the draft notes, the potential update-patterns are different in 
these two areas. 

The information in (1) is potentially *huge*; changes are caused by
the normal churn of customers between providers. This will be a steady
stream of updates (without hard realtime requirements), punctured by
occasional bulk updates (network grooming, mergers, ...) plus large
initial data loads.

This is basically a classic example of a directory: the information is
independent on who is asking, data-set is huge, update frequency harmless. 

Comparing (1) to
draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00
I find a very good match: This is exactly what David & co describe in
their draft.

The upper part in the diagram, i.e. (2), is different. This is routing data,
pure and simple.

Here is the point, where I can't follow the authors of ESPP: You don't
"provision" inter-provider routing table entries. That's telco-thinking.
That is maybe IP routing of the 80's. Having a human enter a such a
route into the ESPP system sounds to me like adding a static route to an
IP router.

Yes, you do that on the customer facing interface, but you cetainly
don't do that on a peering router. On a peering router, you configure
the basic parameters of a routing protocol: where are the peers, which
routes to announce, and which conditions learned routes must fulfill.
Manual traffic engineering is done by tweaking the routing protocol,
weighing routes differently based on various criteria, but *never* by
hardcoding routes into the system.

I may be oversensitive to the difference between "provisioning" and
"routing", but this is crucial towards the direction of speermint and
peppermint.

----

Other comments:

* ServiceArea

As I wrote above, the concept is sound. We need such an aggregation
scheme. I'm a bit worried, though, that the "ServiceArea" term is quite
specific to the US cable landscape with operators serving geographically
disjunct regions.

What about a scenario where multiple operators serve the same area,
with number porting between them. ServiceArea "Brooklyn" thus isn't
specific to a single carrier. I'm not quite sure how that fits into
this scheme.

* NAPTR

A provisioning protocol should not be overly tied to the specifics of
the query protocol. I'd feel more comfortable with a provision system
which deals with generic routing information. Whether that information
is then passed to the switches by means of an ENUM response, or via
dumping some sort of proprietary database into the switches should be of
no concern to the provisioning.

NAPTRs are a quirk of the ENUM protocol. They are not the most natural
data format for routing information.

* Transit

I won't make myself popular by bringing this up, but we need to keep the
requirements of provisioning transit in the back of our head.

Like it or not, but we will have to be prepared for it.

What would that mean for ESPP?

I see two basic approaches to implement transit with ESPP:

a) The transit operator announces mappings and routes towards the
destination network as they were part of his own network. Perhaps with a
special ServiceArea designation, but otherwise no changes.

b) The transit operator re-injects number->ServiceArea mappings
unchanged into the other ESPP domain, and only creates new Route objects
announcing the path via this transit operator.

In both cases, it will happen that potential source networks see
competing announcements towards a destination. As I have read ESPP, this
has not been considered.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 14 Apr 2008 09:46:53 -0600

Otmar, Bob, Paul, and all of your who sent comments/issues re: ESPP
Internet-Drafts:

   Thank you for the detailed comments.  This is exactly the type of
review comments we were hoping to get.

   Along with the other co-authors, we're taking notes of these comments
and we plan to review them and send an aggregated response.  Some
comments may lead to bug fixes in the I-Ds, new email threads, etc.  In
the meantime, just wanted to ack the receipt of these and say thanks for
taking the time to read this.

More later.
Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of Otmar Lendl
> Sent: Monday, April 14, 2008 8:46 AM
> To: [email-masked]
> Subject: [PEPPERMINT] Some comments on ESPP
> 
> 
>                                                       +------------
> ----+