Re: New communication from the OIF

["Adrian Farrel" <adrian@olddog.co.uk>]

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" <julien.meuric@orange-ftgroup.com>
To: <Dimitri.Papadimitriou@alcatel-lucent.be>; <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
Sent: Monday, March 05, 2007 5:44 PM
Subject: RE: New communication from the OIF


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: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel-lucent.be

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" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
28/02/2007 16:16
Please respond to "Adrian Farrel"

       To:     <ccamp@ops.ietf.org>
       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, adrian@olddog.co.uk and Deborah Brungard,
dbrungard@att.com,
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