[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VLAN label range requirement



lyndon

- not sure to understand - the information part of the liaison question was "how large is large" ?

eg. RFC 3946 support VC4-256v did you ever ask the question whether we have an efficient encoding ?


Ong, Lyndon wrote:

Sure, I understand.  I think the concern that was expressed at the last
OIF
meeting was whether we might need to define an efficient way of
describing
a set consisting of a very large set of labels, since the range of VLAN
tags,
for example, is quite a bit larger than the typical set of labels
assumed for
optical switches. If OIF comes up with any proposals along those lines, it would then liaise this to CCAMP for
its
consideration.

Cheers,

Lyndon
-----Original Message-----
From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Sent: Wednesday, July 12, 2006 6:33 AM
To: Ong, Lyndon
Cc: Stephen Shew; Adrian Farrel; ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

lyndon -

listing a set of labels as part of the response is something already
covered in GMPLS

hence if i well understand the MEF.10 document the information elements
that needs to be considered is quite straightforward

so do we need this loop back and forth ? why not just produce a 2 page
doc and close this ?

thx,
- d.

Ong, Lyndon wrote:


That was my interpretation also, not sure if that came through on the slides.

Lyndon

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Stephen Shew
Sent: Tuesday, July 11, 2006 8:09 PM
To: Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: VLAN label range requirement

You're welcome.

The response from CCAMP on this question is very thorough, and I certainly appreciate the thought that went into it. My interpretation


of the response is that that CCAMP encourages the OIF to design an encoding for the VLAN identifiers, and communicate it back to CCAMP.

Stephen

-----Original Message-----
From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: July 11, 2006 18:42
To: Shew, Stephen (CAR:Q840); ccamp@ops.ietf.org
Subject: Re: VLAN label range requirement

Thanks Stephen.

What is your opinion of the response to this question that CCAMP supplied in its return communication to the OIF?

Adrian
----- Original Message -----
From: "Stephen Shew" <sdshew@nortel.com>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, July 11, 2006 4:44 PM
Subject: VLAN label range requirement


In yesterday's meeting, there was a request for more information on the VLAN label range requirement. From the original OIF liaison, the description was: "We are investigating label formats to represent a list or range of VLAN identifiers, as used in MEF.11 bundling. In the case where a large number of non-consecutive VLAN identifiers is used for the same connection, we would like to keep the label to a reasonable size."

The requirement to send a range of VLAN identifiers in signalling arises in the bundling feature in Ethernet services as specified in Metro Ethernet Forum (MEF) and ITU-T SG15 documents. In the MEF, the MEF.11 spec "User Network Interface (UNI) Requirements and Framework" there is a UNI service attribute called "bundling" that is described as "A UNI attribute in which more than one CE-VLAN ID is associated

with an EVC."

It is more fully described in MEF.10 "Ethernet Services Attributes Phase 1". Both technical specs may be obtained free at:
http://www.metroethernetforum.org/TechSpec.htm

Equivalent ITU-T Recs. are G.8011, G8011.1, and G.8011.2. These are available to ITU-T members, or under a "3 free" capability on the ITU-T website.

Of interest is the MEF Ethernet Link Management Interface (E-LMI) defined in MEF.16 that has an encoding for passing VLAN ranges between


the UNI client and network. This in a structure called the "CE-VLAN ID/EVC Map information element".

I hope this provides more clarity to the VLAN label range issue.

Stephen Shew
Metro Ethernet Networks
Nortel
sdshew@nortel.com
Telephone: +1 613 763 2462 / ESN 393 2462




.



.