Subject: Re: L1VPN service models

From: [email-masked]
Date: Thu, 31 Mar 2005 13:53:42 +0200

hi alex - see in-line for some comments

Alex Zinin <[email-masked]>
Sent by: [email-masked]
03/29/2005 17:09 PST
Please respond to Alex Zinin

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

Adrian, Takeda, et al-

// rtg-dir cc'ed here

As promised, I'm reviewing the documents related to the L1VPN effort.
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?

=> each of these models has its applicability, the only question is whether we can assume that the rtg+sig mode needs to be worked together or phased (always the same question are the operators looking for the rtg+sig model as final target going directly to rtg+sig capability before deploying or start with sig interactions and then extend with routing interactions) - note: most of the remaining work concerning the sig model is to detail the "membership" information exchange between PEs

2. The documents include three submodels for the rtg+signaling model.
Is there an intent to pick one of them for standardization?

=> virtual node and virtual link are two (sub-)models on their own, the peer service is more a "meta" model (as indeed it can be constructed from the others in addition to peer control plane interconnection model specifics as its name indicates), there is a probably a need to refine the first two base approaches before writing down the full details for the later

Thank you.

--
Alex
http://www.psg.com/~zinin

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 31 Mar 2005 08:37:51 -0800 (PST)

Hi,

Just to add a couple of points.

   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!

> 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

---

From: [email-masked]
Date: Thu, 31 Mar 2005 22:14:39 +0200

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)

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

---

Hi,

   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

    Hi Alex,

    Thanks!

    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.

    short-term solution, and is relatively easy to implement, but that in
the

    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!?

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 31 Mar 2005 12:26:16 -0800 (PST)

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,

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

Thanks!

> In my reading of the framework and applicability
documents, I got a
couple
> 1. The documents discuss three service models
(management, signaling,
and
> 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!?

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

---

From: [email-masked]
Date: Thu, 14 Apr 2005 20:23:47 +0200

hi tomonori, all

see in-line - starting with [dp]

At 19:34 05/04/07 -0500, Alex Zinin wrote:
> 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.

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.

[dp] in fact this is pointing us to one of the fundamental issues that were
never part of any GMPLS discussion in the overlay model context, the
address
resolution problem without which all mechanism from the CE are simple
manual

[dp] the other question is of course ensure proper reachability information
exchange among PE's such that incoming request can be routed toward the
appropriate egress PE

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

[dp] as usual, we would have two cases in the single carrier context,
single
AS vs multiple AS

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

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.

[dp] see point 3 here below

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

[dp] ok - here there is a need to analyze details in terms of requirements
concerning PathErr/ResvErr information exchange through the IF_ID RSVP_HOP
object TLV and further refine the Notify message exchange

> 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

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

[dp] this is definitelly one of the major piece of work for this 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
>      GMPLS LSP requests

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.

[dp] CE's signaling requests are expected to make use of GMPLS LSP request,
the point here is to detail operations such as nesting, shuffling, etc. in
the network, the latter (i.e. shuffling) implies protocol operations for
objects SESSION, SENDER_TEMPLATE, FILTER_SPEC, etc. that carries end-to-end
significant addresses ... example translation of sessions lists when Notify
messages crosses PE's

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

[dp] concerning the signaling most of the details would indeed be related
to the shuffling operation, concerning reachability information exchange
both cases i.e between PE's only (sig model) and between CE's through PE's
(sig+rtg model) requires further work

[dp] i would like also to know whether there is an assumption about
homogeneity of the protocols (same protocol running between CE-PE and
PE-..-PE) or can we assume that a different protocol can be running between
CE-PE and between PE's ?

Best regards,

Tomonori,