Subject: RE: New communication from the OIF

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Mon, 5 Mar 2007 18:44:26 +0100

Hi Dimitri.

If you consider the access network, I agree with you: provisioning would
probably be on a per customer basis. However, when we focus on the
aggregation or the core networks, service establishment could be needed
for a collection of VIDs already in place: as far as I understand, this
is what the MEF defines as a single service carrying several VLANs, and
I believe the OIF would prefer to establish this as a single service
instead of signalling a list of 500 VIDs, especially if end-to-end
recovery is needed some time.

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

adrain, very interesting examples / applications of ethernet LSPs
but in the proposed cases i see more rationales to unbundle than
bundle the VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the
VLAN per customer the question is simple, are all customers specs
identical and provisioned at the same time ?

thanks,
- d.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
28/02/2007 16:16
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        cc: 
        Subject:        New communication from the OIF

Hi,

We have received the following communication from the OIF discussing
their 

desire to build compound VLAN-ID labels. It would be good to look at the

scenarios they describe to examine what our recommendations are.

All input gratefully received.

As always, all communications can be found through the CCAMP alternate
Web 

site at www.olddog.co.uk/ccamp.htm

Regards,
Adrian
====
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard, 
[email-masked],
IETF CCAMP WG co-chairs

From: Jim Jones, OIF Technical Committee Chair

Subject: Further Information Regarding VLAN ID Requirements

Dear Adrian and Deborah,

It is our understanding that CCAMP members requested more information to

understand the requirements we have identified for carrying or
indicating 
large numbers of VLAN IDs in the Label objects in control signaling 
messages 
for Ethernet connections with frame switching granularity. This issue is

more fully described in the attached excerpt from our liaison to CCAMP
on 
October 2006.

Accordingly, our carrier WG has developed a small set of illustrative 
scenarios as attached, for CCAMP's review and information.

We would be strongly interested in CCAMP's conclusions on how these 
scenarios can be supported using existing GMPLS methods or if any
further 
definition might be required.

Best regards,
Jim Jones
OIF Technical Committee Chair

Attachments:
1) Excerpt from OIF Liaison to IETF CCAMP of October 2006
2) oif2007.056 - Illustrative Scenarios of VLAN ID Use

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors
Lyndon Ong, OIF TC Vice Chair
Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 5 Mar 2007 23:46:21 -0000

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of multiple 
Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a construction, 
like the label stack in MPLS, is easily available in Ethernet. Is there a 
specific reason why the end-to-end labels must be visible in the data plane 
in the core of the network?

In this sense, the request for a concatenation of labels is simply so that 
multiple labels can be treated in the same way, not (unlike the TDM case) in 
order to construct some for of virtual concatenation. If it were the case 
that each Ethernet label had a limited amount of bandwidth associated and it 
was necessary to clump labels to make a bigger unit of bandwidth, the case 
would be different, but that does not apply to Ethernet AFAIK.

So, still struggling to understand the underlying requirement.

Perhaps it is "simply" the desire to exchange only one Path message between 
source and destination when multiple LSPs are formed between the same pair 
of end-points. One might argue the same case in L3VPN deployments.

Adrian

----- Original Message ----- 
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments:

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 7 Mar 2007 11:35:41 -0500

Hi Adrian,

I'm not the expert on this, but I think there may be two models at work
here:

- in one model, several originators request resource reservation for
their Ethernet flows 
based on the associated Ethernet labels, each with some associated
bandwidth.  The receiving 
node creates a corresponding tunnel and aggregates these flows into the
tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking
with our MEF 'experts' on this), the originator requests an EVC service,
which has an 
associated bandwidth from one edge of the network to another, and can
support within it
several Ethernet flows that share this bandwidth.  If there are multiple
EVCs, the 
originator uses signaling to identify which labels should be carried in
EVCx and which
should be carried in EVCy - if EVCx carries 200 Ethernet flows, then you
would need to
identify 200 labels as belonging to EVCx.  However there is one
transport requirement
for the EVC, not one for each flow.

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Monday, March 05, 2007 3:46 PM
To: MEURIC Julien RD-CORE-LAN; [email-masked]
Cc: [email-masked]
Subject: Re: New communication from the OIF

Julien, Dimitry,

I, too, read these examples as a desire to perform aggregation of
multiple Ethernet flows into a single managed flow.

My question is, what is wrong with a tunnel construct? Such a
construction, like the label stack in MPLS, is easily available in
Ethernet. Is there a specific reason why the end-to-end labels must be
visible in the data plane in the core of the network?

In this sense, the request for a concatenation of labels is simply so
that multiple labels can be treated in the same way, not (unlike the TDM
case) in order to construct some for of virtual concatenation. If it
were the case that each Ethernet label had a limited amount of bandwidth
associated and it was necessary to clump labels to make a bigger unit of
bandwidth, the case would be different, but that does not apply to
Ethernet AFAIK.

Perhaps it is "simply" the desire to exchange only one Path message
between source and destination when multiple LSPs are formed between the
same pair of end-points. One might argue the same case in L3VPN
deployments.

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments:

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 7 Mar 2007 18:28:50 -0500

Hi Deborah,

That's great that you talked to your MEF reps, I think it confirms my
previous email:

- there are, as you say, several models allowed in the MEF spec.  One
model does
allow bundling of many (possibly hundreds or thousands) of VIDs in one
EVC, which 
causes a problem if you are 
attempting to control the EVC with an RSVP session.  The original
liaison was not
intended, I think, to restrict the models supported, but to identify a
case 
where it was not clear how you would do the signaling, where the case
was of particular
interest to some of the carrier members of OIF.

- perhaps multiple messages could be a solution.  If so, it would be
helpful to 
understand how this would work - any solutions coming out of CCAMP would
be
very welcome.  

- not sure if there is an issue on point-to-multipoint, we were just
trying to 
address one issue at a time, I think.

Now that we hopefully have a better understanding of the underlying
motivations,
hopefully we can make some further progress on a solution :o)

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Lyndon,

I checked here among MEF reps and there are several models: bandwidth
profile per ingress UNI, bandwidth profile per ingress EVC for a UNI,
bandwidth profile per ingress EVC+CE-VLAN CoS tuple. Both untagged and
tagged frames can be supported per EVC. As different bandwidth profiles
could apply for each of the UNIs in an EVC, the bandwidth profile is not
specified on an EVC basis, but as a UNI service attribute. Multiple EVCs
can be supported at a UNI. And a mix of UNIs with different
(physical/service) characteristics for a EVC is allowed. [MEF10] A new
egress profile was added [MEF 10.1].

MEF's EVC, if point-to-point, associates two UNI, or it may be
multi-point (multiple UNIs). And depending if CE-VLAN preservation is
used, the CE-VLAN ID values may only be significant at a given UNI.

The OIF liaison noted OIF was only considering point-to-point, though I
am wondering why? MEF is considering both pt-to-pt and multi-point EVCs.

As I mentioned at the last IETF meeting, it is difficult to understand
the requirement to (one-time) signal a list of VIDs without
understanding the requirements behind it. I can understand that an EVC
may support (possibly;-)) 500 VIDS when bundling. I am not sure this
infers one signaling message per EVC. Service multiplexing, multi-point,
all will have different needs. We may want to consider other
alternatives (l1vpn, call,..) to be able to support the wider MEF
service scope than optimizing for one specific service attribute.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ong, Lyndon
Sent: Wednesday, March 07, 2007 11:36 AM
To: Adrian Farrel; MEURIC Julien RD-CORE-LAN;
[email-masked]
Cc: [email-masked]
Subject: RE: New communication from the OIF

Hi Adrian,

- in one model, several originators request resource reservation for
their Ethernet flows based on the associated Ethernet labels, each with
some associated bandwidth.  The receiving node creates a corresponding
tunnel and aggregates these flows into the tunnel.

- in the second model (which I believe to be the MEF EVC model, although
we're checking with our MEF 'experts' on this), the originator requests
an EVC service, which has an associated bandwidth from one edge of the
network to another, and can support within it several Ethernet flows
that share this bandwidth.  If there are multiple EVCs, the originator
uses signaling to identify which labels should be carried in EVCx and
which should be carried in EVCy - if EVCx carries 200 Ethernet flows,
then you would need to identify 200 labels as belonging to EVCx.
However there is one transport requirement for the EVC, not one for each
flow.

Cheers,

Lyndon

-----Original Message-----

Julien, Dimitry,

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

adrain, very interesting examples / applications of ethernet LSPs but in
the proposed cases i see more rationales to unbundle than bundle the
VLAN ID in the same Path message

for the VLAN per service i guess we're on the safe path, for the VLAN
per customer the question is simple, are all customers specs identical
and provisioned at the same time ?

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

To: Adrian Farrel, [email-masked] and Deborah Brungard,
[email-masked], IETF CCAMP WG co-chairs

Dear Adrian and Deborah,

understand the requirements we have identified for carrying or
indicating large numbers of VLAN IDs in the Label objects in control
signaling messages for Ethernet connections with frame switching
granularity. This issue is

on October 2006.

We would be strongly interested in CCAMP's conclusions on how these
scenarios can be supported using existing GMPLS methods or if any
further definition might be required.

Best regards,
Jim Jones

Attachments:

cc: Bill Fenner and Ross Callon, IETF Routing Area Directors Lyndon Ong,
OIF TC Vice Chair Evelyne Roch, OIF Interoperability Working Group Chair
Jonathan Sadler, OIF Architecture & Signaling Working Group Chair

---

From: [email-masked]
Date: Thu, 8 Mar 2007 01:26:33 +0100

lyndon

o) first you will observe that the doc. MEF traffic parameters does not 
speak about "label distribution" 

reason: you will observe (by section 3.4 of RFC 3209) that label per 
sender (shared reservation or not) and label per link reservation 
(de-facto shared) are possible

hence the usage of RSVP-TE traffic parameters result also in using these 
rules (i will add a statement to make this clearer in the next release) 
but remember the doc does not define any "label" format for MEF purposes

o) second you will observe that the document does not infer any "VID" to 
EVC relationship, noticing that single CoS and multiple CoS per EVC are 
covered in the draft, and this, independently of the number of VIDs per 
EVC 

o) third closing the loop, the draft is not inferring any "label" to "VID" 
relationship (that relationship when equating an EVC with single or 
multiple CoS to an RSVP session is straightforward) 

the questions are thus the following

1. to which entity the traffic parameters are applied in case of a single 
EVC with multiple VIDs ? if you are following the reasoning since so far 
it should be per EVC (for the set of VIDs) 

note: per EVC+VID taken individually requires separate signaling otherwise 
you need a list of tspecs and a list of label + correspondance and this is 
another protocol, in fact boiling down to a simple relationship 

2. what is the "label" value(s) in this case ? using the set of VIDs to 
represent a "reservation" at the control plane level is completely useless 
as the control plane doesn't need this info to create PSB/RSB and the 
entity to which the reservation is associated is the "EVC" ... so you will 
need to find a unique per-EVC characteristic when the 1:1 relationship 
between label and EVC is limitative e.g. a bundle index or so (something 
that boils you down to a 1:1 relationship because indepedently of the 
"protocol" being explicit in the enumeration IS cumbersome)

 thanks,
-d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
08/03/2007 00:28
 
        To:     "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, 
"Adrian Farrel" <[email-masked]>, "MEURIC Julien RD-CORE-LAN" 
<[email-masked]>, Dimitri 
PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Deborah,

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;

Hi Lyndon,

Deborah

-----Original Message-----

Hi Adrian,

Cheers,

Lyndon

-----Original Message-----

Julien, Dimitry,

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments:

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 7 Mar 2007 16:28:11 -0600

Hi Lyndon,

Deborah

-----Original Message-----

Hi Adrian,

Cheers,

Lyndon

-----Original Message-----

Julien, Dimitry,

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments:

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 9 Mar 2007 13:29:03 -0500

Hi Dimitri,

I understand what you are saying, however it is still not clear what
the solution should be:

a) it is not clear as you say what "label" value you would use for the
EVC

b) there still needs to be some method of enumerating the VIDs carried
by 
the EVC (for this type of EVC).  If the signaling does not enumerate the
VIDs, 
then some other mechanism is necessary, to create what I think you refer
to as 
a "bundle index".

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 4:27 PM
To: Ong, Lyndon
Cc: Adrian Farrel; [email-masked]; BRUNGARD, DEBORAH A, ATTLABS;
MEURIC Julien RD-CORE-LAN; [email-masked]
Subject: RE: New communication from the OIF

lyndon

o) third closing the loop, the draft is not inferring any "label" to
"VID" 
relationship (that relationship when equating an EVC with single or
multiple CoS to an RSVP session is straightforward) 

1. to which entity the traffic parameters are applied in case of a
single EVC with multiple VIDs ? if you are following the reasoning since
so far it should be per EVC (for the set of VIDs) 

note: per EVC+VID taken individually requires separate signaling
otherwise you need a list of tspecs and a list of label + correspondance
and this is another protocol, in fact boiling down to a simple
relationship 

2. what is the "label" value(s) in this case ? using the set of VIDs to
represent a "reservation" at the control plane level is completely
useless as the control plane doesn't need this info to create PSB/RSB
and the entity to which the reservation is associated is the "EVC" ...
so you will need to find a unique per-EVC characteristic when the 1:1
relationship between label and EVC is limitative e.g. a bundle index or
so (something that boils you down to a 1:1 relationship because
indepedently of the "protocol" being explicit in the enumeration IS
cumbersome)

 thanks,
-d.

Hi Deborah,

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;

Hi Lyndon,

Deborah

-----Original Message-----

Hi Adrian,

Cheers,

Lyndon

-----Original Message-----

Julien, Dimitry,

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments:

---

From: [email-masked]
Date: Fri, 9 Mar 2007 21:46:24 +0100

lyndon

a C-Type 3 label can help here with a VLAN bundle ID 

note that in this case, you will have the possibility to optionally list 
(set of) intervals

hope this will help you,
-d. 

09/03/2007 19:29
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     "Adrian Farrel" <[email-masked]>, 
<[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, 
"MEURIC Julien RD-CORE-LAN" <[email-masked]>, 
<[email-masked]>
        Subject:        RE: New communication from the OIF

Hi Dimitri,

Cheers,

Lyndon 

-----Original Message-----

lyndon

 thanks,
-d.

Hi Deborah,

Cheers,

Lyndon

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2007 2:28 PM
To: Ong, Lyndon; Adrian Farrel; MEURIC Julien RD-CORE-LAN;

Hi Lyndon,

Deborah

-----Original Message-----

Hi Adrian,

Cheers,

Lyndon

-----Original Message-----

Julien, Dimitry,

Adrian

----- Original Message -----
From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF

Hi Dimitri.

Regards,

Julien

-----Original Message-----

thanks,
- d.

        To:     <[email-masked]>
        cc:

Hi,

Regards,
Adrian
====
February 27, 2007

Dear Adrian and Deborah,

Best regards,
Jim Jones

Attachments: