Subject: Re: L1VPN service models

From: [email-masked]
Date: Thu, 31 Mar 2005 23:45:44 +0200

igor - i say that

1. some signaling specifics can be implemented differently if routing exchanges are made available - therefore the question is whether the approach should make this assumption initially or at later stage (the first example here below)

2. others that will be developed in the signaling context are going to stay even if routing exchanges (reachability for instance) are made available and in addition they will certainly influence how routing exchanges are going to be formalized (the second example here below)

therefore, the point i see is that a strict inclusion is not advisable (see point 1) and a more refined phasing needs to be proposed as the issue of working them all in parallel is also not advisable since potentially mis-leading (see point 2), thus, my take on this is that it should be driven by functionality (as i tried to explain in the below e-mail) but to address them we would ideally need to have the set of specific features per model in addition to the common set proposed in the framework document

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
03/31/2005 12:26 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Alex Zinin <[email-masked]>, Adrian Farrel <[email-masked]>, Tomonori TAKEDA <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
bcc:
Subject: Re: L1VPN service models

Dimitri,

See comments in line.

Igor

--- [email-masked] wrote:

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

igor -

these models will "co-exist" - however, the signaling
model implies a higher load on signaling to achieve
the same functionality compared to a routing+signaling
solution (in particular when an IGP-based approach
will be used)

an example for the link service model is for instance
SRLG per PE-to-PE FA-LSP (TE link) allowing disjoint
path computation (if this information is available at
CE) whereas achieve the same functionality in the
signaling model requires among other exclusion of a
set of resources using an eXclusion Route object when
resource selection is performed exclusively at the PE
side - another example is the call model that replaces
part of the remote CE-PE TE link information exchange
(but there are specific conditions for using the
latter)

IB>> Are saying that ability to signal resource colors
is not needed or less useful in the Signaling &
Routing model? And anyway, this is the basics of the
GMPLS signaling, it is already their. Do you believe
we will need some RSVP-TE extensions for the Signaling
Only model? My point is that Signaling Only model is
contained within Signaling & Routing model in a sense
that whatever available in the former signaling- wise
is also available in the later. However, certain
things that could be resolved via Routing (like
discovery of remote CEs and CE-PE links) needs to be
resolved somehow else in the Signaling Only model
(e.g. via configuration). Hence, Signaling Only model
could be considered (as practical as it is in its own
right) as milestone on the road to the Signaling &
Routing model.

Thanks,
Igor

the question becomes thus for the signaling model
whether a base solution (fully contained for the next
routing+ signaling step) would be satisfactory enough
knowing this approach is going to live on its own
(even if in the future it is going to extended with
some base endpoint reachability information exchange),
it boils down to know whether from the operator side
these models are perceived such that there is an
acceptance that the functionality level could be model
dependent and that for some of these functionalities
an alternative solution would be more appropriate from
moving from one model to another -

section of 4 of the applicability document describes
this as a desirable/recommended approach, however
looking at the framework document there is a list of
common functionality (applying to all models) and then
per model a set of illustrative capabilities, but the
question of level of functionality per model does not
seem clear to me beside the fact that section 6.2
acknowledges that control/management level is service
model dependent

Igor Bryskin <[email-masked]>
Sent by: [email-masked]
03/31/2005 08:37 PST

To: Adrian Farrel <[email-masked]>, Alex Zinin
<[email-masked]>, Kireeti Kompella
<[email-masked]>, Tomonori TAKEDA
<[email-masked]>
cc: [email-masked]
bcc:
Subject: Re: L1VPN service models

Hi,

Just to add a couple of points.

1. Signaling Only model is fully contained within
Signaling & Routing model and is a very practical
first step in providing the full-fetched L1VPNs
solution. Basically, there are certain things that are
required by the application that could've been
naturally provided by the routing exchanges between
the Customer and Provider control planes, but could be
also provided with some limitations and less elegantly
(requiring more manual configurations) by some other
means. The point is that we are not going to
standardize two solutions, rather, one solution in
several incremental steps

2.  The same is true for all sub-models of the
Signaling & Routing model: Per-VPN Peering sub-model
fully contains the Virtual Link sub-model, while the
latter contains the Virtual Node sub-model.

Igor

Adrian Farrel <[email-masked]> wrote:
Hi Alex,

> As promised, I'm reviewing the documents related to
the L1VPN effort.

Thanks!

> In my reading of the framework and applicability
documents, I got a
couple
> of questions, that I think will be important for
chartering this work:
>
> 1. The documents discuss three service models
(management, signaling,
and
> rtg+signalling). Is there an intent to pick a
particular one and
> concentrate on the pieces required for it?
>
> 2. The documents include three submodels for the
rtg+signaling model.
> Is there an intent to pick one of them for
standardization?

All of the service models are real. That is, they are
based on the
discussions in SG13 and come from SPs. Obviously the
IETF should only
concentrate on providing solutions that service
providers really intend to
deploy.

It is worth noting that the management service model
requires no activity
from the IETF.

My personal opinion is that the signaling service
model is the best
short-term solution, and is relatively easy to
implement, but that in the
longer term we will need to include routing function
for a proper and
scalable solution. SPs will be able to say which of
the rtg+signaling
models are of most interest.

Just for the record, I don't think it would be a big
deal to standardise
all of the models. This is not really an
interoperability issue since
these are full network deployment scenarios. Further,
the way that models
are satisfied is mainly an applicability statement
based on the core
protocols (simplistic example: the difference between
the signaling model
and the rtg+signaling model is that you use a routing
protocol in the
latter). Also, the necessary changes in the protocols
to completely fulfil
the models are not large.

Cheers,
Adrian

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

Do you Yahoo!?
Make Yahoo! your home page

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: Tomonori TAKEDA <[email-masked]>
Date: Mon, 04 Apr 2005 15:19:25 +0900

Hi Dimitri, Igor,

I get your points, and here are my personal opinions.

In general, commonalities over models/submodels are important. I think 
there could be several signaling protcol extensions needed from base/common 
specifications only for the signaling model, but they are expected to be 
very minor. (Note it would be also desirable not to extend CEs as much as 
possible, as described in section 4 of applicability analysis I-D.)

One significant difference I think would be whether we rely on manual 
configuration (in the signaling model) or on routing protocols (in the 
signaling and routing model). One typical example is how to acquire 
reachability information.

Best regards,

Tomonori

At 23:45 05/03/31 +0200, [email-masked] wrote:

>igor - i say that
>
>1. some signaling specifics can be implemented differently if routing 
>exchanges are made available - therefore the question is whether the 
>approach should make this assumption initially or at later stage (the 
>first example here below)
>
>2. others that will be developed in the signaling context are going to 
>stay even if routing exchanges (reachability for instance) are made 
>available and in addition they will certainly influence how routing 
>exchanges are going to be formalized (the second example here below)
>
>therefore, the point i see is that a strict inclusion is not advisable 
>(see point 1) and a more refined phasing needs to be proposed as the issue 
>of working them all in parallel is also not advisable since potentially 
>mis-leading (see point 2), thus, my take on this is that it should be 
>driven by functionality (as i tried to explain in the below e-mail) but to 
>address them we would ideally need to have the set of specific features 
>per model in addition to the common set proposed in the framework document
>
>cc: Alex Zinin <[email-masked]>, Adrian Farrel <[email-masked]>, 
>Tomonori TAKEDA <[email-masked]>, [email-masked], Kireeti 
>Kompella <[email-masked]>
>bcc:
><http://mobile.yahoo.com/maildemo>http://mobile.yahoo.com/maildemo

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Apr 2005 19:34:06 -0500

Folks-

 Thanks everyone for your responses.

 It appears that there's an agreement on making the signalling-only model the
 first step and then enhancing it with some routing (for some value of this
 word) mechanisms.

 Before we go further, I'd like to make sure we agree on the bigger picture.
 Correct as needed, pls. Briefly, in the general case:

 CE functionality. Needs to know:

   1) what prefixes are behind other CEs, i.e. reachability information
      Manually configured or smth like OSPF DC in the sig-only case.
      NOTE: in the general case, those don't have to be IP.

   2) set of signaling params. the minimal set is the remote CE interface
      and basic connection characteristics (mux type, BW). advanced cases
      may include more TE information to influence the LSP trajectory.
      Manually configured in the the sig-only case.

   3) how to signal the connection through the provider's cloud

   4) status of established connections

 PE functionality. Needs to know:

   1) (in the sig+rtg model) how to help CEs distribute reachability information
      + (in the per-VPN peer mode) may also need to expose some internal
      topology to the CEs

   2) CE's signaling notation

   3) how to process CE's signaling requests and translate them into internal
      GMPLS LSP requests

   4) how to tell CEs about connection status

--
Alex

---

From: Tomonori TAKEDA <[email-masked]>
Date: Thu, 14 Apr 2005 01:25:26 +0900

Hi Alex,

Thank you very much for your further investigations.

Please see my opinions in line.

 >      NOTE: in the general case, those don't have to be IP.

Yes.

In the sig-only model, customers may wish to obtain prefixes behind other 
CEs, or may not. And mechanisms for customers to obtain reachability 
information behind other CEs are transparent to the provider. In one case, 
as you suggested, customers may wish to obtain reachability information 
behind other CEs via OSPF DC (between CEs). This operation is transparent 
to the provider, and this is out of scope of the L1VPN work.

In the typical deployment scenario, all VPN sites are managed by a single 
administrative entity (operator), and this entity knows prefixes behind 
other CEs.

 >      Manually configured in the the sig-only case.

Yes.

Parameters in existing signaling protocols are good enough to handle all of 
those parameters (see GMPLS overlay I-D).

Note manually configured or something else is out of the scope of the 
protocol (even in the sig+rtg model).

 >   3) how to signal the connection through the provider's cloud

Yes.

As in 2) above, parameters in existing signaling protocols are good enough 
to signal the connection through the provider's cloud. Provider's core 
nodes (PEs and Ps) and CEs all use GMPLS signaling, so no special 
procedures are required.

 >   4) status of established connections

Yes. This is definitely needed.

Since L1VPN connections are just GMPLS LSPs, we can use existing GMPLS 
mechanisms. Namely, we can utilize control plane mechanisms (e.g., Refresh 
messages) to monitor the status of these connections.

Note since we are focusing on GMPLS perspective, mechanisms such as data 
plane OAM mechanisms are out of the scope,

 >      + (in the per-VPN peer mode) may also need to expose some internal

Yes. This is the additional piece required for the sig+rtg model

Note to help CEs distribute reachability information, we already have 
several mechanisms (see GVPN I-D). In addition, the per-VPN peer model is 
conceptually similar to virtual routers although the implementation might 
be different.

 >   2) CE's signaling notation

Yes.

As I mentioned above (2) and 3) in CE functionality), CE's signaling 
notation is just normal GMPLS signaling notation. Inventing new signaling 
protocols is out of the scope for us. There is no reason to assume anything 
except the normal GMPLS signaling.

 >   3) how to process CE's signaling requests and translate them into internal

Yes.

Note we already have several mechanisms, such as stitching/nesting. Here, 
we do not perform any "translation". We expect to use the same signaling 
protocols and formats. The only "mapping" required is from one IP address 
space to another.

 >   4) how to tell CEs about connection status

Yes.

As I mentioned above (4) in CE functionality), we can use existing GMPLS 
mechanisms, such as Refresh, Notify and PathErr.

In summary, I think all items are important functionalities to provide 
L1VPN services, and most of them are already covered by standard GMPLS 
(RFC3473) or proposed extensions (GVPN I-D, GMPLS overlay I-D).

I do not think there are any major items missing here.

Best regards,

Tomonori,