Subject: Re: L1VPN service models

From: Tomonori TAKEDA <[email-masked]>
Date: Wed, 20 Apr 2005 18:01:51 +0900

Hi Dimitri,

Thank you very much for your comments, and sorry for late response.

Please see in-line.

At 20:23 05/04/14 +0200, [email-masked] wrote:

>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

OK. There may be a need to further consider this issue.

Note this functionality is not L1VPN specific, and that is why I mentioned 
this is out of scope of the L1VPN work.

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

Agreed. This is an important functionality for the 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

Yes.

Note, even in multiple ASes, in the single carrier context, addresses may 
be assigned by a single administrative entity.

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

I do not think there is anything special for L1VPNs. Could you please share 
your ideas?

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

OK. First, we need to think whether we would want shuffling as a standard 
mechanism.

My personal opinion is that stitching/nesting already supports required 
mechanisms for L1VPNs. Therefore, I am not sure whether we need another 
approach (shuffling).

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

Agreed.

As I said above, need for shuffling is a subject for discussion.

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

If homegeneity means the same protocol, regardless of the same instance or 
not, then my understanding is that we are looking at homegeneity. For example,
- We would not run GMPLS CR-LDP between CE and PE, and GMPLS RSVP-TE in the 
provider network.
So, there is no need to perform protocol conversion (or parameter mapping).

Best regards,

Tomonori

>Best regards,
>Tomonori,
>  >--
>  >Alex

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 23 Apr 2005 21:05:14 +0100

Hi Alex,

There has been some reasonably constructive discussion on this topic which
to me indicates:
- Not all of the decisions have been taken yet
  Probably a good thing :-)
- There is value in having an open (wider) debate in some
  context perhaps on the L1VPN mailing list.
  If you don't think this is inappropriate, I would like
  someone (Dimitri? Tomonori? me?) to move some of the
  discussion to there.
- There are no *huge* protocol holes that have been identified.
  (I didn't hear anyone say, "And therefore we need a new routing
   protocol.")

Soooo...
How is your assessment coming along? Which way are you inclined to jump?
And what more can we do to help with your evaluation?

Cheers,
Adrian

----- Original Message ----- 
From: "Tomonori TAKEDA" <[email-masked]>
To: <[email-masked]>
Cc: "Alex Zinin" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Kireeti Kompella" <[email-masked]>; "Igor
Bryskin" <[email-masked]>; "Adrian Farrel" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, April 20, 2005 10:01 AM
Subject: Re: L1VPN service models

---

From: Alex Zinin <[email-masked]>
Date: Mon, 25 Apr 2005 13:55:31 -0700

Adrian, et al-

 Sorry for the delay. I took some time off last week.
 I'll catch up on this within a couple of days and get back to you.

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 3 May 2005 03:23:25 -0700

Adrian, et al-

 I think we can go ahead with this. Agree with Adrian--let's talk the
 technical part of the discussion to the list--Dimitri, Tomonori, please
 follow up on this.

 Bill and I would like this to be a separate WG, so we need to start
 working on the charter, which implies that we need two proposed WG chairs.
 Please send your recommendations unicast to Bill and me.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 3 May 2005 21:18:42 -0700

Folks-

 Before we bring it to the l1vpn mailing list, I'd like to run this draft
 by you guys for comments.

-- 
Alex

Layer 1 Virtual Private Networks (l1vpn)

Last Modified: 2005-01-25
Chair(s):
 TBD
 TBD

Routing Area Director(s):
 Bill Fenner <[email-masked]>
 Alex Zinin <[email-masked]>

Routing Area Advisor:
 Alex Zinin <[email-masked]>

Technical Advisor(s):

Mailing Lists:
 General Discussion: [email-masked]
 To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
 Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html

Description of Working Group:

 L1VPN Working Group's task is to specify mechanisms necessary for
 providing a VPN service over a GMPLS transport network.

 The following two service models will be addressed:

  1. Basic mode: the CE-PE interface's functional repertoire is limited to
     path setup signalling only. The GMPLS network is not involved in
     distribution of user's routing information.

  2. Enhanced mode: the CE-PE interface provides the signaling capabilities
     as in the Basic mode, plus permits utilization of the provider's control
     plane for distribution of user's routing information (e.g. similar to the
     MPLS/BGP model).

 The WG will work on the following items:

  1. Specification of the L1VPN user-to-network interface (UNI) basic mode,
     including both CE and PE functionality.

  2. Specification of the L1VPN node-to-node interface (NNI) basic mode.

  3. MIB modules and/or extensions required for UNI and NNI basic mode.

  4. Specification of L1VPN UNI enhanced mode.

  5. Specification of L1VPN NNI enhanced mode.

  6. MIB modules and/or extensions required for UNI and NNI enhanced mode.

 Protocol extensions required for L1VPN will be done in cooperation with
 CCAMP, OSPF, IS-IS, IDR, and other WGs where necessary.

Milestones:

  Sep 05 Submit first Internet Drafts of UNI and NNI basic mode
         specifications
  Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic
         mode
  Jun 06 Submit UNI and NNI basic mode specifications to IESG for
         publication as Proposed Standard
  Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode
         specifications
  Aug 06 Submit MIB modules for UNI and NNI basic mode to IESG for
         publication as Proposed Standard
  Dec 06 Submit UNI and NNI enhanced mode specifications to IESG for
         publication as Proposed Standard
  Aug 06 Submit MIB modules for UNI and NNI enhanced mode to IESG for
         publication as Proposed Standard

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 4 May 2005 07:33:48 -0700 (PDT)

>      distribution of user's routing information.

Well, reachability information needs to be exchanged (what CE's are in
my VPN, and how can I reach them (via which PE)?).

>      plane for distribution of user's routing information (e.g. similar to the

Here, there is additional routing info, typically about CE-PE links.

>  The WG will work on the following items:

We should add the l1vpn framework document.  I usually don't care much
for fw docs, but this one is useful, and sets out the reference
models.  If the charter uses the terms 'basic' and 'enhanced' modes,
these can be defined in detail in the fw doc.

>   2. Specification of the L1VPN node-to-node interface (NNI) basic mode.

NNI = network-to-network

>   Sep 05 Submit first Internet Drafts of UNI and NNI basic mode

as individual drafts?  as WG docs?

>   Dec 05 Submit first Internet Drafts of MIB modules for UNI and NNI basic

ditto

>          publication as Proposed Standard

Seems too much time here.  I would suggest mar 06.

>   Jun 06 Submit first Internet Drafts of UNI and NNI enhanced mode

Why serialize between basic and enhanced modes?  The initial enhanced
mode draft(s) could be submitted jan/feb 06.

>          publication as Proposed Standard

Kireeti.
-------

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 4 May 2005 09:21:12 -0700 (PDT)

>  Alex Zinin <[email-masked]>

One question: what is the rationale for having L1VPN in the Routing
Area, whereas L2VPN and L3VPN are in Internet?

Kireeti.
-------

---

From: Alex Zinin <[email-masked]>
Date: Wed, 4 May 2005 15:47:24 -0700

Kireeti,

> Area, whereas L2VPN and L3VPN are in Internet?

Looking back, I believe putting L2VPN and L3VPN in RTG was a big mistake.
A lot of complexity related to their work, as well as people involved are
in RTG. Same with L1VPN--it builds on the technology developed with RTG.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 4 May 2005 15:45:54 -0700

Kireeti,

> my VPN, and how can I reach them (via which PE)?).

I thought this was supposed to be manually configured in the
signalling-only scenario, no?

> Here, there is additional routing info, typically about CE-PE links.

My understanding of the routing info distribution was that it would provide
the VPN-prefix to remote CE mapping.

> these can be defined in detail in the fw doc.

I thought the basic and enhanced mode specs would essentially be the
profiles of different protocol features, pulling together different
functionality. With this model in mind, do we still need a fw doc?

> NNI = network-to-network

I remember ATM. I didn't like the original expansion though, since we're
talking about a single network, hence the change. Don't care much though.

> as individual drafts?  as WG docs?

It's a WG charter. Individuals don't count :)

> Seems too much time here.  I would suggest mar 06.

C'est bon

> mode draft(s) could be submitted jan/feb 06.

Walk first?

Alex

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 May 2005 20:04:39 +0100

> in RTG. Same with L1VPN--it builds on the technology developed with RTG.

I agree with Alex.
But will we have a war in the IESG over this? Is there anything we need to
do to prepare the ground?

A

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 12:43:38 -0700

Adrian,

If there is one--it's my job to fight it. No worries.

Alex