Subject: RE: [IP-Optical] RE: Arbitrary concatenation proposals
From: Vishal Sharma <[email-masked]>
To: "'Scott Bradner'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Date: Thu, 31 May 2001 15:15:37 -0700

Scott,

Thanks very much for your clarification. It clears up a doubt I had.

While on the subject, there was a question I had posed to the ADs,
Advisors, and Chairs, regarding the recent call for soliciting "service
provider input" in various Working Groups, requesting to understant exactly 
what that
meant. My query was echoed at least by two others, Neil
Harrisson and Jerry Ash, both of whom work for service providers.

If there was a response to my question, I must have missed it.
I am including an excerpt from my email below for your reference.

Thanks,

-Vishal

On Thursday, May 31, 2001 10:54 AM, Scott Bradner [SMTP:[email-masked]] wrote:
>
>
> > This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
>
> I did not see a message from Lucent I saw a message from an individual
>
>  reminder - in teh IETF we operate as individuals - one should not
> extend the words of an individual to mean that an organization has
> expressed an opinion
>
> Scott

On Monday, May 28, 2001 12:59 PM, Vishal Sharma [SMTP:[email-masked]] 
wrote:
> Dimitri, Bala,
>
> I agree with your philosopy. Especally the part that points out that there 
are
>
<<snip>>

> As for Jerry's point, I think all he is saying is that over the last couple 
of
>
> IETFs,
> there have been formal calls by the ADs, Acting ADs, and different WG
> advisors
> to formally obtain SP input on several items (such as restoration, TE best
> practices,
> etc.), but this does not seem to have been the case for GMPLS signaling 
specs.
>
> (Of course, as Eric rightly pointed out, this does not prevent any SP or
> their
> representatives from providing such input.)
>
> Finally, and others can correct me if I am wrong, isn't there  a little bit
> of
> contradiction in the IETF stance with respect to SP input, given that
> (technically) we
> all come to the IETF, not as representatives of our companies, but rather
> as individual contributors.
>
> If so, I am a little confused about what it means
> to ask for SP input? Are we asking for individual contributors from the
> SP community, and hoping that they will bring in (by osmosis) the overall
> philosophy
> of their company, or are we asking for companies to specifically send
> their representatives to provide inputs on certain topics that have been
> deemed to require SP input?
>
> ADs, Chairs, any comments or clarifications?
>
> Thanks,
>
> -Vishal

Delivery-date: Thu, 31 May 2001 12:18:01 -0700
Date: Thu, 31 May 2001 15:13:12 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: GMPLS RSVP-TE question

Hello All,

Where is the wavelength/port label defined for GMPLS RSVP-TE? Should it has a
new C-TYPE?

Thanks,

Yanggunag

Envelope-to: [email-masked]
Delivery-date: Thu, 31 May 2001 10:56:52 -0700
Date: Thu, 31 May 2001 13:54:09 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: [IP-Optical] RE: Arbitrary concatenation proposals

> This is really odd.  Perhaps Eve would enlighten us on Lucent's change of

I did not see a message from Lucent I saw a message from an individual

 reminder - in teh IETF we operate as individuals - one should not
extend the words of an individual to mean that an organization has
expressed an opinion

Scott

Delivery-date: Thu, 31 May 2001 08:40:46 -0700
From: Martin Dubuc <[email-masked]>
To: 'Arumugam R' <[email-masked]>
Cc: "Thomas D. Nadeau" <[email-masked]>, [email-masked], [email-masked], [email-masked], "[email-masked]" <[email-masked]>, [email-masked]
Subject: RE: Some clarifications in the LMP mib..
Date:  Thu, 31 May 2001 11:33:42 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0E9E7.1310F22E
Content-Type: text/plain;
	charset="iso-8859-1"

Arumagam,

I have submitted a new version of the LMP MIB May 22. However, it still has
not shown up on IETF Web site. I have attached it with this message. The
filename might change as a result of classifying the ID.

The new version of the MIB addresses your first two comments. As far as
lmpDataLinkRemoteIfId is conerned, it is now read-write, but should be
read-create. This will be fixed in next release.

As far as manual configuration procedure of TE link is concerned, once the
TE link and data-bearing links are configured manually, their information is
sent in LinkSummary messages as part of the property correlation procedure.
The TE link and data-bearing link information configured manually in both
local and remote nodes can be correlated. If there is a mismatch, a property
mismatch trap can be generated. As you have mentioned, a node that does not
implement the link verification procedure does not need to track states
related to link verification.

Regards,

Martin

-----Original Message-----
From: Arumugam R [mailto:[email-masked]]
Sent: Thursday, May 31, 2001 2:41 AM
To: [email-masked]; Thomas D. Nadeau; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Some clarifications in the LMP mib..

Hi,

While going through the LMP mib, some typo errors are found and i need 
some more clarification.

1. The lmpTeLinkAdminStatus in the lmpTeLinkTable is marked read-only, 
instead of read-create.

2. In the lmpTeLinkCCMappingTable, the lmpTeLinkCcMappingEntry is bound 
to have 4 entries as given in the example.

It should look like the following.

LmpTeLinkCcMappingEntry ::= SEQUENCE {
   lmpTeLinkId                                      TeLinkId,
   lmpCcId                                            LmpCcId,
   lmpTeLinkCcMappingRowStatus       RowStatus,
   lmpTeLinkCcMappingStorageType    StorageType
}
and appropriately the values and description needs to be changed.

3. In the lmpDateBearingLinkTable, the lmpDataLinkRemoteIfId is given as 
a read-only object.
The typo is in the example given, it is configured which gives a feeling 
that it is read-create. It needs to be removed from the example.

Can you through some explanation regarding the manual configuration 
procedure, since it can reduce some states and events in the TE Link 
FSM, as well as avoiding the test procedure & Data Link FSM, since it is 
not clearly explained in the LMP Draft. 

4. The lmpDataBearingLinkCcPreemptibility is mentioned as read-only 
instead of read-create. Also the description for the same is wrong & i 
feel it is a cut and paste from the description of lmpDataBearingType.

Suggestions are welcome

Thanks and regards
Arumugam R.

------_=_NextPart_000_01C0E9E7.1310F22E
Content-Type: text/plain;
	name="draft-ietf-ccamp-lmp-mib-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-ccamp-lmp-mib-00.txt"

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Network Working Group                                       Martin =
Dubuc=0A=
Internet Draft                                            edgeflow, =
Inc.=0A=
Expires: November 2001=0A=
                                                     Sudheer =
Dharanikota=0A=
                                                    Nayna Networks, =
Inc.=0A=
=0A=
                                                        Thomas D. =
Nadeau=0A=
                                                     Cisco Systems, =
Inc.=0A=
=0A=
                                                        Jonathan P. =
Lang=0A=
                                                           Evan =
McGinnis=0A=
                                                  Calient Networks, =
Inc.=0A=
=0A=
=0A=
    Link Management Protocol Management Information Base Using SMIv2=0A=
=0A=
=0A=
                    draft-ietf-ccamp-lmp-mib-00.txt=0A=
=0A=
=0A=
Status of this Memo=0A=
=0A=
   This document is an Internet-Draft and is in full conformance =
with=0A=
   all provisions of Section 10 of RFC 2026.=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups. Note that =
other=0A=
   groups may also distribute working documents as Internet- Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six =
months=0A=
   and may be updated, replaced, or obsoleted by other documents at =
any=0A=
   time. It is inappropriate to use Internet- Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
Table of Contents=0A=
=0A=
1.   Abstract .....................................................    =
2=0A=
2.   Introduction .................................................    =
2=0A=
3.   Terminology ..................................................    =
3=0A=
4.   The SNMP Management Framework ................................    =
3=0A=
4.1. Object Definitions ...........................................    =
4=0A=
5.   Feature Checklist ............................................    =
4=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
1]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
6.   Outline ......................................................    =
5=0A=
6.1. Summary of LMP MIB ...........................................    =
6=0A=
7.   Brief Description of MIB Objects .............................    =
6=0A=
7.1. lmpNbrTable ..................................................    =
6=0A=
7.2. lmpControlChannelTable .......................................    =
6=0A=
7.3. lmpControlChannelPerfTable ...................................    =
7=0A=
7.4. lmpTeLinkTable ...............................................    =
7=0A=
7.5. lmpLinkVerificationTable .....................................    =
7=0A=
7.6. lmpDataBearingLinkTable ......................................    =
7=0A=
7.7. lmpDataBearingLinkPerfTable ..................................    =
7=0A=
8.   Example of LMP Control Channel Interface Setup ...............    =
7=0A=
9.   Link Management Protocol MIB Definitions .....................   =
10=0A=
10.  Security Considerations ......................................   =
46=0A=
11.  Acknowledgments ..............................................   =
47=0A=
12.  References ...................................................   =
47=0A=
13.  Authors' Addresses ...........................................   =
50=0A=
14.  Full Copyright Statement .....................................   =
51=0A=
=0A=
=0A=
=0A=
1.  Abstract=0A=
=0A=
   This memo defines an experimental portion of the Management =
Informa-=0A=
   tion Base (MIB) for use with network management protocols in the=0A=
   Internet community. In particular, it describes managed objects =
for=0A=
   modeling the Link Management Protocol (LMP) [LMP].=0A=
=0A=
=0A=
2.  Introduction=0A=
=0A=
   This memo defines an experimental portion of the Management =
Informa-=0A=
   tion Base (MIB) for use with network management protocols in the=0A=
   Internet community. In particular, it describes managed objects =
for=0A=
   modeling the Link Management Protocol (LMP) [LMP].=0A=
=0A=
   Comments should be made directly to the ccamp mailing list at=0A=
   [email-masked].=0A=
=0A=
   This memo does not, in its draft form, specify a standard for the=0A=
   Internet community.=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =
this=0A=
   document are to be interpreted as described in RFC 2119, =
reference=0A=
   [BCP14].=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
2]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
3.  Terminology=0A=
=0A=
   This document uses terminology from the document describing the =
Link=0A=
   Management Protocol [LMP]. An "LMP adjacency" is formed between =
two=0A=
   nodes that support the same capabilities, and LMP messages are=0A=
   exchanged between the node pair over control channels that form =
this=0A=
   adjacency. Several control channels can be active at the same =
time.=0A=
   With the exception of messages related to control channel =
management,=0A=
   any time a LMP message needs to be transferred to a neighbor node, =
it=0A=
   can be sent on any of the active control channels. The control =
chan-=0A=
   nels can also be used to exchange MPLS control plane information =
or=0A=
   routing information.=0A=
=0A=
   LMP is designed to support aggregation of one or more =
data-bearing=0A=
   links into a traffic-engineering (TE) link. The data-bearing =
links=0A=
   can be either component links or ports depending on their =
multiplex-=0A=
   ing capability (see [LMP] for distinction between port and =
component=0A=
   link). Furthermore, the data-bearing links may be defined as =
primary=0A=
   or secondary data-bearing links, where a secondary data-bearing =
link=0A=
   is used to protect a primary data-bearing link, i.e. if a primary=0A=
   data-bearing link fails, data traffic is switched over to one of =
the=0A=
   secondary data-bearing links.=0A=
=0A=
   Each TE link is associated with an LMP adjacency, and one or more=0A=
   control channels are used to exchange LMP messages. In turn, =
control=0A=
   channels are used to manage one or more TE links.=0A=
=0A=
=0A=
=0A=
4.  The SNMP Management Framework=0A=
=0A=
   The SNMP Management Framework presently consists of five major =
com-=0A=
   ponents:=0A=
=0A=
   -  An overall architecture, described in RFC 2571 [SNMPArch].=0A=
=0A=
   -  Mechanisms for describing and naming objects and events for =
the=0A=
      purpose of management. The first version of this Structure of=0A=
      Management Information (SMI) is called SMIv1 and described in=0A=
      RFC 1155 [SMIv1], RFC 1212 [SNMPv1MIBDef] and RFC 1215=0A=
      [SNMPv1Traps]. The second version, called SMIv2, is described=0A=
      in RFC 2578 [SMIv2], RFC 2579 [SNMPv2TC] and RFC 2580=0A=
      [SNMPv2Conf].=0A=
=0A=
   -  Message protocols for transferring management information. The=0A=
      first version of the SNMP message protocol is called SNMPv1=0A=
      and described in RFC 1157 [SNMPv1]. A second version of the=0A=
      SNMP message protocol, which is not an Internet standards=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
3]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
      track protocol, is called SNMPv2c and described in RFC 1901=0A=
      [SNMPv2c] and RFC 1906 [SNMPv2TM]. The third version of the=0A=
      message protocol is called SNMPv3 and described in RFC 1906=0A=
      [SNMPv2TM], RFC 2272 [SNMPv3MP] and RFC 2574 [SNMPv3USM].=0A=
=0A=
   -  Protocol operations for accessing management information. The=0A=
      first set of protocol operations and associated PDU formats is=0A=
      described in RFC 1157 [SNMPv1]. A second set of protocol=0A=
      operations and associated PDU formats is described in RFC 1905=0A=
      [SNMPv2PO].=0A=
=0A=
   -  A set of fundamental applications described in RFC 2273=0A=
      [SNMPv3App] and the view-based access control mechanism=0A=
      described in RFC 2575 [SNMPv3VACM].=0A=
=0A=
   Managed objects are accessed via a virtual information store, =
termed=0A=
   the Management Information Base or MIB. Objects in the MIB are=0A=
   defined using the mechanisms defined in the SMI. This memo =
specifies=0A=
   a MIB module that is compliant to the SMIv2. A MIB conforming to =
the=0A=
   SMIv1 can be produced through the appropriate translations. The=0A=
   resulting translated MIB must be semantically equivalent, except=0A=
   where objects or events are omitted because no translation is =
possi-=0A=
   ble (use of Counter64). Some machine-readable information in =
SMIv2=0A=
   will be converted into textual descriptions in SMIv1 during the=0A=
   translation process. However, this loss of machine-readable =
informa-=0A=
   tion is not considered to change the semantics of the MIB.=0A=
=0A=
=0A=
=0A=
4.1.  Object Definitions=0A=
=0A=
   Managed objects are accessed via a virtual information store, =
termed=0A=
   the Management Information Base or MIB. Objects in the MIB are=0A=
   defined using the subset of Abstract Syntax Notation One (ASN.1)=0A=
   defined in the SMI. In particular, each object type is named by =
an=0A=
   OBJECT IDENTIFIER, an administratively assigned name.  The object=0A=
   type together with an object instance serves to uniquely identify =
a=0A=
   specific instantiation of the object. For human convenience, we =
often=0A=
   use a textual string, termed the descriptor, to also refer to the=0A=
   object type.=0A=
=0A=
=0A=
=0A=
5.  Feature Checklist=0A=
=0A=
   The Link Management protocol MIB (LMP-MIB) is designed to satisfy =
the=0A=
   following requirements and constraints:=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
4]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   -  The MIB supports the enabling and disabling of LMP capability=0A=
      on LMP capable interfaces of a photonic switch, optical=0A=
      cross-connect or router.=0A=
=0A=
   -  Support is provided for configuration of the keep alive and=0A=
      link verification parameters.=0A=
=0A=
   -  The MIB allows the mapping between TE links and control=0A=
      channels to be established either through manual=0A=
      configuration or via the link verification procedure.=0A=
=0A=
   -  The MIB is used to express the mapping between local and =
remote=0A=
      TE links, as well as local and remote interface identifiers =
for=0A=
      port or component link.=0A=
=0A=
   -  Performance counters are provided for measuring LMP=0A=
      performance on a per-interface basis. Performance counters are=0A=
      also provided for measuring LMP performance on the =
data-bearing=0A=
      links.=0A=
=0A=
   Note that the LMP MIB goes hand-in-hand with the Link Bundling =
MIB=0A=
   [BUNDLE-MIB]. The TE link table, which is used to associate data-=0A=
   bearing links to TE links, is defined in the Link Bundling MIB. =
The=0A=
   TE link table in the LMP MIB contains TE link information specific =
to=0A=
   LMP.=0A=
=0A=
=0A=
=0A=
6.  Outline=0A=
=0A=
   Configuring LMP through an optical device involves the following=0A=
   steps:=0A=
=0A=
   -  Enabling LMP on LMP capable interfaces through of control =
channel=0A=
      configuration.=0A=
=0A=
   -  Optionally specifying link verification parameters.=0A=
=0A=
   -  Configuring the data-bearing links and associating them to the=0A=
      appropriate TE link (this association is stored in the=0A=
      Link Bundling MIB).=0A=
=0A=
   -  Identifying which control channels manage the TE link.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
5]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
6.1.  Summary of LMP MIB=0A=
=0A=
   The MIB objects for performing these actions consist of the =
following=0A=
   tables:=0A=
=0A=
   -  The remote node table is used to identify the pair=0A=
      of nodes that exchange LMP messages over control channels.=0A=
=0A=
   -  The control channel table (lmpControlChannelTable) is used=0A=
      for enabling the LMP protocol on LMP-capable interfaces.=0A=
=0A=
   -  The control channel performance table=0A=
      (lmpControlChannelPerfTable) is used for collecting=0A=
      LMP performance counts on a per-interface basis.=0A=
=0A=
   -  The TE link table (lmpTeLinkTable) is used for=0A=
      specifying TE links.=0A=
=0A=
   -  The link verification table (lmpLinkVerificationTable) is used =
for=0A=
      configuring the LMP link verification parameters of TE links.=0A=
=0A=
=0A=
   -  The data-bearing link table (lmpDataBearingLinkTable) is used =
to=0A=
      specify the data-bearing links that are associated with TE =
links.=0A=
=0A=
   -  The data-bearing link performance table=0A=
      (lmpDataBearingLinkPerfTable) is used for collecting LMP=0A=
      performance counts on data-bearing links.=0A=
=0A=
   These tables are described in the subsequent sections.=0A=
=0A=
=0A=
=0A=
7.  Brief Description of MIB Objects=0A=
=0A=
   Sections 7.1-7.3 describe objects pertaining to LMP-capable =
inter-=0A=
   faces. Section 7.4 to 7.7 describes objects for specifying TE =
links=0A=
   and data-bearing links. The MIB objects were derived from the LMP=0A=
   document [LMP].=0A=
=0A=
=0A=
7.1.  lmpNbrTable=0A=
=0A=
   This table identifies the pairs of nodes on which LMP is enabled.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
6]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
7.2.  lmpControlChannelTable=0A=
=0A=
   This table represents the interfaces that are LMP capable (i.e. =
capa-=0A=
   ble of transmitting LMP messages). A photonic switch, optical =
cross-=0A=
   connect, or router creates an entry in this table for every LMP =
capa-=0A=
   ble interface on that device.=0A=
=0A=
=0A=
=0A=
7.3.  lmpControlChannelPerfTable=0A=
=0A=
   This table contains the objects to measure the LMP performance of =
LMP=0A=
   capable interfaces and is an AUGMENT to the =
lmpControlChannelTable.=0A=
   High capacity counters are provided for objects that are likely =
to=0A=
   wrap around quickly.=0A=
=0A=
=0A=
=0A=
7.4.  lmpTeLinkTable=0A=
=0A=
   This table represents the TE link information specific to LMP.=0A=
=0A=
=0A=
=0A=
7.5.  lmpLinkVerificationTable=0A=
=0A=
   This table represents the link verification parameters associated=0A=
   with the TE links.=0A=
=0A=
=0A=
=0A=
7.6.  lmpDataBearingLinkTable=0A=
=0A=
   The data-bearing link table enumerates the data-bearing links =
that=0A=
   are associated with each TE link.=0A=
=0A=
=0A=
=0A=
7.7.  lmpDataBearingLinkPerfTable=0A=
=0A=
   This table contains the objects to measure the LMP performance of=0A=
   data-bearing links and is an AUGMENT to the =
lmpDataBearingLinkTable.=0A=
=0A=
=0A=
=0A=
8.  Example of LMP Control Channel Setup=0A=
=0A=
   In this section we provide a brief example of using the MIB=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
7]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   objects described in section 11 to set up an LMP control channel.=0A=
   While this example is not meant to illustrate every nuance of the=0A=
   MIB, it is intended as an aid to understanding some of the key=0A=
   concepts. It is meant to be read after going through the MIB =
itself.=0A=
=0A=
   Suppose that one would like to form an LMP adjacency between two=0A=
   nodes using two control channels. Suppose also that there are=0A=
   three data-bearing links. We also assume that the data-bearing=0A=
   links are ports (lambdas). We also assume that the link=0A=
   verification procedure is not enabled. The following example=0A=
   illustrates which rows and corresponding objects might be created=0A=
   to accomplish this.=0A=
=0A=
   First, LMP must be enabled between the pair of nodes.=0A=
=0A=
   In lmpNbrTable:=0A=
   {=0A=
      lmpNbrNodeId                       =3D 'c0010101'H, -- =
192.1.1.1=0A=
      lmpNbrLinkSumRetransmitInterval    =3D 10,=0A=
      lmpNbrAdminStatus                  =3D up(1),=0A=
      lmpNbrRowStatus                    =3D createAndGo(4)=0A=
   }=0A=
=0A=
   Then, the control channels must be set up. These are created in=0A=
   the lmpControlChannelTable.=0A=
=0A=
   In lmpControlChannelTable:=0A=
   {=0A=
      ifIndex                           =3D 1,=0A=
      lmpCcAuthentication               =3D false(1),=0A=
      lmpCcConfigRetransmitInterval     =3D 10,=0A=
      lmpCcHelloInterval                =3D 5,=0A=
      lmpCcHelloDeadInterval            =3D 15,=0A=
      lmpCcAdminStatus                  =3D up(1),=0A=
      lmpCcRowStatus                    =3D createAndGo(4)=0A=
   }=0A=
=0A=
   {=0A=
      ifIndex                           =3D 2,=0A=
      lmpCcAuthentication               =3D false(1),=0A=
      lmpCcConfigRetransmitInterval     =3D 10,=0A=
      lmpCcHelloInterval                =3D 5,=0A=
      lmpCcHelloDeadInterval            =3D 15,=0A=
      lmpCcAdminStatus                  =3D up(1),=0A=
      lmpCcRowStatus                    =3D createAndGo(4)=0A=
   }=0A=
=0A=
   Next, the three data-bearing links are created. For each data-=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
8]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   bearing link, an ifEntry with the same ifIndex needs to be =
created=0A=
   beforehand.=0A=
=0A=
   In lmpDataBearingLinkTable:=0A=
   {=0A=
      ifIndex                         =3D 41,=0A=
      lmpDataBearingLinkRemoteIfId    =3D 47,=0A=
      lmpDataBearingLinkRowStatus     =3D createAndGo(4)=0A=
   }=0A=
=0A=
   {=0A=
      ifIndex                         =3D 43,=0A=
      lmpDataBearingLinkRemoteIfId    =3D 42,=0A=
      lmpDataBearingLinkRowStatus     =3D createAndGo(4)=0A=
   }=0A=
=0A=
   {=0A=
      ifIndex                         =3D 44,=0A=
      lmpDataBearingLinkRemoteIfId    =3D 48,=0A=
      lmpDataBearingLinkRowStatus     =3D createAndGo(4)=0A=
   }=0A=
=0A=
   Note that the data-bearing link type (lmpDataBearingLinkType) =
does=0A=
   not need to be provisioned as it is automatically populated by =
the=0A=
   node. The definition of the protection role (primary or=0A=
   secondary) for the data-bearing links is stored in the=0A=
   dataBearingChannelTable of the Link Bundling MIB [BUNDLE-MIB].=0A=
=0A=
   Then, a TE link is created as an ifEntry with ifType teLink in=0A=
   the ifTable.=0A=
=0A=
   Once the TE link is created in the ifTable, a TE link entry=0A=
   is created in the LMP MIB to specify TE link information specific=0A=
   to LMP.=0A=
=0A=
   In lmpTeLinkTable:=0A=
   {=0A=
      ifIndex                    =3D 20,=0A=
      lmpRemoteTeLinkId          =3D 33,=0A=
      lmpRemoteTeLinkType        =3D unnumbered(2),=0A=
      lmpTeLinkVerification      =3D true(2),=0A=
      lmpTeLinkFaultIsolation    =3D true(2),=0A=
      lmpTeLinkDwdm              =3D false(1),=0A=
      lmpTeLinkEncodingType      =3D sonet(6),=0A=
      lmpTeLinkBitRate           =3D 100000,=0A=
      lmpTeLinkWavelength        =3D 0,=0A=
      lmpTeLinkAdminStatus       =3D up(1),=0A=
      lmpTeLinkRowStatus         =3D createAndGo(4)=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                  [Page =
9]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   }=0A=
=0A=
   The association between the data-bearing links and the TE links =
is=0A=
   stored in the ifStackTable [IF-MIB].=0A=
=0A=
   In parallel with the entry created in the lmpTeLinkTable, an =
entry=0A=
   may be created in the teLinkTable of Link Bundling MIB=0A=
   [BUNDLE-MIB].=0A=
=0A=
=0A=
=0A=
9.  LMP MIB Definitions=0A=
=0A=
LMP-MIB DEFINITIONS ::=3D BEGIN=0A=
=0A=
IMPORTS=0A=
   MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,=0A=
   experimental, Integer32, Unsigned32, Counter32, Counter64,=0A=
   IpAddress=0A=
      FROM SNMPv2-SMI=0A=
=0A=
   MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP=0A=
      FROM SNMPv2-CONF=0A=
=0A=
   TEXTUAL-CONVENTION, TruthValue, RowStatus, StorageType,=0A=
   RowPointer, TimeStamp=0A=
      FROM SNMPv2-TC=0A=
=0A=
   InterfaceIndex, InterfaceIndexOrZero, ifIndex=0A=
      FROM IF-MIB;=0A=
=0A=
lmpMIB MODULE-IDENTITY=0A=
   LAST-UPDATED "200105221200Z"  -- 22 May 2001 12:00:00 EST=0A=
   ORGANIZATION "Common Control and Measurement Protocols (CCAMP)=0A=
                 Working Group"=0A=
   CONTACT-INFO=0A=
       "        Martin Dubuc=0A=
        Postal: edgeflow, Inc.=0A=
                329 March Rd.=0A=
                Kanata, ON, CANADA K2K 2E1=0A=
        Tel:    +1-613-270-9279 x253=0A=
        Email:  [email-masked]=0A=
=0A=
                Sudheer Dharanikota=0A=
        Postal: Nayna Networks, Inc.=0A=
                157 Topaz Street=0A=
                Milipitas, CA 95035=0A=
        Tel:    +1-408-956-8000 x357=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
10]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        Email:  [email-masked]=0A=
=0A=
                Thomas D. Nadeau=0A=
        Postal: Cisco Systems, Inc.=0A=
                300 Apollo Drive=0A=
                Chelmsford, MA 01824=0A=
        Tel:    +1-978-244-3051=0A=
        Email:  [email-masked]=0A=
=0A=
                Jonathan P. Lang=0A=
        Postal: Calient Networks, Inc.=0A=
                25 Castilian Drive=0A=
                Goleta, CA 93117=0A=
        Email:  [email-masked]=0A=
=0A=
                Evan McGinnis=0A=
        Postal: Calient Networks, Inc.=0A=
                5853 Rue Ferrari=0A=
                San Jose, CA 95138=0A=
        Email:  [email-masked]"=0A=
=0A=
=0A=
   DESCRIPTION=0A=
       "This MIB contains managed object definitions for the=0A=
        Link Management Protocol (LMP) as=0A=
        defined in: Lang, J., Mitra, K., Drake, J., Kompella, K.,=0A=
        Rekhter, Y., Berger, L., Saha, D.,=0A=
        Basak, D., Sandick, H., Zinin, A., and=0A=
        Rajagopalan, B., Link Management Protocol,=0A=
        Internet Draft <draft-ietf-mpls-lmp-02.txt>,=0A=
        March 2001."=0A=
=0A=
   -- Revision history.=0A=
   REVISION=0A=
       "200105221200Z"  -- 22 May 2001 12:00:00 EST=0A=
   DESCRIPTION=0A=
      "Updates based on IETF-50 feedback. Aligned with=0A=
       upcoming version of LMP draft."=0A=
   REVISION=0A=
       "200102221200Z"  -- 22 February 2001 12:00:00 EST=0A=
   DESCRIPTION=0A=
      "Updates based on MPLS mailing list feedback."=0A=
   REVISION=0A=
       "200101261200Z"  -- 26 January 2001 12:00:00 EST=0A=
   DESCRIPTION=0A=
      "Initial draft version."=0A=
   ::=3D { experimental 113 }=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
11]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
-- Textual Conventions=0A=
=0A=
NodeID ::=3D TEXTUAL-CONVENTION=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This value represents a Node ID."=0A=
   SYNTAX        IpAddress=0A=
=0A=
LmpInterval ::=3D TEXTUAL-CONVENTION=0A=
   DISPLAY-HINT "d"=0A=
   STATUS      current=0A=
   DESCRIPTION=0A=
       "The interval delay in milliseconds."=0A=
   SYNTAX      Unsigned32 (1..65535)=0A=
=0A=
LmpRetransmitInterval ::=3D TEXTUAL-CONVENTION=0A=
   DISPLAY-HINT "d"=0A=
   STATUS      current=0A=
   DESCRIPTION=0A=
       "The retransmission interval delay in milliseconds."=0A=
   SYNTAX      Unsigned32 (1..4294967295)=0A=
=0A=
=0A=
-- Top level components of this MIB=0A=
=0A=
-- Traps=0A=
lmpNotifications OBJECT IDENTIFIER ::=3D { lmpMIB 0 }=0A=
-- Tables, Scalars=0A=
lmpObjects       OBJECT IDENTIFIER ::=3D { lmpMIB 1 }=0A=
-- Conformance=0A=
lmpConformance   OBJECT IDENTIFIER ::=3D { lmpMIB 2 }=0A=
=0A=
=0A=
lmpAdminStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER { up(1), down(2) }=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The desired operational status of LMP on the node."=0A=
   DEFVAL        { up }=0A=
   ::=3D { lmpObjects 1 }=0A=
=0A=
=0A=
-- LMP Neighbor Table=0A=
=0A=
lmpNbrTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpNbrEntry=0A=
   MAX-ACCESS    not-accessible=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
12]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies the neighbor node to which control =
channels=0A=
        may be established."=0A=
   ::=3D { lmpObjects 2 }=0A=
=0A=
lmpNbrEntry OBJECT-TYPE=0A=
   SYNTAX        LmpNbrEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table is created by a LMP-enabled device =
for=0A=
        every pair of nodes that can establish control channels."=0A=
   INDEX         { lmpNbrNodeId }=0A=
   ::=3D { lmpNbrTable 1 }=0A=
=0A=
LmpNbrEntry ::=3D SEQUENCE {=0A=
  lmpNbrNodeId                    NodeID,=0A=
  lmpNbrLinkSumRetransmitInterval LmpRetransmitInterval,=0A=
  lmpNbrLinkSumRetransmitTimeout  Unsigned32,=0A=
  lmpNbrAdminStatus               Unsigned32,=0A=
  lmpNbrOperStatus                Unsigned32,=0A=
  lmpNbrRowStatus                 RowStatus,=0A=
  lmpNbrStorageType               StorageType=0A=
}=0A=
=0A=
lmpNbrNodeId OBJECT-TYPE=0A=
   SYNTAX        NodeID=0A=
   MAX-ACCESS    accessible-for-notify=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This is a unique index for an entry in the=0A=
        LmpNbrTable. This value represents the=0A=
        remote Node ID."=0A=
   ::=3D { lmpNbrEntry 1 }=0A=
=0A=
lmpNbrLinkSumRetransmitInterval OBJECT-TYPE=0A=
   SYNTAX        LmpRetransmitInterval=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the interval that is used for the=0A=
        retransmission of LinkSummary messages during the property=0A=
        correlation phase."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
13]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpNbrEntry 2 }=0A=
=0A=
lmpNbrLinkSumRetransmitTimeout OBJECT-TYPE=0A=
   SYNTAX        Unsigned32=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the LinkSummary retransmission timeout=0A=
        period. If the specified timeout expires and no=0A=
        LinkSummaryAck or LinkSummaryNack message has been received,=0A=
        a node can stop restransmitting LinkSummary messages for the=0A=
        TE link. A value of 0 is used to indicate that a node should=0A=
        never stop retransmission."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   DEFVAL        { 0 }=0A=
   ::=3D { lmpNbrEntry 3 }=0A=
=0A=
lmpNbrAdminStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER { up(1), down(2) }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The desired operational status of LMP to this remote node."=0A=
   ::=3D { lmpNbrEntry 4 }=0A=
=0A=
lmpNbrOperStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER { up(1), down(2) }=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The actual operational status of LMP to this remote node."=0A=
   ::=3D { lmpNbrEntry 5 }=0A=
=0A=
lmpNbrRowStatus OBJECT-TYPE=0A=
   SYNTAX        RowStatus=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable is used to create, modify, and/or=0A=
        delete a row in this table."=0A=
   ::=3D { lmpNbrEntry 6 }=0A=
=0A=
lmpNbrStorageType OBJECT-TYPE=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
14]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   SYNTAX        StorageType=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The storage type for this entry."=0A=
   ::=3D { lmpNbrEntry 7 }=0A=
=0A=
-- End of lmpNbrTable=0A=
=0A=
=0A=
lmpCcHelloIntervalDefault OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the default value for the =
HelloInterval=0A=
        parameter used in the Hello protocol keep-alive phase. It=0A=
        indicates how frequently LMP Hello messages will be sent."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpObjects 3 }=0A=
=0A=
lmpCcHelloIntervalDefaultMin OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the default minimum value for the=0A=
        HelloInterval parameter."=0A=
   ::=3D { lmpObjects 4 }=0A=
=0A=
lmpCcHelloIntervalDefaultMax OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the default maximum value for the=0A=
        HelloInterval parameter."=0A=
   ::=3D { lmpObjects 5 }=0A=
=0A=
lmpCcHelloDeadIntervalDefault OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
15]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
       "This object specifies the default HelloDeadInterval parameter =
to=0A=
        use in the Hello protocol keep-alive phase. It indicates how =
long=0A=
        a device should wait before declaring the control channel =
dead.=0A=
        The HelloDeadInterval parameter must be greater than the=0A=
        HelloInterval parameter and should be at least three times =
the=0A=
        value of HelloInterval."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpObjects 6 }=0A=
=0A=
lmpCcHelloDeadIntervalDefaultMin OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the default minimum value for the=0A=
        HelloDeadInterval parameter."=0A=
   ::=3D { lmpObjects 7 }=0A=
=0A=
lmpCcHelloDeadIntervalDefaultMax OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the default maximum value for the=0A=
        HelloDeadInterval parameter."=0A=
   ::=3D { lmpObjects 8 }=0A=
=0A=
=0A=
-- LMP Control Channel Table=0A=
=0A=
lmpControlChannelTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpControlChannelEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies LMP control channel information."=0A=
   ::=3D { lmpObjects 9 }=0A=
=0A=
lmpControlChannelEntry OBJECT-TYPE=0A=
   SYNTAX        LmpControlChannelEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table is created by a LMP-enabled device =
for=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
16]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        every control channel. An ifEntry with must exist in the =
ifTable=0A=
        before the lmpControlChannelEntry with corresponding ifIndex=0A=
        is created. If the entry in the ifTable is destroyed, then =
so=0A=
        is the corresponding entry in the lmpControlChannelTable."=0A=
   INDEX         { ifIndex }=0A=
   ::=3D { lmpControlChannelTable 1 }=0A=
=0A=
LmpControlChannelEntry ::=3D SEQUENCE {=0A=
  lmpCcNbrNodeId                 NodeID,=0A=
  lmpRemoteCcId                  InterfaceIndexOrZero,=0A=
  lmpCcAuthentication            TruthValue,=0A=
  lmpCcConfigRetransmitInterval  LmpRetransmitInterval,=0A=
  lmpCcConfigRetransmitTimeout   Unsigned32,=0A=
  lmpCcHelloInterval             LmpInterval,=0A=
  lmpCcHelloIntervalMin          LmpInterval,=0A=
  lmpCcHelloIntervalMax          LmpInterval,=0A=
  lmpCcHelloDeadInterval         LmpInterval,=0A=
  lmpCcHelloDeadIntervalMin      LmpInterval,=0A=
  lmpCcHelloDeadIntervalMax      LmpInterval,=0A=
  lmpCcAdminStatus               Unsigned32,=0A=
  lmpCcOperStatus                Unsigned32,=0A=
  lmpCcRowStatus                 RowStatus,=0A=
  lmpCcStorageType               StorageType=0A=
}=0A=
=0A=
lmpCcNbrNodeId OBJECT-TYPE=0A=
   SYNTAX        NodeID=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This is the Node ID of the control channel remote node.=0A=
        This value gets created by the node when the Config=0A=
        message is acknowledged by the remote node."=0A=
   ::=3D { lmpControlChannelEntry 1 }=0A=
=0A=
lmpRemoteCcId OBJECT-TYPE=0A=
   SYNTAX        InterfaceIndexOrZero=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This value represents the interface index for the remote =
control=0A=
        channel. It is determined during the negotiation phase. A =
value=0A=
        of zero means that the remote control channel identifier has =
not=0A=
        yet been assigned."=0A=
   ::=3D { lmpControlChannelEntry 2 }=0A=
=0A=
lmpCcAuthentication OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
17]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object indicates whether the control channel should use=0A=
        authentication."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpControlChannelEntry 3 }=0A=
=0A=
lmpCcConfigRetransmitInterval OBJECT-TYPE=0A=
   SYNTAX        LmpRetransmitInterval=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the interval that is used for the=0A=
        retransmission of Config messages during the parameter=0A=
        negotiation phase."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpControlChannelEntry 4 }=0A=
=0A=
lmpCcConfigRetransmitTimeout OBJECT-TYPE=0A=
   SYNTAX        Unsigned32=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the Config restransmission timeout=0A=
        period. If the specified timeout expires and no Config,=0A=
        ConfigAck or ConfigNack message has been received, a node=0A=
        can stop restransmitting Config messages on the control=0A=
        channel. A value of 0 is used to indicate that a node should=0A=
        never stop retransmission."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   DEFVAL        { 0 }=0A=
   ::=3D { lmpControlChannelEntry 5 }=0A=
=0A=
lmpCcHelloInterval OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
18]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the value of the HelloInterval=0A=
        parameter. Once the control channel is active, it represents=0A=
        the negotiated value of the HelloInterval."=0A=
   ::=3D { lmpControlChannelEntry 6 }=0A=
=0A=
lmpCcHelloIntervalMin OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the minimum value for the=0A=
        HelloInterval parameter."=0A=
   ::=3D { lmpControlChannelEntry 7 }=0A=
=0A=
lmpCcHelloIntervalMax OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the maximum value for the=0A=
        HelloInterval parameter."=0A=
   ::=3D { lmpControlChannelEntry 8 }=0A=
=0A=
lmpCcHelloDeadInterval OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the value of the HelloDeadInterval=0A=
        parameter. Once the control channel is active, it represents=0A=
        the negotiated value of the HelloDeadInterval."=0A=
   ::=3D { lmpControlChannelEntry 9 }=0A=
=0A=
lmpCcHelloDeadIntervalMin OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the minimum value for the=0A=
        HelloDeadInterval parameter."=0A=
   ::=3D { lmpControlChannelEntry 10 }=0A=
=0A=
lmpCcHelloDeadIntervalMax OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-write=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
19]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the maximum value for the=0A=
        HelloDeadInterval parameter."=0A=
   ::=3D { lmpControlChannelEntry 11 }=0A=
=0A=
lmpCcAdminStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER { up(1), down(2) }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The desired operational status of this control channel."=0A=
   ::=3D { lmpControlChannelEntry 12 }=0A=
=0A=
lmpCcOperStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER {=0A=
                     up(1),=0A=
                     down(2),=0A=
                     configSnd(3),=0A=
                     configRcv(4),=0A=
                     active(5),=0A=
                     goingDown(6)=0A=
                 }=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The actual operational status of this control channel=0A=
        interface."=0A=
   ::=3D { lmpControlChannelEntry 13 }=0A=
=0A=
lmpCcRowStatus OBJECT-TYPE=0A=
   SYNTAX        RowStatus=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable is used to create, modify, and/or=0A=
        delete a row in this table."=0A=
   ::=3D { lmpControlChannelEntry 14 }=0A=
=0A=
lmpCcStorageType OBJECT-TYPE=0A=
   SYNTAX        StorageType=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The storage type for this entry."=0A=
   ::=3D { lmpControlChannelEntry 15 }=0A=
=0A=
-- End of lmpControlChannelTable=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
20]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
-- LMP Control Channel Performance Table=0A=
=0A=
lmpControlChannelPerfTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpInterfacePerfEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies LMP control channel performance =
counters."=0A=
   ::=3D { lmpObjects 10 }=0A=
=0A=
lmpControlChannelPerfEntry OBJECT-TYPE=0A=
   SYNTAX        LmpInterfacePerfEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table is created by a LMP-enabled device =
for=0A=
        every control channel."=0A=
   AUGMENTS      { lmpControlChannelEntry }=0A=
   ::=3D { lmpControlChannelPerfTable 1 }=0A=
=0A=
LmpInterfacePerfEntry ::=3D SEQUENCE {=0A=
  lmpCcHCInOctets            Counter64,=0A=
  lmpCcInDiscards            Counter32,=0A=
  lmpCcInErrors              Counter32,=0A=
  lmpCcHCOutOctets           Counter64,=0A=
  lmpCcOutDiscards           Counter32,=0A=
  lmpCcOutErrors             Counter32,=0A=
  lmpCcHCHelloReceived       Counter64,=0A=
  lmpCcHCHelloSent           Counter64,=0A=
  lmpCcConfigReceived        Counter32,=0A=
  lmpCcConfigSent            Counter32,=0A=
  lmpCcConfigRetransmit      Counter32,=0A=
  lmpCcLinkSummaryReceived   Counter32,=0A=
  lmpCcLinkSummarySent       Counter32,=0A=
  lmpCcLinkSummaryRetransmit Counter32,=0A=
  lmpCcChannelFailReceived   Counter32,=0A=
  lmpCcChannelFailSent       Counter32,=0A=
  lmpCcChannelActiveReceived Counter32,=0A=
  lmpCcChannelActiveSent     Counter32=0A=
}=0A=
=0A=
lmpCcHCInOctets OBJECT-TYPE=0A=
    SYNTAX      Counter64=0A=
    MAX-ACCESS  read-only=0A=
    STATUS      current=0A=
    DESCRIPTION=0A=
            "The total number of LMP message octets received on the=0A=
             control channel."=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
21]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
    ::=3D { lmpControlChannelPerfEntry 1 }=0A=
=0A=
lmpCcInDiscards OBJECT-TYPE=0A=
    SYNTAX      Counter32=0A=
    MAX-ACCESS  read-only=0A=
    STATUS      current=0A=
    DESCRIPTION=0A=
            "The number of inbound packets which were chosen to be=0A=
             discarded even though no errors had been detected. One=0A=
             possible reason for discarding such a packet could be =
to=0A=
             free up buffer space."=0A=
    ::=3D { lmpControlChannelPerfEntry 2 }=0A=
=0A=
lmpCcInErrors OBJECT-TYPE=0A=
    SYNTAX      Counter32=0A=
    MAX-ACCESS   read-only=0A=
    STATUS       current=0A=
    DESCRIPTION=0A=
            "The number of inbound packets that contained errors=0A=
             preventing them from being processed by LMP."=0A=
    ::=3D { lmpControlChannelPerfEntry 3 }=0A=
=0A=
lmpCcHCOutOctets OBJECT-TYPE=0A=
    SYNTAX       Counter64=0A=
    MAX-ACCESS   read-only=0A=
    STATUS       current=0A=
    DESCRIPTION=0A=
            "The total number of LMP message octets transmitted out =
of=0A=
             the control channel."=0A=
    ::=3D { lmpControlChannelPerfEntry 4 }=0A=
=0A=
lmpCcOutDiscards OBJECT-TYPE=0A=
    SYNTAX       Counter32=0A=
    MAX-ACCESS   read-only=0A=
    STATUS       current=0A=
    DESCRIPTION=0A=
            "The number of outbound packets which were chosen to be=0A=
             discarded even though no errors had been detected to =
prevent=0A=
             their being transmitted. One possible reason for =
discarding=0A=
             such a packet could be to free up buffer space."=0A=
    ::=3D { lmpControlChannelPerfEntry 5 }=0A=
=0A=
lmpCcOutErrors OBJECT-TYPE=0A=
    SYNTAX       Counter32=0A=
    MAX-ACCESS   read-only=0A=
    STATUS       current=0A=
    DESCRIPTION=0A=
            "The number of outbound packets that could not be=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
22]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
             transmitted because of errors."=0A=
    ::=3D { lmpControlChannelPerfEntry 6 }=0A=
=0A=
lmpCcHCHelloReceived OBJECT-TYPE=0A=
   SYNTAX        Counter64=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Hello messages that have=0A=
        been received on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 7 }=0A=
=0A=
lmpCcHCHelloSent OBJECT-TYPE=0A=
   SYNTAX        Counter64=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Hello messages that have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 8 }=0A=
=0A=
lmpCcConfigReceived OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Config messages that have=0A=
        been received on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 9 }=0A=
=0A=
lmpCcConfigSent OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Config messages that have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 10 }=0A=
=0A=
lmpCcConfigRetransmit OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Config messages that=0A=
        have been retransmitted over this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 11 }=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
23]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
lmpCcLinkSummaryReceived OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of LinkSummary messages that =
have=0A=
        been received on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 12 }=0A=
=0A=
lmpCcLinkSummarySent OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of LinkSummary messages that =
have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 13 }=0A=
=0A=
lmpCcLinkSummaryRetransmit OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of LinkSummary messages that=0A=
        have been retransmitted over this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 14 }=0A=
=0A=
lmpCcChannelFailReceived OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of ChannelFail messages that =
have=0A=
        been received on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 15 }=0A=
=0A=
lmpCcChannelFailSent OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of ChannelFail messages that =
have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 16 }=0A=
=0A=
lmpCcChannelActiveReceived OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
24]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of ChannelActive messages that =
have=0A=
        been received on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 17 }=0A=
=0A=
lmpCcChannelActiveSent OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of ChannelActive messages that =
have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpControlChannelPerfEntry 18 }=0A=
=0A=
-- End of lmpControlChannelPerfTable=0A=
=0A=
=0A=
-- LMP TE Link Table=0A=
=0A=
lmpTeLinkTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpTeLinkEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table contains a collection of TE link."=0A=
   ::=3D { lmpObjects 11 }=0A=
=0A=
lmpTeLinkEntry OBJECT-TYPE=0A=
   SYNTAX        LmpTeLinkEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table exists for each ifEntry with an=0A=
        ifType of teLink(TBD), i.e. for every TE link. An ifEntry=0A=
        with an ifIndex must exist before the corresponding=0A=
        teLinkEntry is created. If a TE link entry in the ifTable is=0A=
        destroyed, then so is the corresponding entry in the=0A=
        teLinkTable. The administrative status value is controlled=0A=
        from the ifEntry. Setting the administrative status to=0A=
        testing prompts LMP to start link verification on the TE =
link.=0A=
        Information about the TE link that is not LMP specific is =
also=0A=
        contained in teLinkTable [BUNDLE-MIB]."=0A=
   INDEX         { ifIndex }=0A=
   ::=3D { lmpTeLinkTable 1 }=0A=
=0A=
LmpTeLinkEntry ::=3D SEQUENCE {=0A=
  lmpTeLinkNbrNodeId      NodeID,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
25]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
  lmpRemoteTeLinkId       InterfaceIndexOrZero,=0A=
  lmpRemoteTeLinkType     Unsigned32,=0A=
  lmpTeLinkVerification   TruthValue,=0A=
  lmpTeLinkFaultIsolation TruthValue,=0A=
  lmpTeLinkDwdm           TruthValue,=0A=
  lmpTeLinkEncodingType   Unsigned32,=0A=
  lmpTeLinkBitRate        Unsigned32,=0A=
  lmpTeLinkWavelength     Unsigned32,=0A=
  lmpTeLinkOperStatus     Unsigned32,=0A=
  lmpTeLinkRowStatus      RowStatus,=0A=
  lmpTeLinkStorageType    StorageType=0A=
}=0A=
=0A=
lmpTeLinkNbrNodeId OBJECT-TYPE=0A=
   SYNTAX        NodeID=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This is the Node ID of the TE link remote node."=0A=
   ::=3D { lmpTeLinkEntry 1 }=0A=
=0A=
lmpRemoteTeLinkId OBJECT-TYPE=0A=
   SYNTAX        InterfaceIndexOrZero=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This identifies the TE link identifier on the remote side=0A=
        of the TE link. This is either configured manually or is=0A=
        communicated by the remote node during the link verification=0A=
        procedure. It is expected that for unnumbered TE links, this=0A=
        value will be set to 0."=0A=
   ::=3D { lmpTeLinkEntry 2 }=0A=
=0A=
lmpRemoteTeLinkType OBJECT-TYPE=0A=
   SYNTAX        INTEGER {=0A=
                     numbered(0),=0A=
                     unnumbered(1)=0A=
                 }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The remote TE link type (numbered or unnumbered)."=0A=
   ::=3D { lmpTeLinkEntry 3 }=0A=
=0A=
lmpTeLinkVerification OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
26]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   DESCRIPTION=0A=
       "This object indicates if the extended LMP link verification=0A=
        procedure is enabled for this TE link."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpTeLinkEntry 4 }=0A=
=0A=
lmpTeLinkFaultIsolation OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object indicates if the extended LMP fault isolation=0A=
        procedure is enabled on this TE link."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpTeLinkEntry 5 }=0A=
=0A=
lmpTeLinkDwdm OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object indicates if the extended LMP DWDM procedure=0A=
        is enabled on this TE link."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpTeLinkEntry 6 }=0A=
=0A=
lmpTeLinkEncodingType OBJECT-TYPE=0A=
   SYNTAX        INTEGER {=0A=
                     packet(1),=0A=
                     ethernet(2),=0A=
                     ansiPdh(3),=0A=
                     etsiPdh(4),=0A=
                     sdh(5),=0A=
                     sonet(6),=0A=
                     digitalWrapper(7),=0A=
                     lambda(8),=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
27]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
                     fiber(9)=0A=
                 }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The encoding type of the data-bearing links contained in the=0A=
        TE link."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-generalized-signaling-00.txt - Generalized=0A=
        MPLS Signaling Functional Description, P. Ashwood-Smith,=0A=
        A. Banarjee, L. Berger, G. Bernstein, J. Drake, Y. Fan,=0A=
        E. Mannie, J. Lang, B. Rajagopalan, Y. Rekhter, D. Saha,=0A=
        V. Sharma, G. Swallow, Z. Tang, October 2000."=0A=
   ::=3D { lmpTeLinkEntry 7 }=0A=
=0A=
lmpTeLinkBitRate OBJECT-TYPE=0A=
   SYNTAX        Unsigned32=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This is the bit rate at which the Test messages will be=0A=
        transmitted and is expressed in bytes per second."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpTeLinkEntry 8 }=0A=
=0A=
lmpTeLinkWavelength OBJECT-TYPE=0A=
   SYNTAX        Unsigned32=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This value corresponds to the wavelength at=0A=
        which the Test messages will be transmitted over and is=0A=
        measured in nanometers (nm). If each data-bearing link=0A=
        corresponds to a separate wavelength, than this value should =
be=0A=
        set to 0."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpTeLinkEntry 9 }=0A=
=0A=
lmpTeLinkOperStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER { up(1), down(2), testing(3), degraded(4) }=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
28]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The actual operational status of this TE link. The status=0A=
        is set to testing when the TE link is performing link=0A=
        verification. A degraded status indicates that the TE link=0A=
        cannot provide the provisioned protection level, but yet,=0A=
        there is no disruption of service. For instance, if the=0A=
        protection type is 1+1 and one link is down, the TE link=0A=
        still carries the requested amount of data traffic, but=0A=
        this traffic is not protected anymore."=0A=
   ::=3D { lmpTeLinkEntry 10 }=0A=
=0A=
lmpTeLinkRowStatus OBJECT-TYPE=0A=
   SYNTAX        RowStatus=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable is used to create, modify, and/or=0A=
        delete a row in this table."=0A=
   ::=3D { lmpTeLinkEntry 11 }=0A=
=0A=
lmpTeLinkStorageType OBJECT-TYPE=0A=
   SYNTAX        StorageType=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable indicates the storage type for this=0A=
        object."=0A=
   ::=3D { lmpTeLinkEntry 12 }=0A=
=0A=
-- End of lmpTeLinkTable=0A=
=0A=
=0A=
lmpLinkVerificationInterval OBJECT-TYPE=0A=
   SYNTAX        Unsigned32=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object indicates how often the link verification =
procedure=0A=
        is executed. The interval is in milliseconds."=0A=
   ::=3D { lmpObjects 12 }=0A=
=0A=
=0A=
-- LMP Link Verification Table=0A=
=0A=
lmpLinkVerificationTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpLinkVerificationEntry=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
29]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies TE link information=0A=
        associated with the LMP verification procedure."=0A=
   ::=3D { lmpObjects 13 }=0A=
=0A=
lmpLinkVerificationEntry OBJECT-TYPE=0A=
   SYNTAX        LmpLinkVerificationEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table is created by a LMP-enabled device =
for=0A=
        every TE link that supports the LMP verification=0A=
        procedure."=0A=
   AUGMENTS      { lmpTeLinkEntry }=0A=
   ::=3D { lmpLinkVerificationTable 1 }=0A=
=0A=
LmpLinkVerificationEntry ::=3D SEQUENCE {=0A=
  lmpVerifyInterval           LmpInterval,=0A=
  lmpVerifyDeadInterval       LmpInterval,=0A=
  lmpVerifyTransportMechanism BITS,=0A=
  lmpVerifyAllLinks           Unsigned32=0A=
}=0A=
=0A=
lmpVerifyInterval OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the VerifyInterval parameter used=0A=
        in the LMP link verification process. It indicates the =
interval=0A=
        at which the Test messages are sent."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpLinkVerificationEntry 1 }=0A=
=0A=
lmpVerifyDeadInterval OBJECT-TYPE=0A=
   SYNTAX        LmpInterval=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object specifies the VerifyDeadInterval parameter used=0A=
        in the verification of the physical connectivity of =
data-bearing=0A=
        links. It specifies the observation period used to detect a =
Test=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
30]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        message at the remote node."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpLinkVerificationEntry 2 }=0A=
=0A=
lmpVerifyTransportMechanism OBJECT-TYPE=0A=
   SYNTAX        BITS {=0A=
                     -- SONET/SDH encoding type:=0A=
                     j0OverheadBytes(0),=0A=
                     dccSectionOverheadBytes(1),=0A=
                     dccLineOverheadBytes(2),=0A=
                     pos(3)=0A=
                     -- GigE encoding type: TBD=0A=
                     -- 10GigE encoding type: TBD=0A=
                 }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This defines the transport mechanism for the Test messages. =
The=0A=
        scope of this bit mask is restricted to each link encoding=0A=
        type. The local node will set the bits corresponding to the=0A=
        various mechanisms it can support for transmitting LMP Test=0A=
        messages. The receiver chooses the appropriate mechanism in =
the=0A=
        BeginVerifyAck message."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpLinkVerificationEntry 3 }=0A=
=0A=
lmpVerifyAllLinks OBJECT-TYPE=0A=
   SYNTAX        INTEGER { verifyAllLinks(1), verifyNewLinks(2) }=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object indicates whether the verification process =
checks=0A=
        all entities or only the new entities that have been added =
to=0A=
        this TE link."=0A=
   ::=3D { lmpLinkVerificationEntry 4 }=0A=
=0A=
-- End of lmpLinkVerificationTable=0A=
=0A=
=0A=
-- LMP Data Bearing Link Table=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
31]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
lmpDataBearingLinkTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpDataBearingLinkEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies the data-bearing links managed by the=0A=
        LMP."=0A=
   ::=3D { lmpObjects 14 }=0A=
=0A=
lmpDataBearingLinkEntry OBJECT-TYPE=0A=
   SYNTAX        LmpDataBearingLinkEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table exists for each ifEntry that =
represents=0A=
        a data-bearing link. An ifEntry with an ifIndex must exist=0A=
        before the corresponding lmpDataBearingLinkEntry is created.=0A=
        If an entry representing the data-bearing link is destroyed =
in=0A=
        the ifTable, then so is the corresponding entry in the=0A=
        lmpDataBearingLinkTable. The administrative status value is=0A=
        controlled from the ifEntry. The index to this table also=0A=
        used to get information in the dataBearingChannelTable=0A=
        [BUNDLE-MIB]."=0A=
   INDEX         { ifIndex }=0A=
   ::=3D { lmpDataBearingLinkTable 1 }=0A=
=0A=
LmpDataBearingLinkEntry ::=3D SEQUENCE {=0A=
  lmpDataBearingLinkType             Unsigned32,=0A=
  lmpDataBearingLinkRemoteIfId       InterfaceIndexOrZero,=0A=
  lmpDataBearingLinkOperStatus       Unsigned32,=0A=
  lmpDataBearingLinkRowStatus        RowStatus,=0A=
  lmpDataBearingLinkStorageType      StorageType=0A=
}=0A=
=0A=
lmpDataBearingLinkType OBJECT-TYPE=0A=
   SYNTAX        INTEGER {=0A=
                     port(1),=0A=
                     componentLink(2)=0A=
                 }=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This attribute specifies whether this data-bearing link is=0A=
        a port or a component link. Component link are multiplex=0A=
        capable whereas, ports are not multiplex capable."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
32]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpDataBearingLinkEntry 1 }=0A=
=0A=
lmpDataBearingLinkRemoteIfId OBJECT-TYPE=0A=
   SYNTAX        InterfaceIndexOrZero=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "Interface identifier of the remote end point. This=0A=
        information is either configured manually or is=0A=
        communicated by the remote node during the link verification=0A=
        procedure."=0A=
   ::=3D { lmpDataBearingLinkEntry 2 }=0A=
=0A=
lmpDataBearingLinkOperStatus OBJECT-TYPE=0A=
   SYNTAX        INTEGER {=0A=
                     upAlloc(1),=0A=
                     upFree(2),=0A=
                     down(3),=0A=
                     testing(4),=0A=
                     ccBoot(5),=0A=
                     beginVerify(6),=0A=
                     psvTst(7),=0A=
                     degraded(8) }=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "The actual operational status of this data-bearing link.=0A=
        A data-bearing link is in the degraded state if the=0A=
        control channel and associated backup control channel(s) are=0A=
        down but the data-bearing link is still operational."=0A=
   REFERENCE=0A=
       "draft-ietf-mpls-lmp-02.txt - Link Management Protocol (LMP),=0A=
        J. Lang, K. Mitra, J. Drake, K. Kompella, Y. Rekhter,=0A=
        L. Berger, D. Saha, D. Basak, H. Sandick, A. Zinin,=0A=
        B. Rajagopalan, March 2001."=0A=
   ::=3D { lmpDataBearingLinkEntry 3 }=0A=
=0A=
lmpDataBearingLinkRowStatus OBJECT-TYPE=0A=
   SYNTAX        RowStatus=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable is used to create, modify, and/or=0A=
        delete a row in this table."=0A=
   ::=3D { lmpDataBearingLinkEntry 4 }=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
33]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
lmpDataBearingLinkStorageType OBJECT-TYPE=0A=
   SYNTAX        StorageType=0A=
   MAX-ACCESS    read-create=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This variable indicates the storage type for this=0A=
        object."=0A=
   ::=3D { lmpDataBearingLinkEntry 5 }=0A=
=0A=
-- End of lmpDataBearingLinkTable=0A=
=0A=
=0A=
-- LMP Data Bearing Link Performance Table=0A=
=0A=
lmpDataBearingLinkPerfTable OBJECT-TYPE=0A=
   SYNTAX        SEQUENCE OF LmpDataBearingLinkPerfEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This table specifies the data-bearing links LMP performance=0A=
        counters."=0A=
   ::=3D { lmpObjects 15 }=0A=
=0A=
lmpDataBearingLinkPerfEntry OBJECT-TYPE=0A=
   SYNTAX        LmpDataBearingLinkPerfEntry=0A=
   MAX-ACCESS    not-accessible=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "An entry in this table contains information about=0A=
        the LMP performance counters for the data-bearing links."=0A=
   AUGMENTS      { lmpDataBearingLinkEntry }=0A=
   ::=3D { lmpDataBearingLinkPerfTable 1 }=0A=
=0A=
LmpDataBearingLinkPerfEntry ::=3D SEQUENCE {=0A=
  lmpDataBearingLinkTestReceived Counter32,=0A=
  lmpDataBearingLinkTestSent     Counter32=0A=
}=0A=
=0A=
lmpDataBearingLinkTestReceived OBJECT-TYPE=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Test messages that have=0A=
        been received on this interface."=0A=
   ::=3D { lmpDataBearingLinkPerfEntry 1 }=0A=
=0A=
lmpDataBearingLinkTestSent OBJECT-TYPE=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
34]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   SYNTAX        Counter32=0A=
   MAX-ACCESS    read-only=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This object counts the number of Test messages that have=0A=
        been sent on this interface."=0A=
   ::=3D { lmpDataBearingLinkPerfEntry 2 }=0A=
=0A=
-- End of lmpDataBearingLinkTable=0A=
=0A=
=0A=
-- Notification Configuration=0A=
=0A=
lmpLinkPropertyMismatchTrapEnable OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "If this object is true, then it enables the=0A=
        generation of lmpTeLinkPropertyMismatch=0A=
        and lmpDataBearingLinkPropertyMismatch traps,=0A=
        otherwise these traps are not emitted."=0A=
   DEFVAL        { false }=0A=
   ::=3D { lmpObjects 16 }=0A=
=0A=
lmpUnprotectedTrapEnable OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "If this object is true, then it enables the=0A=
        generation of lmpUnprotected trap,=0A=
        otherwise these traps are not emitted."=0A=
   DEFVAL        { false }=0A=
   ::=3D { lmpObjects 17 }=0A=
=0A=
lmpCcUpDownTrapEnable OBJECT-TYPE=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "If this object is true, then it enables the generation of=0A=
        lmpControlChannelUp and lmpControlChannelDown traps,=0A=
        otherwise these traps are not emitted."=0A=
   DEFVAL        { false }=0A=
   ::=3D { lmpObjects 18 }=0A=
=0A=
lmpTeLinkTrapEnable OBJECT-TYPE=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
35]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   SYNTAX        TruthValue=0A=
   MAX-ACCESS    read-write=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "If this object is true, then it enables the=0A=
        generation of lmpTeLinkDegraded trap,=0A=
        otherwise these traps are not emitted."=0A=
   DEFVAL        { false }=0A=
   ::=3D { lmpObjects 19 }=0A=
=0A=
=0A=
-- Notifications=0A=
=0A=
-- Link Property Mismatch Traps=0A=
=0A=
lmpTeLinkPropertyMismatch NOTIFICATION-TYPE=0A=
   OBJECTS       { ifIndex,=0A=
                   lmpRemoteTeLinkId }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when a TE link property=0A=
        mismatch is detected on the node. ifIndex is the interface=0A=
        index of the misconfigured TE link. The remote TE link id=0A=
        is the remote TE link id received in the LinkSummary =
message."=0A=
   ::=3D { lmpNotifications 1 }=0A=
=0A=
lmpDataBearingLinkPropertyMismatch NOTIFICATION-TYPE=0A=
   OBJECTS       { ifIndex,=0A=
                   ifIndex,=0A=
                   lmpDataBearingLinkRemoteIfId }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when a data-bearing link=0A=
        property mismatch is detected on the node. The first ifIndex=0A=
        is the interface index of the TE link. The second ifIndex is=0A=
        the interface index of the data-bearing link. The remote =
entify=0A=
        interface id is the remote entity interface id received in =
the=0A=
        LinkSummary message."=0A=
   ::=3D { lmpNotifications 2 }=0A=
=0A=
-- Neighbor Trap=0A=
=0A=
lmpUnprotected NOTIFICATION-TYPE=0A=
   OBJECTS       { lmpCcNbrNodeId }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when all but one control =
channel=0A=
        is operational. If the only operational control channel =
fails,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
36]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        then there will be no more control channels between the pair =
of=0A=
        nodes and all the data-bearing links between the pair of =
nodes=0A=
        will go to degraded state."=0A=
   ::=3D { lmpNotifications 3 }=0A=
=0A=
-- Control Channel Trap=0A=
=0A=
lmpControlChannelUp NOTIFICATION-TYPE=0A=
   OBJECTS       { ifIndex }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when a control=0A=
        channel transitions to the up operational state."=0A=
   ::=3D { lmpNotifications 4 }=0A=
=0A=
lmpControlChannelDown NOTIFICATION-TYPE=0A=
   OBJECTS       { ifIndex }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when a control=0A=
        channel transitions to the down operational state."=0A=
   ::=3D { lmpNotifications 5 }=0A=
=0A=
-- TE Link Trap=0A=
=0A=
lmpTeLinkDegraded NOTIFICATION-TYPE=0A=
   OBJECTS       { ifIndex }=0A=
   STATUS        current=0A=
   DESCRIPTION=0A=
       "This notification is generated when a lmpTeLinkOperStatus=0A=
        object for a TE link enters the degraded state."=0A=
   ::=3D { lmpNotifications 6 }=0A=
=0A=
-- End of notifications=0A=
=0A=
=0A=
-- Module compliance=0A=
=0A=
lmpGroups=0A=
   OBJECT IDENTIFIER ::=3D { lmpConformance 1 }=0A=
=0A=
lmpCompliances=0A=
   OBJECT IDENTIFIER ::=3D { lmpConformance 2 }=0A=
=0A=
lmpModuleCompliance MODULE-COMPLIANCE=0A=
   STATUS current=0A=
   DESCRIPTION=0A=
       "Compliance statement for agents that support the=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
37]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
        MPLS LMP MIB."=0A=
   MODULE -- this module=0A=
=0A=
      -- The mandatory groups have to be implemented=0A=
      -- by all LMP-enabled devices. However, they may all be =
supported=0A=
      -- as read-only objects in the case where manual=0A=
      -- configuration is unsupported.=0A=
=0A=
      MANDATORY-GROUPS    { lmpNodeGroup,=0A=
                            lmpControlChannelGroup,=0A=
                            lmpLinkPropertyCorrelationGroup,=0A=
                            lmpPerfGroup,=0A=
                            lmpTeLinkGroup,=0A=
                            lmpDataBearingLinkGroup }=0A=
=0A=
      GROUP lmpLinkVerificationGroup=0A=
      DESCRIPTION=0A=
          "This group is mandatory for devices which support=0A=
           the link verification procedure."=0A=
=0A=
      -- Scalars=0A=
=0A=
      OBJECT      lmpAdminStatus=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpLinkVerificationInterval=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloIntervalDefault=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloIntervalDefaultMin=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloIntervalDefaultMax=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloDeadIntervalDefault=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
38]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloDeadIntervalDefaultMin=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloDeadIntervalDefaultMax=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      -- lmpNbrTable=0A=
=0A=
      OBJECT      lmpNbrLinkSumRetransmitInterval=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpNbrLinkSumRetransmitTimeout=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpNbrRowStatus=0A=
      SYNTAX      INTEGER { active(1), notInService(2),=0A=
                            createAndGo(4), destroy(6) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "The notReady(3) and createAndWait(5) states need=0A=
           not be supported."=0A=
=0A=
      OBJECT      lmpNbrStorageType=0A=
      SYNTAX      INTEGER { other(1) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Only other(1) needs to be supported."=0A=
=0A=
      -- lmpControlChannelTable=0A=
=0A=
      OBJECT      lmpCcAuthentication=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcConfigRetransmitInterval=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
39]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcConfigRetransmitTimeout=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloIntervalMin=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloIntervalMax=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloDeadIntervalMin=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcHelloDeadIntervalMax=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpCcRowStatus=0A=
      SYNTAX      INTEGER { active(1), notInService(2),=0A=
                            createAndGo(4), destroy(6) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "The notReady(3) and createAndWait(5) states need=0A=
           not be supported."=0A=
=0A=
      OBJECT      lmpCcOperStatus=0A=
      SYNTAX      INTEGER { up(1), down(2) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "A value of active(3), configuring(4), goingDown(5)=0A=
           need not be supported."=0A=
=0A=
      OBJECT      lmpCcStorageType=0A=
      SYNTAX      INTEGER { other(1) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
40]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
          "Only other(1) needs to be supported."=0A=
=0A=
      -- lmpLinkVerificationTable=0A=
=0A=
      OBJECT      lmpVerifyInterval=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpVerifyDeadInterval=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpVerifyAllLinks=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      -- lmpTeLinkTable=0A=
=0A=
      OBJECT      lmpTeLinkNbrNodeId=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required if the link verification=0A=
           procedure is enabled."=0A=
=0A=
      OBJECT      lmpRemoteTeLinkId=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required if the link verification=0A=
           procedure is enabled."=0A=
=0A=
      OBJECT      lmpRemoteTeLinkType=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required if the link verification=0A=
           procedure is enabled."=0A=
=0A=
      OBJECT      lmpTeLinkVerification=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpTeLinkFaultIsolation=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
41]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
      OBJECT      lmpTeLinkDwdm=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpTeLinkEncodingType=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpTeLinkBitRate=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpTeLinkWavelength=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required."=0A=
=0A=
      OBJECT      lmpTeLinkOperStatus=0A=
      SYNTAX      INTEGER { up(1), down(2), degraded(4) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "The testing(3) state need not be supported."=0A=
=0A=
      OBJECT      lmpTeLinkRowStatus=0A=
      SYNTAX      INTEGER { active(1), notInService(2),=0A=
                            createAndGo(4), destroy(6) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "The notReady(3) and createAndWait(5) states need=0A=
           not be supported."=0A=
=0A=
      OBJECT      lmpTeLinkStorageType=0A=
      SYNTAX      INTEGER { other(1) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Only other(1) needs to be supported."=0A=
=0A=
      -- lmpDataBearingLinkTable=0A=
=0A=
      OBJECT      lmpDataBearingLinkRemoteIfId=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Write access is not required if the link verification=0A=
           procedure is enabled."=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
42]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
      OBJECT      lmpDataBearingLinkOperStatus=0A=
      SYNTAX      INTEGER { up(1), down(2), degraded(4) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "A value of testing(3) need not be supported."=0A=
=0A=
      OBJECT      lmpDataBearingLinkRowStatus=0A=
      SYNTAX      INTEGER { active(1), notInService(2),=0A=
                            createAndGo(4), destroy(6) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "The notReady(3) and createAndWait(5) states need=0A=
           not be supported."=0A=
=0A=
      OBJECT      lmpDataBearingLinkStorageType=0A=
      SYNTAX      INTEGER { other(1) }=0A=
      MIN-ACCESS  read-only=0A=
      DESCRIPTION=0A=
          "Only other(1) needs to be supported."=0A=
=0A=
   ::=3D { lmpCompliances 1 }=0A=
=0A=
-- Units of conformance=0A=
=0A=
lmpNodeGroup OBJECT-GROUP=0A=
   OBJECTS { lmpAdminStatus,=0A=
             lmpNbrAdminStatus,=0A=
             lmpNbrOperStatus,=0A=
             lmpNbrRowStatus,=0A=
             lmpNbrStorageType,=0A=
             lmpUnprotectedTrapEnable=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed for LMP node configuration."=0A=
   ::=3D { lmpGroups 1 }=0A=
=0A=
lmpControlChannelGroup OBJECT-GROUP=0A=
   OBJECTS {=0A=
             lmpCcNbrNodeId,=0A=
             lmpNbrLinkSumRetransmitInterval,=0A=
             lmpNbrLinkSumRetransmitTimeout,=0A=
             lmpNbrAdminStatus,=0A=
             lmpNbrOperStatus,=0A=
             lmpNbrRowStatus,=0A=
             lmpNbrStorageType,=0A=
             lmpCcHelloIntervalDefault,=0A=
             lmpCcHelloIntervalDefaultMin,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
43]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
             lmpCcHelloIntervalDefaultMax,=0A=
             lmpCcHelloDeadIntervalDefault,=0A=
             lmpCcHelloDeadIntervalDefaultMin,=0A=
             lmpCcHelloDeadIntervalDefaultMax,=0A=
             lmpCcNbrNodeId,=0A=
             lmpRemoteCcId,=0A=
             lmpCcAuthentication,=0A=
             lmpCcConfigRetransmitInterval,=0A=
             lmpCcConfigRetransmitTimeout,=0A=
             lmpCcHelloInterval,=0A=
             lmpCcHelloIntervalMin,=0A=
             lmpCcHelloIntervalMax,=0A=
             lmpCcHelloDeadInterval,=0A=
             lmpCcHelloDeadIntervalMin,=0A=
             lmpCcHelloDeadIntervalMax,=0A=
             lmpCcOperStatus,=0A=
             lmpCcAdminStatus,=0A=
             lmpCcRowStatus,=0A=
             lmpCcStorageType,=0A=
             lmpCcUpDownTrapEnable=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed for LMP interface=0A=
           configuration."=0A=
   ::=3D { lmpGroups 2 }=0A=
=0A=
lmpLinkPropertyCorrelationGroup OBJECT-GROUP=0A=
   OBJECTS { lmpLinkPropertyMismatchTrapEnable }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed to implement the link=0A=
           property correlation procedure."=0A=
   ::=3D { lmpGroups 3 }=0A=
=0A=
lmpLinkVerificationGroup OBJECT-GROUP=0A=
   OBJECTS { lmpLinkVerificationInterval,=0A=
             lmpVerifyInterval,=0A=
             lmpVerifyDeadInterval,=0A=
             lmpVerifyTransportMechanism,=0A=
             lmpVerifyAllLinks=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed to implement the link=0A=
           verification procedure."=0A=
   ::=3D { lmpGroups 4 }=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
44]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
lmpPerfGroup OBJECT-GROUP=0A=
   OBJECTS { lmpCcHCInOctets,=0A=
             lmpCcInDiscards,=0A=
             lmpCcInErrors,=0A=
             lmpCcHCOutOctets,=0A=
             lmpCcOutDiscards,=0A=
             lmpCcOutErrors,=0A=
             lmpCcHCHelloReceived,=0A=
             lmpCcHCHelloSent,=0A=
             lmpCcConfigReceived,=0A=
             lmpCcConfigSent,=0A=
             lmpCcConfigRetransmit,=0A=
             lmpCcLinkSummaryReceived,=0A=
             lmpCcLinkSummarySent,=0A=
             lmpCcLinkSummaryRetransmit,=0A=
             lmpCcChannelFailReceived,=0A=
             lmpCcChannelFailSent,=0A=
             lmpCcChannelActiveReceived,=0A=
             lmpCcChannelActiveSent,=0A=
             lmpDataBearingLinkTestReceived,=0A=
             lmpDataBearingLinkTestSent=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed for providing performance=0A=
           information about LMP interfaces and data-bearing links."=0A=
   ::=3D { lmpGroups 5 }=0A=
=0A=
lmpTeLinkGroup OBJECT-GROUP=0A=
   OBJECTS { lmpTeLinkNbrNodeId,=0A=
             lmpRemoteTeLinkId,=0A=
             lmpRemoteTeLinkType,=0A=
             lmpTeLinkVerification,=0A=
             lmpTeLinkFaultIsolation,=0A=
             lmpTeLinkDwdm,=0A=
             lmpTeLinkEncodingType,=0A=
             lmpTeLinkBitRate,=0A=
             lmpTeLinkOperStatus,=0A=
             lmpTeLinkWavelength,=0A=
             lmpTeLinkRowStatus,=0A=
             lmpTeLinkStorageType,=0A=
             lmpTeLinkTrapEnable=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed for TE link configuration."=0A=
   ::=3D { lmpGroups 6 }=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
45]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
lmpDataBearingLinkGroup OBJECT-GROUP=0A=
   OBJECTS { lmpDataBearingLinkType,=0A=
             lmpDataBearingLinkRemoteIfId,=0A=
             lmpDataBearingLinkOperStatus,=0A=
             lmpDataBearingLinkRowStatus,=0A=
             lmpDataBearingLinkStorageType=0A=
           }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Collection of objects needed for data-bearing link=0A=
           configuration."=0A=
   ::=3D { lmpGroups 7 }=0A=
=0A=
lmpNotificationGroup NOTIFICATION-GROUP=0A=
   NOTIFICATIONS { lmpTeLinkPropertyMismatch,=0A=
                   lmpDataBearingLinkPropertyMismatch,=0A=
                   lmpUnprotected,=0A=
                   lmpControlChannelUp,=0A=
                   lmpControlChannelDown,=0A=
                   lmpTeLinkDegraded }=0A=
   STATUS  current=0A=
   DESCRIPTION=0A=
          "Set of notifications implemented in this module.=0A=
           None is mandatory."=0A=
   ::=3D { lmpGroups 8 }=0A=
=0A=
-- End of LMP-MIB=0A=
END=0A=
=0A=
=0A=
=0A=
10.  Security Considerations=0A=
=0A=
   It is clear that this MIB is potentially useful for monitoring of =
LMP=0A=
   enabled devices. This MIB can also be used for configuration of =
cer-=0A=
   tain objects, and anything that can be configured can be =
incorrectly=0A=
   configured, with potentially disastrous results.=0A=
=0A=
   At this writing, no security holes have been identified beyond =
those=0A=
   that SNMP Security [SNMPArch] is itself intended to address.  =
These=0A=
   relate to primarily controlled access to sensitive information =
and=0A=
   the ability to configure a device - or which might result from =
opera-=0A=
   tor error, which is beyond the scope of any security =
architecture.=0A=
=0A=
   There are a number of management objects defined in this MIB =
which=0A=
   have a MAX-ACCESS clause of read-write and/or read-create. Such=0A=
   objects may be considered sensitive or vulnerable in some network=0A=
   environments. The support for SET operations in a non-secure=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
46]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
   environment without proper protection can have a negative effect =
on=0A=
   network operations. The use of SNMP Version 3 is recommended over=0A=
   prior versions, for configuration control, as its security model =
is=0A=
   improved.=0A=
=0A=
   SNMPv1 or SNMPv2 are by themselves not a secure environment. Even =
if=0A=
   the network itself is secure (for example by using IPSec =
[IPSEC]),=0A=
   there is no control as to who on the secure network is allowed to=0A=
   access and GET/SET (read/change/create/delete) the objects in =
this=0A=
   MIB. It is recommended that the implementers consider the =
security=0A=
   features as provided by the SNMPv3 framework. Specifically, the =
use=0A=
   of the User-based Security Model [SNMPv3USM] and the View-based=0A=
   Access Control [SNMPv3VACM] is recommended. It is then a=0A=
   customer/user responsibility to ensure that the SNMP entity =
giving=0A=
   access to an instance of this MIB is properly configured to give=0A=
   access to the objects only to those principals (users) that have =
leg-=0A=
   itimate rights to indeed GET or SET (change/create/delete) them.=0A=
=0A=
   There are a number of managed objects in this MIB that may =
contain=0A=
   information that may be sensitive from a business perspective, in=0A=
   that they represent a customer's interface to the G-MPLS network.=0A=
   Allowing uncontrolled access to these objects could result in =
mali-=0A=
   cious and unwanted disruptions of network traffic or incorrect =
confi-=0A=
   gurations for these customers. There are no objects that are =
particu-=0A=
   larly sensitive in their own right, such as passwords or monetary=0A=
   amounts.=0A=
=0A=
=0A=
=0A=
11.  Acknowledgments=0A=
=0A=
   The general structure of this draft has been modeled around =
draft-=0A=
   ietf-mpls-lsr-mib-06.txt.=0A=
=0A=
   The authors wish to thank Dmitry Ryumkin.=0A=
=0A=
=0A=
12.  References=0A=
=0A=
   [LMP]         Lang, J., Mitra, K., Drake, J., Kompella, K.,=0A=
                 Rekhter, Y., Berger, L., Saha, S., Basak, D.,=0A=
                 Sandick, H., Zinin, A., and Rajagopalan, B.,=0A=
                 "Link Management Protocol", Internet Draft=0A=
                 <draft-ietf-mpls-lmp-02.txt>, March 2001.=0A=
=0A=
   [GMPLS]       Ashwood-Smith, P., Banarjee, A., Berger, L.,=0A=
                 Bernstein, G., Drake, J., Fan, Y., Kompella, K.,=0A=
                 Mannie, E., Lang, J., Rajagopalan, B., Rekhter, Y.,=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
47]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
                 Saha, D., Sharma, V., Swallow, G., and Tang, Z.,=0A=
                 "Generalized MPLS Signaling Function Description",=0A=
                 Internet Draft=0A=
                 <draft-ietf-mpls-generalized-signaling-04.txt>,=0A=
                 May 2001.=0A=
=0A=
   [BUNDLE]      Kompella, K., Rekhter, Y., and Berger, L.,=0A=
                 "Link Bundling in MPLS Traffic Engineering",=0A=
                 Internet Draft <draft-kompella-mpls-bundle-05.txt>,=0A=
                 February 2001.=0A=
=0A=
   [BUNDLE-MIB]  Dubuc, M., Dharanikota, S. Nadeau, T., Lang, J.,=0A=
                 "Link Bundling Management Information Base using=0A=
   SMIv2",=0A=
                 Internet Draft =
<draft-dubuc-mpls-bundle-mib-01.txt>,=0A=
                 May 2001.=0A=
=0A=
   [Assigned]    Reynolds, J., and J. Postel, "Assigned Numbers",=0A=
                 RFC 1700, October 1994. See also:=0A=
                 http://www.isi.edu/in-notes/iana/assignments/smi-=0A=
                 numbers=0A=
=0A=
   [IANAFamily]  Internet Assigned Numbers Authority (IANA), ADDRESS=0A=
                 FAMILY NUMBERS, (http://www.isi.edu/in-=0A=
                 notes/iana/assignements/address-family-numbers),=0A=
                 for MIB see:=0A=
                 ftp://ftp.isi.edu/mib/ianaaddressfamilynumbers.mib=0A=
=0A=
   [SNMPArch]    Harrington, D., Presuhn, R., and B. Wijnen, "An=0A=
                 Architecture for Describing SNMP Management=0A=
                 Frameworks", RFC 2571, April 1999.=0A=
=0A=
   [SMIv1]       Rose, M., and K. McCloghrie, "Structure and=0A=
                 Identification of Management Information for =
TCP/IP-=0A=
                 based Internets", RFC 1155, May 1990.=0A=
=0A=
   [SNMPv1MIBDef]Rose, M., and K. McCloghrie, "Concise MIB=0A=
                 Definitions", RFC 1212, March 1991.=0A=
=0A=
   [SNMPv1Traps] M. Rose, "A Convention for Defining Traps for use=0A=
                 with the SNMP", RFC 1215, March 1991.=0A=
=0A=
   [RFC2572]     Case, J., Harrington D., Presuhn R., and B. Wijnen,=0A=
                 "Message Processing and Dispatching for the Simple=0A=
                 Network Management Protocol (SNMP)", RFC 2572,=0A=
                 April 1999.=0A=
=0A=
   [RFC2574]     Blumenthal, U., and B. Wijnen, "User-based Security=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
48]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
                 Model (USM) for version 3 of the Simple Network=0A=
                 Management Protocol (SNMPv3)", RFC 2574, April=0A=
                 1999.=0A=
=0A=
   [RFC1905]     Case, J., McCloghrie, K., Rose, M., and S.=0A=
                 Waldbusser, "Protocol Operations for Version 2 of=0A=
                 the Simple Network Management Protocol (SNMPv2)",=0A=
                 RFC 1905, January 1996.=0A=
=0A=
   [RFC2573]     Levi, D., Meyer, P., and B. Stewart, "SNMPv3=0A=
                 Applications", RFC 2573, April 1999.=0A=
=0A=
   [RFC2575]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-=0A=
                 based Access Control Model (VACM) for the Simple=0A=
                 Network Management Protocol (SNMP)", RFC 2575,=0A=
                 April 1999.=0A=
=0A=
   [RFC2570]     Case, J., Mundy, R., Partain, D., and B. Stewart,=0A=
                 "Introduction to Version 3 of the Internet-standard=0A=
                 Network Management Framework", RFC 2570, April=0A=
                 1999.=0A=
=0A=
   [SMIv2]       McCloghrie, K., Perkins, D., Schoenwaelder, J.,=0A=
                 Case, J., Rose, M., and S. Waldbusser,=0A=
                 "Structure of Management Information=0A=
                 Version 2 (SMIv2)", RFC 2578, April 1999.=0A=
=0A=
   [SNMPv2TC]    McCloghrie, K., Perkins, D., Schoenwaelder, J.,=0A=
                 Case, J., Rose, M., and S. Waldbusser,=0A=
                 "Textual Conventions for SMIv2",=0A=
                 RFC 2579, April 1999.=0A=
=0A=
   [SNMPv2Conf]  McCloghrie, K., Perkins, D., Schoenwaelder, J.,=0A=
                 Case, J., Rose, M., and S. Waldbusser,=0A=
                 "Conformance Statements for SMIv2",=0A=
                 RFC 2580, April 1999.=0A=
=0A=
   [SNMPv1]      Case, J., Fedor, M., Schoffstall, M., and J. Davin,=0A=
                 "Simple Network Management Protocol", RFC 1157, May=0A=
                 1990.=0A=
=0A=
   [SNMPv2c]     Case, J., McCloghrie, K., Rose, M., and S.=0A=
                 Waldbusser, "Introduction to Community-based=0A=
                 SNMPv2", RFC 1901, January 1996.=0A=
=0A=
   [SNMPv2TM]    Case, J., McCloghrie, K., Rose, M., and S.=0A=
                 Waldbusser, "Transport Mappings for Version 2 of=0A=
                 the Simple Network Management Protocol (SNMPv2)",=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
49]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
                 RFC 1906, January 1996.=0A=
=0A=
   [SNMPv3MP]    Case, J., Harrington D., Presuhn R., and B. Wijnen,=0A=
                 "Message Processing and Dispatching for the Simple=0A=
                 Network Management Protocol (SNMP)", RFC 2272,=0A=
                 January 1998.=0A=
=0A=
   [SNMPv3USM]   Blumenthal, U., and B. Wijnen, "User-based Security=0A=
                 Model (USM) for version 3 of the Simple Network=0A=
                 Management Protocol (SNMPv3)", RFC 2574, April=0A=
                 1999.=0A=
=0A=
   [SNMPv2PO]    Case, J., McCloghrie, K., Rose, M., and S.=0A=
                 Waldbusser, "Protocol Operations for Version 2 of=0A=
                 the Simple Network Management Protocol (SNMPv2)",=0A=
                 RFC 1905, January 1996.=0A=
=0A=
   [SNMPv3App]   Levi, D., Meyer, P., and B. Stewart, "SNMPv3=0A=
                 Applications", RFC 2273, January 1998.=0A=
=0A=
   [SNMPv3VACM]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-=0A=
                 based Access Control Model (VACM) for the Simple=0A=
                 Network Management Protocol (SNMP)", RFC 2575,=0A=
                 April 1999.=0A=
=0A=
   [IPSEC]       Kent, S., and Atkinson, R., "Security Architecture=0A=
                 for the Internet Protocol", RFC 2401, November=0A=
                 1998.=0A=
=0A=
   [IFMIB]       McCloghrie, K., and Kastenholtz, F., "The =
Interfaces=0A=
                 Group MIB", RFC 2863, June 2000.=0A=
=0A=
   [BCP14]       Bradner, S., "Key words for use in RFCs to Indicate=0A=
                 Requirement Levels", BCP 14, RFC 2119, March 1997.=0A=
=0A=
=0A=
=0A=
13.  Authors' Addresses=0A=
=0A=
Martin Dubuc                         Jonathan P. Lang=0A=
edgeflow, Inc.                       Calient Networks, Inc.=0A=
329 March Rd.                        25 Castilian Drive=0A=
Kanata, ON, CANADA K2K 2E1           Goleta, CA 93117=0A=
Phone: +1-613-270-9279 x253          Email: [email-masked]=0A=
Email: [email-masked]=0A=
=0A=
Sudheer Dharanikota                  Evan McGinnis=0A=
Nayna Networks, Inc.                 Calient Networks, Inc.=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
50]=0A=
=0C=0A=
Internet Draft                MPLS LMP MIB                  May 22, =
2001=0A=
=0A=
=0A=
157 Topaz Street                     5853 Rue Ferrari=0A=
Milipitas, CA 95035                  San Jose, CA 95138=0A=
Phone: +1-408-956-8000 x357          Email: [email-masked]=0A=
Email: [email-masked]=0A=
=0A=
Thomas D. Nadeau=0A=
Cisco Systems, Inc.=0A=
300 Apollo Drive=0A=
Chelmsford, MA 01824=0A=
Phone: +1-978-244-3051=0A=
Email: [email-masked]=0A=
=0A=
=0A=
=0A=
14.  Full Copyright Statement=0A=
=0A=
=0A=
   Copyright (C) The Internet Society (2000). All Rights Reserved.=0A=
=0A=
   This document and translations of it may be copied and furnished =
to=0A=
   others, and derivative works that comment on or otherwise explain =
it=0A=
   or assist in its implementation may be prepared, copied, =
published=0A=
   and distributed, in whole or in part, without restriction of any=0A=
   kind, provided that the above copyright notice and this paragraph =
are=0A=
   included on all such copies and derivative works. However, this =
docu-=0A=
   ment itself may not be modified in any way, such as by removing =
the=0A=
   copyright notice or references to the Internet Society or other=0A=
   Internet organizations, except as needed for the purpose of =
develop-=0A=
   ing Internet standards in which case the procedures for =
copyrights=0A=
   defined in the Internet Standards process must be followed, or as=0A=
   required to translate it into languages other than English.=0A=
=0A=
   The limited permissions granted above are perpetual and will not =
be=0A=
   revoked by the Internet Society or its successors or assigns.  =
This=0A=
   document and the information contained herein is provided on an =
"AS=0A=
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING =
TASK=0A=
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT =
NOT=0A=
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN =
WILL=0A=
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF =
MERCHANTABILITY=0A=
   OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Dubuc et al.             Expires November 2001                 [Page =
51]=0A=
=0C=0A=

------_=_NextPart_000_01C0E9E7.1310F22E--

Delivery-date: Thu, 31 May 2001 01:18:42 -0700
From: Heiles Juergen <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>, "'Eric Gray'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Thu, 31 May 2001 10:14:19 +0200

Greg,

I don't have complaints about these features as such. My two concerns are
- we should clearly identify what is standard SDH/SONET and what not
- and we should be confident that we understand these features and their implications so that the signaling support is ok

Juergen

> -----Original Message-----
> From:	Bernstein, Greg [SMTP:[email-masked]]
> Sent:	Tuesday, May 29, 2001 8:01 PM
> To:	'Eric Gray'
> Cc:	[email-masked]'; [email-masked]; [email-masked]
> Subject:	RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi Eric (Gray), Ciena supports all the concatenation extensions discussed in
> the draft. Note that LTE only equipment doesn't need to do anything special
> to support the transport of virtually concatenated signals.
> The transparency options are larger and apply to more than one type of
> equipment. Hence, I might not offer all types on the same box (DWDM, Core
> Switching, Metro Switch). 
> 
> Are the complaints from BT, Lucent, Siemens and AT&T primarily directed at:
> (1) Extended concatenation types
> (2) Semi-transparency feature
> (3) Path group/AUG-N signal type
> Are there other problems?  Would leaving these for further study get us out
> of this deadlock? I.e., some don't want these in a separate specification,
> some do. Note that various companies have implemented an earlier less mature
> form of this spec and acheived some measure of interoperability, i.e., the
> closed door UNH OIF session and the upcomming supercom demo. It would be
> very helpful for the industry in general to move this forward now even
> without some of the more "advanced features". 
> 
> Note, however, I do receive pressure from carriers to be open and to provide
> these features.
> 
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation 
> 
> 
> 
> -----Original Message-----
> From: Eric Gray [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 10:26 AM
> To: Bernstein, Greg
> Cc: [email-masked]'; [email-masked]; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> 
> Greg,
> 
>     I think it is fair to both ask and answer the question -
> 
>         'which companies support feature X'
> 
> - on these mailing lists.  An answer is certainly relevant, it
> need not be in the form of a product announcement and it is
> much better than a choice of poking around in the dark at
> shadows of 'some vendors' or being one of a few hundred
> people to call the oracle.
> 
>     For once, I'd like to see a straight forward answer.  How
> naive I must be...
> 
> --
> Eric Gray
> 
> You wrote:
> 
> > Hi Tony, I didn't think we were supposed to advertise on these e-mail
> > exploders so I didn't name names. See comments below.
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> > Phone: (510) 573-2237
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, May 29, 2001 8:32 AM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Greg,
> >
> > From your points:
> >
> > (1) progressive loosening ... equates to non-compliant.
> > >> Actually not, this equipment is completely G.707/T1.105 compliant. This
> > is an extension not a further restriction.
> >
> > (2) Which vendors? Let's here some names. Or even better, from the vendors
> > themselves.
> > >> Don't want to plug any particular company, but feel free to give me a
> > call.
> >
> > (3) How does this equipment negotiate feature availability?
> > >> Numerous ways: with "end systems (across a UNI)" this is what the
> service
> > discovery part of the OIF UNI is about, with "peers" this is what the
> > routing extensions are partially about.
> > (4) Of course it's proprietary!
> > >> Actually "proprietary" means "no one else can offer it". Like in the> 
> old
> > PBX days where the manufacturers would patent a "feature" like
> "distinctive
> > ringing" so that no one else could offer it or that license fees would
> need
> > to be paid.  I took this definition from Randy Bush. I would say this is a
> > non-standard feature.
> > (5) Has this level of signalling been proposed yet?
> > >> Partially, via GMPLS SONET/SDH extensions.
> >
> > Still nobody answers the question of why not use virtual concatenation,
> > which does all that is required and more. Or do people have too much half
> > baked silicon!
> > >> Virtual concatenation is really a PTE function that uses path overhead
> > and is not "path transparent". The concatenation extensions (arbitrary and
> > flexible) are fairly straight forward line (MS) layer extensions that
> > prevent the need for re-grooming.
> >
> > Regards
> >
> >         Tony
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: 29 May 2001 16:26
> > To: [email-masked]'; [email-masked]; [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > I think there is some confusion in the intention of introducing the
> > concatenation options.  A few points:
> > (1) The two additional concatenation options introduced in Eric's proposal
> > "arbitrary contiguous" and "flexible arbitrary" are the progressive
> > loosening of the existing "contiguous concatenation" restrictions of G.707
> > or T1.105.
> > (2) Several vendors offer one or both of these extensions.
> > (3) Equipment that offers these extensions can always work with equipment
> > that doesn't offer these extensions.
> > (4) These are not proprietary features using the definition of
> "proprietary"
> > as furnished by Randy Bush in a recent e-mail.
> > (5) GMPLS routing and signaling can be used to negotiate the use of these
> > features within a network of mixed equipment and hence make the best use
> of
> > all types of equipment.
> >
> > Greg B.
> > ***********************************
> > Dr. Greg M. Bernstein
> > Senior Scientist, Ciena Corporation
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, May 29, 2001 1:51 AM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Eric,
> >
> > This is not describing just a way to use SONET/SDH as it changes every box
> > in the network! To use this there are changes/additions required to G,707
> > and G.783.
> >
> > Neither is this a new feature. Concatenation is already described and
> > explained.
> >
> > I do not understand the linkage between GMPLS and concatenation. the two
> are
> > independent up to the point that you may wish to attempt variable
> bandwidth
> > allocation. At this point extensions to concatenation are requires, and as
> I
> > have already stated this work is already under discussion in ITU.
> >
> > Regards
> >
> >         Tony
> >
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: 28 May 2001 12:06
> > To: 'Rob Coltun'; John Drake
> > Cc: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hello Rob,
> >
> > > Is it really that big an issue to just keep them in a separate RFC?
> >
> > Even if there is absolutely no standard required from ITU-T ? Nothing is
> > needed for arbitrary concatenation, AUG-X, TUG, etc. We are just
> describing
> > a way to use SDH/SONET. There was no technical discussion about that.
> >
> > Do you mean that any feature that is not defined by ITU-T should not be
> > published in the standard track ? For instance the concept of waveband
> > switching ? The signal types ? The link protection ? The protection and
> > restoration ?
> >
> > What is the added-value of GMPLS if we cannot take some freedom with the
> > existing standards ? Our added-value is to match the new developments of> 
> the
> > industry, with the added-value that was added and not only the published
> > standards from ITU-T.
> >
> > We already agreed on the following approach:
> >
> > - all mechanisms are optional (zero means I don't care).
> > - we indicate clearly what is not defined in ITU-T/T1X1 standards.
> >
> > Can we simply use this approach ?
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Saturday, May 26, 2001 1:20 AM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the scope
> > of the IETF to define - so this keeps us more in line with (in this case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Wed, 30 May 2001 11:15:28 -0700
From: Jonathan Lang <[email-masked]>
To: 'Dimitrios Pendarakis' <[email-masked]>, Jonathan Lang <[email-masked]>, 'Fong Liaw' <[email-masked]>, 'suresh Katukam' <[email-masked]>
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Wed, 30 May 2001 11:08:09 -0700

Dimitrios,
  The luxury of being in meetings all morning is that I had the chance to
read your email as well as the responses from David, Lyndon, and Eric before
I respond.  Since I agree with their response, I will try to be brief.
Using RSVP Hellos to detect RSVP module failures is in my mind the correct
usage for them.  Control channel failures should be detected by mechanisms
designed to detect them (e.g., LMP Hellos).   One scenario that carriers are
interested in supporting is the notion of having parallel redundant control
channels for signaling purposes.  We will need to support other mechanisms
for detecting control channel failures in this case.

Thanks,
Jonathan

> -----Original Message-----
> From: Dimitrios Pendarakis [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 7:24 AM
> To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'
> Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> Subject: RE: Last call - RSVP problems
> 
> 
> Jonathan,
> 
> Could you please clarify why you think RSVP Hello doesn't work for 
> parallel (redundant) control channels? Control channel redundancy 
> is obviously important; however I don't think it relates to the 
> usefulness of the RSVP hello mechanism, at least in the context of 
> this discussion.
> 
> The whole issue is one of layering: LMP hello allows you to detect 
> individual link (or control channel) failures; RSVP Hello allows
> you to detect that you 've lost contact with your signaling peer
> for whatever reason (failure of all redundant control channels, 
> failure of the RSVP daemon, etc.). Since they operate at different
> levels they are to some extend complementary; once RSVP Hello tells
> you that your peer is not reachable, you could use LMP Hello's to 
> try to pinpoint where the problem occurred. 
> 
> For clarification, the "control channel failure" mentioned in
> Fong's mail that started this discussion refers to a failure of the
> signaling channel, i.e., inability to communicate with your signaling
> peer, not failure of specific (individual) control channels. As such, 
> I still believe RSVP Hello is a more accurate detection mechanism.
> 
> Please see some additional comments inline.
> 
> Thanks,
> Dimitris
> 
> 
> >   If you're using the RSVP Hello to detect the failure of the 
> > RSVP module
> > only, then this is fine.  If you're using the RSVP Hello to 
> detect (or
> > rather, infer) control channel failures, I have a problem.  
> > For starters, I
> > don't think it works for parallel (redundant) control 
> > channels; if control
> > channel redundancy is *not* important for SPs, then it's not 
> > as much of an
> > issue, however, I think you're overloading the semantics of 
> > the RSVP Hello.
> > 
> >   See additional comments inline.
> > 
> > Thanks,
> > Jonathan
> > 
> > > 
> > > Hi Jonathan,
> > > 
> > > What needs to be detected here is the inability to send and 
> > > receive signaling messages to and from your RSVP peer. In this 
> > > respect, using RSVP Hello is a more accurate mechanism for 
> > > detecting failures since it is part of the RSVP protocol and 
> > > independent of the link layer used to realize the control 
> > > channel. As you point out, if you prefer redundant control 
> > > channels for resiliency, and want to rely on LMP only, you have
> > > to correlate all LMP detected failures in order to declare a 
> > > control channel failure.
> > This is not correct.  LMP allows you to detect individual 
> > control channel
> > failures, even when there are multiple (redundant) control 
> > channels.  The
> > RSVP Hello cannot do this.
> > 
> 
> Sure, as I pointed above, RSVP Hello is not intended to detect 
> individual link failures. At the risk of sounding repetitive, the
> point here is that these are different mechanisms that serve 
> different purpose. For example, if you have 3 (redundant) IP control 
> channels and rely on LMP Hello only, in order to infer failure of the 
> signaling channel with your peer, you would have to correlate LMP 
> failures in all three channels. 
> 
> > > With RSVP Hello you would rely on a 
> > > single set of event(s) to detect the failure.
> > To be clear, the failure of the RSVP module.
> 
> Or simultaneous failure of all IP control channels...
> 
> > 
> > > To go even further, what if all your control channels are working
> > > fine, but your RSVP daemon has crashed, for whatever reason.
> > > LMP hellos will keep going across but RSVP messages will not...
> > This is where the RSVP Hello has its place.
> > 
> > > 
> > > All this points to the (certainly non-trivial) problem of failure 
> > > detection and correlation at different layers. I am not trying to
> > > say that RSVP Hello is the perfect or only mechanism we 
> should rely 
> > > on, but it certainly has a place in addressing the problem.
> > agreed.  see above comment.
> > 
> > > 
> > > Thanks,
> > > Dimitris
> > > 
> > > PS. Hopefully we are not too far apart so we might not have
> > > to keep the discussion going for too long :-)
> > > In any case I believe it has some relevance here as well.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 6:56 PM
> > > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; 'suresh
> > > > Katukam'; [email-masked]
> > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > Subject: RE: Last call - RSVP problems
> > > > 
> > > > 
> > > > Dimitris,
> > > >   The RSVP Hello Extension is intended to detect node 
> > > failures and not
> > > > necessarily link (control channel) failures.  In particular, 
> > > > the tunnel
> > > > draft says, "It should be noted that node failure detection 
> > > > is not the same
> > > > as a link failure detection mechanism, particularly in the 
> > > > case of multiple
> > > > parallel unnumbered links."  What happens if you want 
> > > > redundant control
> > > > channels for control-channel resiliency?  I believe you would 
> > > > still want a
> > > > mechanism to detect control channel (link-layer) failures.
> > > > 
> > > >   In LMP, you can have multiple active control channels 
> > > > between a pair of
> > > > nodes.  You can configure control channels over shared 
> > > > Ethernet and over
> > > > SONET/SDH overhead, etc.  You send keep-alive Hellos over 
> > > each control
> > > > channel.  If you so desire, you can send all signaling 
> > > > messages over the
> > > > Ethernet control channels.  You can also choose to send all 
> > > > remaining LMP
> > > > messages over the SONET/SDH-based control channels.  Keeping 
> > > > RSVP Hellos as
> > > > "optional" would be fine.  Making them mandatory doesn't seem 
> > > > like the right
> > > > solution.
> > > > 
> > > > Thanks,
> > > > Jonathan
> > > > 
> > > > P.S.  Should we move this discussion on the OIF list??
> > > > 
> > > > > -----Original Message-----
> > > > > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > > > > Sent: Friday, May 25, 2001 3:16 PM
> > > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; 
> > > > [email-masked]
> > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > Subject: RE: Last call - RSVP problems
> > > > > 
> > > > > 
> > > > > Hi Jonathan,
> > > > > 
> > > > > One point to consider is that the signaling control 
> > > > > channel might be realized over a different link layer 
> > > > > than LMP. For example, LMP might be running in-fiber
> > > > > over SONET/SDH overhead bytes, while RSVP is running 
> > > > > over an out-of-band network such a shared Ethernet.
> > > > > RSVP Hello allows independent detection of signaling 
> > > > > channel failure, so it's a useful option to keep.
> > > > > 
> > > > > Thanks,
> > > > > Dimitris
> > > > > 
> > > > > Dimitris Pendarakis
> > > > > Tellium, Inc.
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > > Sent: Friday, May 25, 2001 5:30 PM
> > > > > > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > > Subject: RE: Last call - RSVP problems
> > > > > > 
> > > > > > 
> > > > > > Fong,
> > > > > > 
> > > > > > 
> > > > > > <snip>
> > > > > > > Same as (2), any proposals that remove the refresh 
> > mechanism 
> > > > > > > is going to be difficult to prove that all cases 
> > are covered.
> > > > > > > 
> > > > > > > Instead, we (will) recommend the following in OIF UNI 
> > > document:
> > > > > > >    
> > > > > > >    Use RSVP Hello to detect control channel failure.
> > > > > > Why wouldn't you use the LMP Hello to detect 
> control channel 
> > > > > > failure?  This
> > > > > > is exactly what it is designed for.  From 
> > > > > > draft-ietf-mpls-lsp-tunnel-08.txt,
> > > > > > 
> > > > > >   "This (RSVP Hello) mechanism is intended to be used when 
> > > > > > notification of
> > > > > > link layer
> > > > > >    failures is not available and unnumbered links are not 
> > > > > > used, or when
> > > > > >    the failure detection mechanisms provided by the link 
> > > > > layer are not
> > > > > >    sufficient for timely node failure detection."
> > > > > >  
> > > > > > >    If a control channel failure is detected, LSPs states 
> > > > > > >    are maintained as if a node continues to receive 
> > > > > > >    RSVP refresh message from the failed control channel.
> > > > > > >    The recommended Hello timer will be in second range,
> > > > > > >    instead of ms range specified in RSVP-TE draft.  
> > > > > > > 
> > > > > > >    If a control channel failed permanently, manual 
> > > intervention 
> > > > > > >    may be required. This is to be studied.
> > > > > > > 
> > > > > > > p.s The text is currently being drafted as we type.
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

Delivery-date: Wed, 30 May 2001 11:05:03 -0700
From: "Irfan Lateef" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: [IP-Optical] RE: GMPLS Last Calls
Date: Wed, 30 May 2001 14:03:30 -0400

Dimitri,

The para from your email as I quoted below or some form of it,
explaining or atleast mentioning the independence of the protocol
to the model should be included in the text. This will go a long
way in future helping the readers in understanding the position of
the protocol with reference to the models.

Irfan Lateef

>You speak about GMPLS profiles for the UNI at the OIF, and potentially
>in the future for ASTN/ASON which are completely independent of the
>current GMPLS specification (self-consistency). We don't taylor a
>protocol suite based on the model to which we have to apply it since
>if the model change - you have to re-design your protocol ! -. Today
>GMPLS can be accomodated to any UNI/NNI interfaces coming from
>wherever you want. Why ? Because from the beginning it is a model
>independent specification ! By defining the profile you desire you
>can apply it to the OIF UNI / ASON UNI (if still needed) / etc.

>From: Dimitri Papadimitriou <[email-masked]>
>To: Eve Varma <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked],        
>[email-masked], [email-masked]
>Subject: Re: [IP-Optical] RE: GMPLS Last Calls
>Date: Tue, 29 May 2001 22:40:31 +0200
>
>Hi,
>
>In this e-mail you speak about a "Requirements Design Team"
>do you refer to the NNI OIF project here i guess ?
>
>I wouldn't like to (re-)explain here the nice "reception" offered
>during the San Diego IETF meeting on the BT draft. Moreover, what's
>sound very strange here is that the author himself didn't present
>his draft during the last IETF meeting (since there was a -01 version)!
>Are you serious when you speak about ASON UNI requirements at the
>IETF ?
>
>You speak about GMPLS profiles for the UNI at the OIF, and potentially
>in the future for ASTN/ASON which are completely independent of the
>current GMPLS specification (self-consistency). We don't taylor a
>protocol suite based on the model to which we have to apply it since
>if the model change - you have to re-design your protocol ! -. Today
>GMPLS can be accomodated to any UNI/NNI interfaces coming from
>wherever you want. Why ? Because from the beginning it is a model
>independent specification ! By defining the profile you desire you
>can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also,
>don't spend to many time at the OIF to define the architecture it is
>already done...
>
>Now you mention one question which is under discussion about the
>correlation between the planes... the good point is that with the
>current work done at the IETF and OIF a solution will be found.
>However this does not mean AT ALL that the current GMPLS
>specifications are not going toward a very good direction. Therefore
>i don't think we need the additional text as you propose. In fact this
>is clearly an extended problem of the "restoration" issue already
>discussed on this mailing list and we already agree upon.
>
>Thanks,
>- Dimitri.
>
>Eve Varma wrote:
> >
> > Hi all,
> >
> > Watching the various emails regarding the GMPLS drafts, I see several
> > issues being raised related to some concerns that service provider
> > requirements haven't been sufficiently reflected in the GMPLS signaling
> > specifications - or at least, not been tested against.  (An initial set
> > of requirements was provided by BT on
> > Considerations on the development of an Optical Control Plane -
> > http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
> > Monica has mentioned other currently available sources of service
> > provider requirements as well, such as the Carriers Optical Services
> > Framework and Associated Requirements for the UNI, developed in the OIF
> > and submitted to T1 and ITU-T.  Some requirements were also submitted
> > earlier in the draft Requirements on the ASON UNI -
> > 
>http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
> > )
> >
> > For example, assuring separation of the control plane from the data
> > plane continues to arise - the GMPLS architecture document mentions this
> > separation, but it's not clear how the GMPLS signaling specifications
> > reflect the implications of this decoupling.  This is best illustrated
> > in the handling of control plane failures.  In particular, what happens
> > to established circuit connections if the control plane fails? If the
> > control plane recovers, how do we sync the connection state?  As an
> > example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
> > the reservation state in routers and hosts. RSVP soft state is created
> > and periodically refreshed by Path and Resv messages. The state is
> > deleted if no matching refresh messages arrive before the expiration of
> > a "cleanup timeout" interval." This means that if for whatever reason
> > control messages are lost, the associated data paths will be released.
> > Thus there is strong failure correlation between the control plane and
> > data plane, which is inconsistent with the GMPLS architecture document,
> > and also results in tearing down optical connections resulting from even
> > temporary failures in the control plane.
> >
> > I also understand the other comments from Hirokazu and Shehzad re
> > exclusion of NSAP, having been at the last OIF meeting where there was
> > considerable and spirited discussion of this issue.  The current GMPLS
> > architecture document specifically excludes NSAP, and from the last OIF
> > meeting 6 out of 12 operators discussing this issue felt there was some
> > need to support NSAP addressing.
> >
> > Given that the Requirements Design Team will be starting shortly, I
> > concur with Yuri's suggestion for inclusion of a clear statement of what
> > is - and isn't - covered in the GMPLS Signaling Description, RSVP
> > Extensions, LDP Extensions drafts.   A suggestion for such text is
> > provided below (the intro will need to be tailored to each draft):
> >
> > "Overall, the objective of Generalized MPLS is to adapt MPLS signaling
> > and other protocols to enable their applicability to various switching
> > technologies.   A key motivating application has been applicability to
> > support a distributed control plane for various circuit-switching
> > technologies.   The signaling specifications contained within the these
> > drafts offer a starting point towards this goal; their current scope and
> > applicability, and areas for further assessment, are summarized below:
> >
> > These drafts provide some extensions to traditional MPLS signaling and
> > the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
> > standard track documents) have not been modified.   It is noted that
> > MPLS signaling has been designed with a focus upon packet-switched
> > network based applications, utilizing  requirements and architectural
> > constructs suitable for such applications.   There may be significant
> > distinguishing characteristics with regard to requirements and
> > architectural considerations  for a distributed control plane that
> > supports circuit-switched network applications.  One well acknowledged
> > instance involves the decoupling of the control plane from the data
> > plane.  Such differences may have substantive impact on the signaling
> > mechanisms, the details of which require further study.  In addition,
> > upon further study of operational requirements and circuit-switching
> > technology specific aspects, further signaling extensions may be
> > required.
> >
> > These drafts are focussed upon intra-area signaling interfaces, and do
> > not address issues and considerations related to other domains of
> > usage.   Applicability to inter-area and inter-domain interfaces
> > requires further study."
> >
> > Hope this helps us move forward.
> >
> > Cheers,
> >   Eve
> >
> > itu
> >
> > [email-masked] wrote:
> > >
> > > Hi,
> > >
> > > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS 
>signalling
> > > drafts.
> > >
> > > (1) Decoupling of the control plane from the data plane should be 
>clearly
> > > stated.
> > >
> > > This decoupling clearly has an impact on how the protocols should be 
>defined
> > > to cope with control plane failures.
> > >
> > > (2) Exclusion of NSAP
> > >
> > > The GMPLS architecture document, (which logically speaking should 
>perhaps
> > > have been put forward for last call, ahead of the functional 
>description)
> > > explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> > > communications channels (DCC bytes) therefore the use of alternative
> > > addressing within the same channels may have an adverse effect on
> > > interworking with legacy equipment, particularly with regard to 
>management.
> > > This raises the general concern of what level of compatibility is
> > > required/desired with legacy SDH/SONET equipment.  This debate whilst 
>likely
> > > to be contentious, is unavoidable as the interworking of control 
>plane,
> > > management plane and transport will have a direct impact on how this
> > > equipment is deployed and the economics of whether such deployments 
>will
> > > ever pay off.
> > >
> > > (3) Requirements from both security and OSS has not been discussed 
>fully
> > > yet.
> > >
> > > Security concerns have not been fully addressed, particularly at the
> > > architectural level.  The use of separate control network may 
>necessitate
> > > the need for 24 hour staff to protect against 'Denial of Service' 
>attacks as
> > > currently happens for IP router networks.  The interaction between the
> > > management plane and control plane need to be addressed, for example 
>it is
> > > undesirable to have multiple alarms generated when circuits are 
>created and
> > > torn down otherwise the management of a large scale network will 
>become
> > > impossible.  Discussions on service aspects need to take place, 
>otherwise
> > > the adoption of GMPLS equipment may be hampered, by these (solvable)
> > > concerns.
> > >
> > > Best regards
> > >
> > > Shehzad Mirza
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hirokazu Ishimatsu [SMTP:[email-masked]]
> > > > Sent: 29 May 2001 02:46
> > > > To:   George Swallow; ccamp; mpls
> > > > Cc:   ip-optical; tsg15q11; tsg13q10
> > > > Subject:      [IP-Optical] RE: GMPLS Last Calls
> > > >
> > > > Hi,
> > > >
> > > > From a carrier's perspective, my concerns about GMPLS signaling 
>drafts
> > > > are as follows:
> > > >
> > > > (1) Decoupling of the control plane from the data plane should be 
>clearly
> > > >      stated.
> > > > (2) Exclusion of NSAP
> > > > (3) Requirements from both security and OSS (Operating Support 
>System)
> > > >      has not been discussed fully yet.
> > > >
> > > > Best regards,
> > > > Hirokazu Ishimatsu
> > > > Japan Telecom
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]On
> > > > > Behalf Of George Swallow
> > > > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > > > To: [email-masked]; [email-masked]
> > > > > Subject: GMPLS Last Calls
> > > > >
> > > > >
> > > > > This message initiates a last call on four GMPLS drafts.  The last
> > > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > > >
> > > > > The drafts are:
> > > > >
> > > > >     1.  Generalized MPLS - Signaling Functional Description
> > > > >
> > > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > > >
> > > > >
> > > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > > >
> > > > >
> > > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > > >
> > > > >
> > > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > > >
> > > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > > >
> > > > >
> > > > > The last call closes May 29, 12 pm GMT.
> > > > >
> > > > >
> > > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > > >
> > > > >
> > > > > 
>======================================================================
> > > > > George Swallow       Cisco Systems                   (978) 
>244-8143
> > > > >                      250 Apollo Drive
> > > > >                      Chelmsford, Ma 01824
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
><< dimitri.papadimitriou.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 30 May 2001 10:04:57 -0700
Date: Wed, 30 May 2001 13:03:04 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: Re: Arbitrary concatenation proposals

Hi John,

> The I-D was submitted as a way to "enhance" the existing codepoints. I
> did not try to specify what should or should not belong. And as I said
> many times now, I am not requesting that these all be moved. I merely
> want to know the metrics for including things.
> 
> JD:  So your comments last week ("if an idea stinks, it doesn't matter
> how many times some idea is presented, it still stinks that many times"
> and "if you see a million flies eating feces, would you also eat?" are
> to be considered a momentary aberration?
> 

:-) My use of those colorful (probably less appetizing) analogies was
trying to remind folks that we should not fall into complacency and
simply accept something because it's there, but try to be diligent in
understanding why something was chosen. I did not mean it to imply
"please remove everything because it stinks". 

so if you want to consider it a momentary aberration, that's fine.
Sometimes I do get over-excited... ;-)

> * Yes, transparency is in the OIF carrier requirements document. So then
> again, as I mentioned many times, if our metric is "more than 2
> vendor/carrier" or "more than half of vendor/carrier community" or "it
> should be included because", then let's include it. But where would it
> be included? In the GMPLS or a separate document? Either way, it will be
> captured.
> 
> JD:  Why do we need to invent a new methodology for deciding whether to
> include transparency and arbitrary concat?  The existing methodology
> which is, as I understand it, rough consensus, should be sufficient.
> 

I was merely trying to help move things along. With all the discussions
going on, I thought that it would be useful to not only have rough
consensus, but to be able to say why it was chosen to allow other people
to understand the decisions. 

> * There has been several discussions/questions about GMPLS handling of
> different exception cases. Have that been studied in detail? Is the RSVP
> or CR-LDP currently able to handle these? For example, how should the
> system behave when a signalling channel fail, but the transport link is
> still up? Should we have a single behavior or could the behavior be
> provisionable?
> 
> JD:  What does this have to do with transparency and arbitrary concat?
> There is a section written by Jonathan, which is perpetually not included
> in new revisions of the GMPLS base signalling draft, that describes this.
> 

Nothing with transparency and arbitrary. It was another item that needs
to be considered. Is Jonathan's text available somewhere?

> * There has been some comments about meeting various requirements. Is
> the requirement supposed to come before the protocol is going to last
> call, or it doesn't matter (i.e., we'll change the protocol if it
> doesn't meet requirements), or requirement is irrelevant?
> 
> JD:  As I understand it, we are involved in an iterative process and that
> as operational experience with GMPLS is gained, the protocols may have to
> be updated.
> 

That's fine. But I think in an iterative process, the first step taken
should try to meet certain requirements so that the iteration could be
shorter, or the amount of changes involves could be reduced...

Zhi

Delivery-date: Wed, 30 May 2001 09:33:09 -0700
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: RE: Arbitrary concatenation proposals
Date: Wed, 30 May 2001 09:27:08 -0700

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 5:49 AM
To: John Drake
Cc: 'Mannie, Eric'; [email-masked]; [email-masked];
q11/15; t1x1.5; [email-masked]'; [email-masked]'; Dimitri
Papadimitriou (E-mail)
Subject: Re: Arbitrary concatenation proposals

Hi John,

Yes, the draft you referred to contains both arbitrary as well as
transparency. But you need to look at the context for that ID.

The I-D was submitted as a way to "enhance" the existing codepoints. I
did not try to specify what should or should not belong. And as I said
many times now, I am not requesting that these all be moved. I merely
want to know the metrics for including things.

JD:  So your comments last week ("if an idea stinks, it doesn't matter
how many times some idea is presented, it still stinks that many times"
and "if you see a million flies eating feces, would you also eat?" are
to be considered a momentary aberration?   

Whether arbitrary/transparency should remain in GMPLS or as a separate
document again is up to the group, but I still like Rob's suggestion.

JD:  AS I indicated in my notes to Rob, there is precedent to keep the
functions in the draft, marked as non-standard, which was the original
proposal. 

So let me propose that we try to cut this thread short, and see where we
are:

* I've outlined the features of both arbitrary and virtual in an earlier
email (I think it was technical). Any comments? Should we include that
type of comparison in the document?

JD:  I don't care, as long as it is correct.

* Yes, transparency is in the OIF carrier requirements document. So then
again, as I mentioned many times, if our metric is "more than 2
vendor/carrier" or "more than half of vendor/carrier community" or "it
should be included because", then let's include it. But where would it
be included? In the GMPLS or a separate document? Either way, it will be
captured.

JD:  Why do we need to invent a new methodology for deciding whether to
include transparency and arbitrary concat?  The existing methodology
which is, as I understand it, rough consensus, should be sufficient.

* There has been several discussions/questions about GMPLS handling of
different exception cases. Have that been studied in detail? Is the RSVP
or CR-LDP currently able to handle these? For example, how should the
system behave when a signalling channel fail, but the transport link is
still up? Should we have a single behavior or could the behavior be
provisionable?

JD:  What does this have to do with transparency and arbitrary concat?
There is a section written by Jonathan, which is perpetually not included
in new revisions of the GMPLS base signalling draft, that describes this.

* There has been some comments about meeting various requirements. Is
the requirement supposed to come before the protocol is going to last
call, or it doesn't matter (i.e., we'll change the protocol if it
doesn't meet requirements), or requirement is irrelevant?

JD:  As I understand it, we are involved in an iterative process and that
as operational experience with GMPLS is gained, the protocols may have to
be updated.  

Zhi

John Drake wrote:
> 
> This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
> heart
> regarding tranparency and arbitrary concatenation?
> 
> I.e., just last week Zhi-Wei Lin was using the phrases "if an idea stinks,
> it doesn't
> matter how many times some idea is presented, it still stinks that many
> times" and
> "if you see a million flies eating feces, would you also eat?" to describe
> them.
> 
> Certainly, he didn't feel that way when he included them in his draft?
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 2:33 PM
> To: [email-masked]; [email-masked]; q11/15; t1x1.5
> Cc: [email-masked]'; [email-masked]'; Dimitri Papadimitriou
> (E-mail)
> Subject: Arbitrary concatenation proposals
> 
> Dear All,
> 
> About the industry support for *arbitrary* concatenation, *transparency*
and
> *AUG-X, TUG-X, VTG*, I would like to recommend the reading of the
following
> draft that was presented at the last IETF meeting:
> 
>
http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
> est-00.txt
> 
>       "Common Label and Label Request Specification
>         for Automatic Switched Transport Network"
> 
> Abstract: "This draft completes the [GMPLS-REORG] draft and details
> technology specific issues. It proposes different approach and enhancement
> to [GMPLS-SIG] and [GMPLS-SIGEN]...."
> 
> In this draft the authors proposed signal types that combine the coding of
> the type of signal itself (including AUG-X, TUG-X and VTG), plus
> transparency, plus arbitrary concatenation, etc.
> 
> I would like to know if their products support arbitrary concatenation,
> AUG-X, TUG-X, etc ?
> 
> The authors (all from the same company) requested to incorporate their
> proposal for arbitrary concatenation, transparency, and the "group type"
of
> signals into GMPLS. During this meeting, the authors were strongly
convinced
> that their proposal should have been merged within GMPLS. This was also
> extensively discussed by e-mails.
> 
> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just want
> >us to be clear...no more, no less....
> 
> Well, I hope this helps, at least this vendor considered these features
> sufficiently important to write a draft of 16 pages, to present it and to
> defend it.
> 
> Of course, Errera Humanum Est (or something like that :-)
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]

Delivery-date: Wed, 30 May 2001 07:51:46 -0700
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Rob Coltun' <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 30 May 2001 07:45:22 -0700

I didn't say that, and I don't think that it is true.

It is my understanding that if there was a set of SONET/SDH pipes between a
pair of GMPLS nodes across a non-GMPLS cloud, then the GMPLS nodes could use
those pipes however they wished as long as they were consistent with
SONET/SDH
transport protocols and the non-GMPLS nodes wouldn't need to understand what
they were doing.

I think that this is exactly the same situation as virtual concatenation,
where
the endpoints are upgraded without disturbing the intermediate equipment.  

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 7:32 AM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

Yes I agree. As long as the GMPLS nodes are consistent with the
non-GMPLS cloud, then there is no interop issue. 

As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
would also need to support this. Then it not only impacts new equipment,
but also require upgrades to embedded equipment as well for this to
work?

Zhi

John Drake wrote:
> 
> Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> interacting with the GMPLS
> nodes wrt signalling.  This means that the links between the GMPLS nodes
at
> the edges of the non-GMPLS cloud
> are pre-configured SONET/SDH pipes.  This also means that as long as what
> the GMPLS nodes are doing
> with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> arbitrary concat, then there
> is no interoperability issue.
> 
> I think that this is the point that Eric has been making, which has tended
> to get lost in the noise.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for
OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the
capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't
require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes,
it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the
scope
> > of the IETF to define - so this keeps us more in line with (in this
case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important
to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the
current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Wed, 30 May 2001 07:38:07 -0700
Date: Wed, 30 May 2001 10:32:26 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Rob Coltun'" <[email-masked]>, [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

Yes I agree. As long as the GMPLS nodes are consistent with the
non-GMPLS cloud, then there is no interop issue. 

As you said, to support arbitrary concat, the SONET/SDH non-GMPLS cloud
would also need to support this. Then it not only impacts new equipment,
but also require upgrades to embedded equipment as well for this to
work?

Zhi

John Drake wrote:
> 
> Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
> interacting with the GMPLS
> nodes wrt signalling.  This means that the links between the GMPLS nodes at
> the edges of the non-GMPLS cloud
> are pre-configured SONET/SDH pipes.  This also means that as long as what
> the GMPLS nodes are doing
> with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
> arbitrary concat, then there
> is no interoperability issue.
> 
> I think that this is the point that Eric has been making, which has tended
> to get lost in the noise.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 AM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes, it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the scope
> > of the IETF to define - so this keeps us more in line with (in this case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Wed, 30 May 2001 07:26:06 -0700
From: Dimitrios Pendarakis <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Fong Liaw'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>
Cc: "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Last call - RSVP problems
Date: Wed, 30 May 2001 10:24:11 -0400

Jonathan,

Could you please clarify why you think RSVP Hello doesn't work for 
parallel (redundant) control channels? Control channel redundancy 
is obviously important; however I don't think it relates to the 
usefulness of the RSVP hello mechanism, at least in the context of 
this discussion.

The whole issue is one of layering: LMP hello allows you to detect 
individual link (or control channel) failures; RSVP Hello allows
you to detect that you 've lost contact with your signaling peer
for whatever reason (failure of all redundant control channels, 
failure of the RSVP daemon, etc.). Since they operate at different
levels they are to some extend complementary; once RSVP Hello tells
you that your peer is not reachable, you could use LMP Hello's to 
try to pinpoint where the problem occurred. 

For clarification, the "control channel failure" mentioned in
Fong's mail that started this discussion refers to a failure of the
signaling channel, i.e., inability to communicate with your signaling
peer, not failure of specific (individual) control channels. As such, 
I still believe RSVP Hello is a more accurate detection mechanism.

Please see some additional comments inline.

Thanks,
Dimitris

>   If you're using the RSVP Hello to detect the failure of the 
> RSVP module
> only, then this is fine.  If you're using the RSVP Hello to detect (or
> rather, infer) control channel failures, I have a problem.  
> For starters, I
> don't think it works for parallel (redundant) control 
> channels; if control
> channel redundancy is *not* important for SPs, then it's not 
> as much of an
> issue, however, I think you're overloading the semantics of 
> the RSVP Hello.
> 
>   See additional comments inline.
> 
> Thanks,
> Jonathan
> 
> > 
> > Hi Jonathan,
> > 
> > What needs to be detected here is the inability to send and 
> > receive signaling messages to and from your RSVP peer. In this 
> > respect, using RSVP Hello is a more accurate mechanism for 
> > detecting failures since it is part of the RSVP protocol and 
> > independent of the link layer used to realize the control 
> > channel. As you point out, if you prefer redundant control 
> > channels for resiliency, and want to rely on LMP only, you have
> > to correlate all LMP detected failures in order to declare a 
> > control channel failure.
> This is not correct.  LMP allows you to detect individual 
> control channel
> failures, even when there are multiple (redundant) control 
> channels.  The
> RSVP Hello cannot do this.
> 

Sure, as I pointed above, RSVP Hello is not intended to detect 
individual link failures. At the risk of sounding repetitive, the
point here is that these are different mechanisms that serve 
different purpose. For example, if you have 3 (redundant) IP control 
channels and rely on LMP Hello only, in order to infer failure of the 
signaling channel with your peer, you would have to correlate LMP 
failures in all three channels. 

> > With RSVP Hello you would rely on a 
> > single set of event(s) to detect the failure.
> To be clear, the failure of the RSVP module.

Or simultaneous failure of all IP control channels...

> 
> > To go even further, what if all your control channels are working
> > fine, but your RSVP daemon has crashed, for whatever reason.
> > LMP hellos will keep going across but RSVP messages will not...
> This is where the RSVP Hello has its place.
> 
> > 
> > All this points to the (certainly non-trivial) problem of failure 
> > detection and correlation at different layers. I am not trying to
> > say that RSVP Hello is the perfect or only mechanism we should rely 
> > on, but it certainly has a place in addressing the problem.
> agreed.  see above comment.
> 
> > 
> > Thanks,
> > Dimitris
> > 
> > PS. Hopefully we are not too far apart so we might not have
> > to keep the discussion going for too long :-)
> > In any case I believe it has some relevance here as well.
> > 
> > 
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 6:56 PM
> > > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; 'suresh
> > > Katukam'; [email-masked]
> > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > Subject: RE: Last call - RSVP problems
> > > 
> > > 
> > > Dimitris,
> > >   The RSVP Hello Extension is intended to detect node 
> > failures and not
> > > necessarily link (control channel) failures.  In particular, 
> > > the tunnel
> > > draft says, "It should be noted that node failure detection 
> > > is not the same
> > > as a link failure detection mechanism, particularly in the 
> > > case of multiple
> > > parallel unnumbered links."  What happens if you want 
> > > redundant control
> > > channels for control-channel resiliency?  I believe you would 
> > > still want a
> > > mechanism to detect control channel (link-layer) failures.
> > > 
> > >   In LMP, you can have multiple active control channels 
> > > between a pair of
> > > nodes.  You can configure control channels over shared 
> > > Ethernet and over
> > > SONET/SDH overhead, etc.  You send keep-alive Hellos over 
> > each control
> > > channel.  If you so desire, you can send all signaling 
> > > messages over the
> > > Ethernet control channels.  You can also choose to send all 
> > > remaining LMP
> > > messages over the SONET/SDH-based control channels.  Keeping 
> > > RSVP Hellos as
> > > "optional" would be fine.  Making them mandatory doesn't seem 
> > > like the right
> > > solution.
> > > 
> > > Thanks,
> > > Jonathan
> > > 
> > > P.S.  Should we move this discussion on the OIF list??
> > > 
> > > > -----Original Message-----
> > > > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 3:16 PM
> > > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; 
> > > [email-masked]
> > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > Subject: RE: Last call - RSVP problems
> > > > 
> > > > 
> > > > Hi Jonathan,
> > > > 
> > > > One point to consider is that the signaling control 
> > > > channel might be realized over a different link layer 
> > > > than LMP. For example, LMP might be running in-fiber
> > > > over SONET/SDH overhead bytes, while RSVP is running 
> > > > over an out-of-band network such a shared Ethernet.
> > > > RSVP Hello allows independent detection of signaling 
> > > > channel failure, so it's a useful option to keep.
> > > > 
> > > > Thanks,
> > > > Dimitris
> > > > 
> > > > Dimitris Pendarakis
> > > > Tellium, Inc.
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > > Sent: Friday, May 25, 2001 5:30 PM
> > > > > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > > Subject: RE: Last call - RSVP problems
> > > > > 
> > > > > 
> > > > > Fong,
> > > > > 
> > > > > 
> > > > > <snip>
> > > > > > Same as (2), any proposals that remove the refresh 
> mechanism 
> > > > > > is going to be difficult to prove that all cases 
> are covered.
> > > > > > 
> > > > > > Instead, we (will) recommend the following in OIF UNI 
> > document:
> > > > > >    
> > > > > >    Use RSVP Hello to detect control channel failure.
> > > > > Why wouldn't you use the LMP Hello to detect control channel 
> > > > > failure?  This
> > > > > is exactly what it is designed for.  From 
> > > > > draft-ietf-mpls-lsp-tunnel-08.txt,
> > > > > 
> > > > >   "This (RSVP Hello) mechanism is intended to be used when 
> > > > > notification of
> > > > > link layer
> > > > >    failures is not available and unnumbered links are not 
> > > > > used, or when
> > > > >    the failure detection mechanisms provided by the link 
> > > > layer are not
> > > > >    sufficient for timely node failure detection."
> > > > >  
> > > > > >    If a control channel failure is detected, LSPs states 
> > > > > >    are maintained as if a node continues to receive 
> > > > > >    RSVP refresh message from the failed control channel.
> > > > > >    The recommended Hello timer will be in second range,
> > > > > >    instead of ms range specified in RSVP-TE draft.  
> > > > > > 
> > > > > >    If a control channel failed permanently, manual 
> > intervention 
> > > > > >    may be required. This is to be studied.
> > > > > > 
> > > > > > p.s The text is currently being drafted as we type.
> > > > > 
> > > > 
> > > 
> > 
> 

Delivery-date: Wed, 30 May 2001 07:25:31 -0700
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Rob Coltun' <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 30 May 2001 07:18:55 -0700

Since the non-GMPLS nodes don't understand GMPLS signalling, they are not
interacting with the GMPLS
nodes wrt signalling.  This means that the links between the GMPLS nodes at
the edges of the non-GMPLS cloud
are pre-configured SONET/SDH pipes.  This also means that as long as what
the GMPLS nodes are doing
with those pipes is consistent wrt SONET/SDH transport protocols, e.g.,
arbitrary concat, then there
is no interoperability issue.

I think that this is the point that Eric has been making, which has tended
to get lost in the noise.

Thanks,

John  

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 5:54 AM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

I'm not sure it's all new boxes. Would you consider this scenario valid?

* 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
might go over legacy systems. The no-GMPLS area is simply providing a
"tunnel" between the two GMPLS areas. 

Do we consider such examples?

Zhi

John Drake wrote:
> 
> Rob,
> 
> It was my understanding that that BGP Capabilities and BGP Multiprotocol
> extensions include a set of code points called "vendor-specific".
> 
> For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
> there is the following:
> 
>        Sub-TLV type   Length (octets)  Name
> 
>            250-254                     Reserved for cisco specific
> extensions
> 
> More importantly, what I thought Eric was saying was that the capabilities
> under
> discussion, i.e., transparency and arbitrary concatenation, didn't require
> any
> changes to the SONET/SDH standards.  Rather, it would require changes to
the
> cross-connects between the SONET/SDH spans.  Since these are new boxes, it
> doesn't
> sound like such a big deal.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:20 PM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
> 
> We've said from the beginning that we didn't want to define new "data
plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
> 
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the
industry.
> This standard stuff is certainly not easy.
> 
> Is it really that big an issue to just keep them in a separate RFC?
> 
> thanks,
> ---rob
> 
> John Drake wrote:
> 
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base
TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Wed, 30 May 2001 06:57:01 -0700
Date: Wed, 30 May 2001 09:52:24 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: John Drake <[email-masked]>, "'Rob Coltun'" <[email-masked]>, [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Then I guess this would fall under the "applicability statement" that
limits GMPLS to new deployments only, and will not work in its current
form with legacy systems?

Zhi

"Mannie, Eric" wrote:
> 
> Hello Zhi,
> 
> >* 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> >Do we consider such examples?
> 
> This one possible scenario. GMPLS is not intended to work for the lowest
> common denominator at all. This is a difference with the ITU-T approach in
> transmission where you have to accomodate all possible cases. Some features
> in GMPLS will not make sense for some scenarios, but will make sense in
> other scenarios (generic-general GMPLS). ITU-T made excatly the same with
> plenty of their protocols (e.g. H.323). So you will not proof anything with
> your example, we know that already and this is not an issue.
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 2:54 PM
> To: John Drake
> Cc: 'Rob Coltun'; [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
> 
> I'm not sure it's all new boxes. Would you consider this scenario valid?
> 
> * 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
> might go over legacy systems. The no-GMPLS area is simply providing a
> "tunnel" between the two GMPLS areas.
> 
> Do we consider such examples?
> 
> Zhi
> 
> John Drake wrote:
> >
> > Rob,
> >
> > It was my understanding that that BGP Capabilities and BGP Multiprotocol
> > extensions include a set of code points called "vendor-specific".
> >
> > For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
> > there is the following:
> >
> >        Sub-TLV type   Length (octets)  Name
> >
> >            250-254                     Reserved for cisco specific
> > extensions
> >
> > More importantly, what I thought Eric was saying was that the capabilities
> > under
> > discussion, i.e., transparency and arbitrary concatenation, didn't require
> > any
> > changes to the SONET/SDH standards.  Rather, it would require changes to
> the
> > cross-connects between the SONET/SDH spans.  Since these are new boxes, it
> > doesn't
> > sound like such a big deal.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:20 PM
> > To: John Drake
> > Cc: [email-masked]
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi John,
> >     valid question -  I don't think this is true for BGP. There are
> > extensions
> > to BGP that the working group has adopted.
> > Which TE drafts are you referring to?
> >
> > We've said from the beginning that we didn't want to define new "data
> plane"
> > functionality for technologies where the data plane is being defined
> > elsewhere
> > - whereas some of the functions aren't really new, and in cases might be
> > de-facto standard
> > we recognize that certain "data plane" functionality are beyond the scope
> > of the IETF to define - so this keeps us more in line with (in this case)
> > the ITU.
> >
> > Note that IETF has defined the
> > MPLS data plane - if some other body were to define new functionality
> > for the MPLS data plane it would certainly cause confusion in the
> industry.
> > This standard stuff is certainly not easy.
> >
> > Is it really that big an issue to just keep them in a separate RFC?
> >
> > thanks,
> > ---rob
> >
> > John Drake wrote:
> >
> > > Rob,
> > >
> > > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > > drafts, for example, there are codepoints defined for use by specific,
> > > named, vendors.  I think the same is also true for BGP.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Rob Coltun [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 6:54 PM
> > > To: [email-masked]
> > > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > All,
> > >     despite the heated arguments I think the discussion is important to
> > > have.
> > >
> > > I suggest that instead of  tagging non/pre-standard items in the current
> > > drafts
> > > that they be put into a separate Informational document  - this is the
> > > cleanest thing to do.
> > > We (the IETF) do have a tradition of publishing company proprietary
> > > protocols
> > > but not as standard track documents.
> > >
> > > thanks,
> > > ---rob

Delivery-date: Wed, 30 May 2001 06:48:33 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'George Newsome' <[email-masked]>, Dimitri Papadimitriou <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: RE: [IP-Optical] RE: GMPLS Last Calls
Date: Wed, 30 May 2001 15:47:46 +0200

Hello George,

I think that Dimitri wanted to say that GMPLS is suitable for a large set of
scenarios (not models in your understanding). Anyway, I think that you
understood very well what he wanted to say...

Rgds,

Eric

-----Original Message-----
From: George Newsome [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 3:29 PM
To: Dimitri Papadimitriou
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [IP-Optical] RE: GMPLS Last Calls

Dimitri,

I'm probably just showing my ignorance, but I'm rather curious about
your statement that GMPLS is not based on a model, "Because from the
beginning it is a model independent specification." 

Likewise you state that by defining a profile, GMPLS can be applied at
any interface. Together these statements implies that GMPLS can meet any
model and any set of requirements.

This sounds too good to be true, and I am reminded of the old advice
that when something looks too good to be true, it probably isn't.

Could you clarify what a model independent specification is, and how a
profile can enable any requirements to be covered?

Thanks

	George Newsome

Dimitri Papadimitriou wrote:
> 
> .......................
> We don't taylor a
> protocol suite based on the model to which we have to apply it since
> if the model change - you have to re-design your protocol ! -. Today
> GMPLS can be accomodated to any UNI/NNI interfaces coming from
> wherever you want. Why ? Because from the beginning it is a model
> independent specification ! By defining the profile you desire you
> can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also,
> don't spend to many time at the OIF to define the architecture it is
> already done...
> 
> Thanks,
> - Dimitri.
>

Delivery-date: Wed, 30 May 2001 06:44:10 -0700
Cc: [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Wed, 30 May 2001 15:43:44 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: Transparency at the IETF and OIF

This is a multi-part message in MIME format.
--------------C6DF2FE6632314EE2ACB59D8
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All,

> Extracted from the carrier OIF requirements for the UNI (oif2000.155.1)=
:
> =

>    Multiple levels of transparent services SHALL be supported:
>    =B7    SONET/SDH Line and Section terminating.
>    =B7    SONET/SDH Section terminating with Line transparency.
>    =B7    SONET/SDH with Line and Section transparency.
>    =B7    Non-SONET/SDH transparent bit-streams. [later version]
> =

The above transparency requirements are standardised transparency levels
supported by SDH/SONET and OTN. I.e.

>    =B7    SONET/SDH Line and Section terminating.
This is provided by the SDH/SONET terminal equipment like ADM, DXCs, TMs
and by WDM/OTN equipment. This is describing the capability to transport
transparently a HOVC/STS signal. =

>    =B7    SONET/SDH Section terminating with Line transparency.
This is provided by SDH/SONET repeaters and by WDM equipment including a
SDH/SONET repeater function in its interface ports. This is describing
the capability to transport transparently a MSn signal.

>    =B7    SONET/SDH with Line and Section transparency.
This is provided by WDM and OTN equipment with CBR interfaces (bit
stream transparent). This is describing the capability to transport
transparently a STM-N/OC-N signal.

None of these transparency levels is related to the semi-transparent
STM-N/OC-N feature introduced in GMPLS. This semi-transparency feature
is the one being debated. =

OIF is not requiring the debated semi-transparent STM-N/OC-N feature in
GMPLS.

Regards,

Maarten

"Mannie, Eric" wrote:
> =

> Dear all,
> =

> About the transparency and its importance (especially for the people th=
at
> want to remove it from the standard track, or remove purely and simply =
:-)
> =

> Extracted from the carrier OIF requirements for the UNI (oif2000.155.1)=
:
> =

>    Multiple levels of transparent services SHALL be supported:
>    =B7    SONET/SDH Line and Section terminating.
>    =B7    SONET/SDH Section terminating with Line transparency.
>    =B7    SONET/SDH with Line and Section transparency.
>    =B7    Non-SONET/SDH transparent bit-streams. [later version]
> =

> This document was co-authored by ATT (Monica and John), UUNET, C&W, Wor=
ldCom
> and Deutshe Telekom. I agree with this requirement.
> =

> The document also list all the members of the OIF carrier group: AT&T, =
Cable
> & Wireless, Deutsche Telekom (D-Nova), Enron, GTS, KDD, Korea Telecom, =
NTT,
> Palm, Sita, Sprint, TDK, Telecom Italia, CSELT, UUNET, WorldCom.
> =

> There are 6 BIG carriers telling that they want to be able to control
> transparency at the UNI. Of course it means that they want transparency=
 at
> the NNI because otherwise it doesn't make any sense, the transparency b=
eing
> implemented at the NNI, not the UNI.
> =

> I said many times that transparency is useful at the GMPLS UNI, whateve=
r is
> happening at the NNI. This is exactly the point that make the OIF and t=
he
> carrier group of the OIF.
> =

> So, what I am proposing is to keep the transparency that we have today =
in
> GMPLS for the UNI. This is not related to any transmission plane issue,=

> because it is not implemented at the UNI.
> =

> Transparency is also supported by the OIF UNI by the way. This
> standardization body is considering it as an important feature. I don't=
 see
> any valid reason in that context why we should not have it in GMPLS at =
the
> UNI.
> =

> I am very surprised that people fighting against transparency in GMPLS =
at
> the IETF (UNI as I explained already many times) are indeed co-authors
> and/or work for companies that approved transparency for the OIF UNI.
> =

> Here is the list of manufacturers that approved transparency at the OIF=
 UNI:
> *Lucent*, Nortel, Alcatel, Tenor, Tellium, Callient, Sycamore, Acceligt=
h,
> Ciena, Lucent, Brightwave, Caspian, Nayna, ONI, Cisco, Juniper, Zaffire=
,
> Avici, Laurel, Sorrento, etc.
> =

> To summarize, transparency is:
> =

> 1) requested by at least 6 big carriers.
> 2) requested by at least 20 manufacturers.
> 3) part the OIF UNI (from a standardization body).
> 4) implemented in many products.
> =

> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just wa=
nt
> >us to be clear...no more, no less....
> =

> Is that a good "metric" ?
> =

> I think that we have a rough consensus to keep transparency in the stan=
dard
> track !
> =

> Amazing that nobody reacted against the OIF carriers requirements for t=
he
> UNI, and against the OIF UNI specification... Even more amazing that so=
me
> people have two different languages, one for IETF and one for the OIF !=

> =

> Kind regards,
> =

> Eric
> =

> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> =

> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> =

> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
--------------C6DF2FE6632314EE2ACB59D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------C6DF2FE6632314EE2ACB59D8--

Delivery-date: Wed, 30 May 2001 06:43:27 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Rob Coltun' <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 30 May 2001 15:42:29 +0200

Hello Zhi,

>* 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
might go over legacy systems. The no-GMPLS area is simply providing a
"tunnel" between the two GMPLS areas. 
>Do we consider such examples?

This one possible scenario. GMPLS is not intended to work for the lowest
common denominator at all. This is a difference with the ITU-T approach in
transmission where you have to accomodate all possible cases. Some features
in GMPLS will not make sense for some scenarios, but will make sense in
other scenarios (generic-general GMPLS). ITU-T made excatly the same with
plenty of their protocols (e.g. H.323). So you will not proof anything with
your example, we know that already and this is not an issue.

Rgds,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 2:54 PM
To: John Drake
Cc: 'Rob Coltun'; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

I'm not sure it's all new boxes. Would you consider this scenario valid?

* 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
might go over legacy systems. The no-GMPLS area is simply providing a
"tunnel" between the two GMPLS areas. 

Do we consider such examples?

Zhi

John Drake wrote:
> 
> Rob,
> 
> It was my understanding that that BGP Capabilities and BGP Multiprotocol
> extensions include a set of code points called "vendor-specific".
> 
> For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
> there is the following:
> 
>        Sub-TLV type   Length (octets)  Name
> 
>            250-254                     Reserved for cisco specific
> extensions
> 
> More importantly, what I thought Eric was saying was that the capabilities
> under
> discussion, i.e., transparency and arbitrary concatenation, didn't require
> any
> changes to the SONET/SDH standards.  Rather, it would require changes to
the
> cross-connects between the SONET/SDH spans.  Since these are new boxes, it
> doesn't
> sound like such a big deal.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:20 PM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
> 
> We've said from the beginning that we didn't want to define new "data
plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
> 
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the
industry.
> This standard stuff is certainly not easy.
> 
> Is it really that big an issue to just keep them in a separate RFC?
> 
> thanks,
> ---rob
> 
> John Drake wrote:
> 
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base
TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Wed, 30 May 2001 05:56:12 -0700
Date: Wed, 30 May 2001 08:53:31 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Rob Coltun'" <[email-masked]>, [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,

I'm not sure it's all new boxes. Would you consider this scenario valid?

* 2 GMPLS-enabled areas connected by a non-GMPLS area. In that case, you
might go over legacy systems. The no-GMPLS area is simply providing a
"tunnel" between the two GMPLS areas. 

Do we consider such examples?

Zhi

John Drake wrote:
> 
> Rob,
> 
> It was my understanding that that BGP Capabilities and BGP Multiprotocol
> extensions include a set of code points called "vendor-specific".
> 
> For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
> there is the following:
> 
>        Sub-TLV type   Length (octets)  Name
> 
>            250-254                     Reserved for cisco specific
> extensions
> 
> More importantly, what I thought Eric was saying was that the capabilities
> under
> discussion, i.e., transparency and arbitrary concatenation, didn't require
> any
> changes to the SONET/SDH standards.  Rather, it would require changes to the
> cross-connects between the SONET/SDH spans.  Since these are new boxes, it
> doesn't
> sound like such a big deal.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:20 PM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
> 
> We've said from the beginning that we didn't want to define new "data plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
> 
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the industry.
> This standard stuff is certainly not easy.
> 
> Is it really that big an issue to just keep them in a separate RFC?
> 
> thanks,
> ---rob
> 
> John Drake wrote:
> 
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Wed, 30 May 2001 05:52:44 -0700
Date: Wed, 30 May 2001 08:48:55 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: Re: Arbitrary concatenation proposals

Hi John,

Yes, the draft you referred to contains both arbitrary as well as
transparency. But you need to look at the context for that ID.

The I-D was submitted as a way to "enhance" the existing codepoints. I
did not try to specify what should or should not belong. And as I said
many times now, I am not requesting that these all be moved. I merely
want to know the metrics for including things.

Whether arbitrary/transparency should remain in GMPLS or as a separate
document again is up to the group, but I still like Rob's suggestion.

So let me propose that we try to cut this thread short, and see where we
are:

* I've outlined the features of both arbitrary and virtual in an earlier
email (I think it was technical). Any comments? Should we include that
type of comparison in the document?

* Yes, transparency is in the OIF carrier requirements document. So then
again, as I mentioned many times, if our metric is "more than 2
vendor/carrier" or "more than half of vendor/carrier community" or "it
should be included because", then let's include it. But where would it
be included? In the GMPLS or a separate document? Either way, it will be
captured.

* There has been several discussions/questions about GMPLS handling of
different exception cases. Have that been studied in detail? Is the RSVP
or CR-LDP currently able to handle these? For example, how should the
system behave when a signalling channel fail, but the transport link is
still up? Should we have a single behavior or could the behavior be
provisionable?

* There has been some comments about meeting various requirements. Is
the requirement supposed to come before the protocol is going to last
call, or it doesn't matter (i.e., we'll change the protocol if it
doesn't meet requirements), or requirement is irrelevant?

Zhi

John Drake wrote:
> 
> This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
> heart
> regarding tranparency and arbitrary concatenation?
> 
> I.e., just last week Zhi-Wei Lin was using the phrases "if an idea stinks,
> it doesn't
> matter how many times some idea is presented, it still stinks that many
> times" and
> "if you see a million flies eating feces, would you also eat?" to describe
> them.
> 
> Certainly, he didn't feel that way when he included them in his draft?
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 2:33 PM
> To: [email-masked]; [email-masked]; q11/15; t1x1.5
> Cc: [email-masked]'; [email-masked]'; Dimitri Papadimitriou
> (E-mail)
> Subject: Arbitrary concatenation proposals
> 
> Dear All,
> 
> About the industry support for *arbitrary* concatenation, *transparency* and
> *AUG-X, TUG-X, VTG*, I would like to recommend the reading of the following
> draft that was presented at the last IETF meeting:
> 
> http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
> est-00.txt
> 
>       "Common Label and Label Request Specification
>         for Automatic Switched Transport Network"
> 
> Abstract: "This draft completes the [GMPLS-REORG] draft and details
> technology specific issues. It proposes different approach and enhancement
> to [GMPLS-SIG] and [GMPLS-SIGEN]...."
> 
> In this draft the authors proposed signal types that combine the coding of
> the type of signal itself (including AUG-X, TUG-X and VTG), plus
> transparency, plus arbitrary concatenation, etc.
> 
> I would like to know if their products support arbitrary concatenation,
> AUG-X, TUG-X, etc ?
> 
> The authors (all from the same company) requested to incorporate their
> proposal for arbitrary concatenation, transparency, and the "group type" of
> signals into GMPLS. During this meeting, the authors were strongly convinced
> that their proposal should have been merged within GMPLS. This was also
> extensively discussed by e-mails.
> 
> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just want
> >us to be clear...no more, no less....
> 
> Well, I hope this helps, at least this vendor considered these features
> sufficiently important to write a draft of 16 pages, to present it and to
> defend it.
> 
> Of course, Errera Humanum Est (or something like that :-)
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 23:16:00 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Wed, 30 May 2001 07:09:47 +0100

Hi Vishal, I was referring to the mails sent out by Bert Wijnen recently
(around 13 May) asking for SP voluteers to for a design team on
'hierarchy/survivability'.

Since this is the fist time a set of operators has been specifically
requested to form such a team, I would make the following observations:
-	as you also pointed out in a recent mail, I see the only capacity in
which DT members can operate sensibly is as company representatives (not
individuals)....this seems a significant change in IETF modus operandi;
-	the 1st task in my view of any such operator team is to make sure
that operator requirements are being addressed....'hierarchy' and
'survivability' are very broad headings.  One can try and constrain the
scope *assuming* one has agreement on fundamental architecture.......but
much of the recent Email activity would suggest to me that this is not the
case.  It would therefore seem eminently sensible IMO to ask the DT to
identify the big issues for them and prioritise work accordingly.  Any
proferred solutions (to any issue) without agreed customer/user requirements
would not seem sensible to me.

I am still waiting to see what has happened with forming this team.

Neil

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: 29 May 2001 22:55
> To: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> 
> 
> Hi Neil,
> 
> Actually, I am not sure which operator design team has been 
> referred to in some
> of the latest emails on this list. Maybe I missed something, 
> but I wasn't aware
> that there was going to be an operators design team for GMPLS.
> 
> My understanding was that there would be a couple design 
> teams in the TE
> WG to nail down some requirements documents, but those did not seem
> related to the current discussions.
> 
> Please elucidate if I missed something.
> 
> Thanks,
> -Vishal
> 
> On Tuesday, May 29, 2001 1:24 PM, [email-masked] 
> [SMTP:[email-masked]] wrote:
> > Hi Vishal.....I am waiting to hear what is happening with 
> the operator
> > 'design team'.  It seems to me that their 1st task ought to 
> be to create an
> > agreed set of requirements.
> >
> > neil
> >
> > > -----Original Message-----
> > > From: Vishal Sharma [mailto:[email-masked]]
> > > Sent: 29 May 2001 20:57
> > > To: 'Debanjan Saha'; 'Mannie, Eric'; 'Lazer, Monica A, NNAD';
> > > 'Bernstein, Greg'; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> > >
> > >
> > > Debanjan,
> > >
> > > Excellent idea! I think this is what I had also proposed a
> > > few days ago,
> > > when Eve had first provided a reference to the BT document.
> > > However, I think it would be really helpful (now, and in the
> > > future) to
> > > have all the carrier requirements articulated in one place.
> > >
> > > That would not only allow us to keep track of the various 
> issues, but
> > > also eliminate redundant ones (so that duplication does 
> not needlessly
> > > crowd the field and our discussions), prioritize the issues,
> > > and start
> > > addressing
> > > them one-by-one in a systematic manner, beginning with the
> > > most relevant
> > > or most substantive ones.
> > >
> > > Thanks,
> > >
> > > -Vishal
> > >
> > > On Tuesday, May 29, 2001 11:59 AM, Debanjan Saha
> > > [SMTP:[email-masked]]
> > > wrote:
> > > > Monica,
> > > > As Eric said, it's very difficult to keep track of all
> > > > the questions that have been asked. Would someone (possibly
> > > > you :-)) put them together in one list so that we all can
> > > > discuss them in a more coordinated way. Thanks in advance,
> > > > Debanjan
> > > >
> > > > -----Original Message-----
> > > > From: Mannie, Eric [mailto:[email-masked]]
> > > > Sent: Tuesday, May 29, 2001 1:20 PM
> > > > To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; 
> [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: [IP-Optical] RE: Proposed text for the 
> concatenation
> > > >
> > > >
> > > > > The text does not look good
> > > >
> > > > Monica, I didn't sent the same e-mail and text again, 
> apparently one
> > > > exploder is re-sending old e-mails, you read the text that
> > > was send last
> > > > week :-)
> > > >
> > > > Anyway, it should be time for everybody to calm down 
> and to behave.
> > > >
> > > > Eric
> > > >
> > > > -----Original Message-----
> > > > From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> > > > Sent: Tuesday, May 29, 2001 5:46 PM
> > > > To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: [IP-Optical] RE: Proposed text for the 
> concatenation
> > > >
> > > >
> > > > Eric,
> > > > The text does not look good. Many have expressed concerns
> > > about having
> > > > support for arbitrary concatenation show as if it is a
> > > standard transport
> > > > feature.
> > > > I am flabbergasted by the fact that many comments, which
> > > expressed the same
> > > > or similar concerns from many companies, have simply 
> been ignored.
> > > > Below are comments that   I sent out. They were not
> > > addressed or replied to.
> > > > So I assumed that there were no objections. I now see 
> that they were
> > > > ignored.
> > > >
> > > > Eric,
> > > > Below I have some additional specific comments for the
> > > document GMPLS
> > > > Extensions for SONET and SDH Control
> > > >
> > > >
> > > > CCT field (3 bits)
> > > > Since arbitrary contiguous concatenation is not a standard
> > > concatenation, it
> > > > falls within the vendor proprietary set of solutions.
> > > >
> > > > So the CCT bits may be used as follows:
> > > > 000	No contiguous concatenation requested
> > > > 001	Standard contiguous concatenation
> > > > others	Vendor specific contiguous concatenation
> > > >
> > > > Alternatively, a better solution is to use only 2 bits for
> > > this field and
> > > > use one bit to show whether contiguous concatenation is
> > > requested and the
> > > > second bit to show whether it is standard or 
> non-standard contiguous
> > > > concatenation.
> > > >
> > > >
> > > > NCC field (16 bits)
> > > > This information is not sufficient.
> > > > NCC needs better description than a zero or non-zero number.
> > > >
> > > > SDH and SONET Labels
> > > >
> > > > Text in this section (Section 3, paragraphs 5 and 6)
> > > indicates that the
> > > > GMPLS proposal limits virtual concatenation to remain
> > > within a single
> > > > (component) link. If I understand this correctly, it means
> > > that GMPLS will
> > > > not allow inverse multiplexing (virtual concatenation) in
> > > the transport
> > > > plane if it requires different component links. This is too
> > > limiting.
> > > >
> > > > Annex 1 (sent out by Eric Mannie on 5/22)
> > > > Defines another type of concatenation - Flexible arbitrary
> > > contiguous
> > > > concatenation without describing precisely how it affects
> > > the OH bits. This
> > > > means that it will be impossible to have this type of
> > > concatenation in a
> > > > multi vendor environment based only on the GMPLS signaling.
> > > If the transport
> > > > plane is proprietary, having the option in the signaling
> > > message will not
> > > > fix the interoperability problem between two different
> > > vendors supporting
> > > > their proprietary versions of arbitrary concatenation.
> > > >
> > > > Annex 2 (sent out by Eric Mannie on 5/22)
> > > > Arbitrary contiguous concatenation needs definition work for
> > > > interoperability.
> > > > Flexible arbitrary contiguous concatenation may be
> > > available today to
> > > > support contiguous signals, but it is not defined in the
> > > current standards.
> > > > Clear agreements on OH usage are needed between 
> supporting vendors.
> > > > Maintenance and tracking of the signal needs to be well 
> understood.
> > > >
> > > >
> > > >
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > [email-masked]
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Bernstein, Greg [mailto:[email-masked]]
> > > > Sent: Monday, May 21, 2001 11:21 PM
> > > > To: Mannie, Eric; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: [IP-Optical] RE: Proposed text for the concatenation
> > > >
> > > > The text looks good Eric.  I'm happy to help with any text
> > > to make the
> > > > definition of arbitrary flexible concatenation clearer.
> > > >
> > > > Greg B.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Mannie, Eric [mailto:[email-masked]]
> > > > Sent: Friday, May 18, 2001 1:28 PM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Proposed text for the concatenation
> > > >
> > > >
> > > > Dear All,
> > > >
> > > > I am pleased to see so many people discussing so much on
> > > these mailing
> > > > lists, but now as an editor of
> > > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > > would like to make some progress.
> > > >
> > > > Please, carefully read the following text that clarifies
> > > the contiguous
> > > > concatenation part of the draft and that introduces one 
> simple new
> > > > concatenation type.
> > > >
> > > > "This field indicates the type of SONET/SDH contiguous
> > > concatenation to
> > > > apply on the Elementary Signal. It is set to zero to
> > > indicate that no
> > > > contiguous concatenation is requested (default value). The
> > > values are
> > > > defined in the following table:
> > > >
> > > >        Bits   Contiguous Concatenation Type
> > > >       -----   ----------------------------------
> > > >        000     No contiguous concatenation requested
> > > >        001     Standard contiguous concatenation
> > > >        010     Arbitrary contiguous concatenation
> > > >        011     Flexible arbitrary contiguous concatenation
> > > >       others   Vendor specific concatenation types
> > > >
> > > > Standard contiguous concatenation refers to the contiguous
> > > concatenation as
> > > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > > contiguous
> > > > concatenation relaxes the limitations of these standards in
> > > terms of the
> > > > location where a contiguous signal can start, and in terms
> > > of the number of
> > > > concatenated VC's/SPE's that can compose this signal.
> > > >
> > > > Flexible arbitrary contiguous concatenation is an
> > > optimisation of the
> > > > arbitrary contiguous concatenation that allows to "inverse
> > > multiplex" a
> > > > contiguously concatenated signal on a per multiplex
> > > section/line basis. In
> > > > order to be effectively used, an upstream node must
> > > indicate that its
> > > > supports this feature to its immediate downstream node,
> > > using the CCT field.
> > > > The downstream node can in that case use that feature and
> > > return a list of
> > > > labels, one for each element of the "inverse multiplex";
> > > instead of one
> > > > single label indicating the beginning of the contiguous signal.
> > > >
> > > > This is not a definition. For this to have any value as a
> > > standard document,
> > > > it needs to be submitted to appropriate tranport plane
> > > standards bodies.
> > > > This is support for proprietary solutions. Not more, not less.
> > > >
> > > > The three types of contiguous concatenation defined here
> > > before defines
> > > > indeed a hierarchy of flexibility in the contiguous
> > > concatenation. If
> > > > selected, the flexible arbitrary contiguous concatenation,
> > > indicates that
> > > > any of the three types of contiguous concatenation can be
> > > chosen by the
> > > > downstream node. It is up to the downstream node to choose
> > > the one that it
> > > > wants to use. The upstream node, when receiving the 
> labels from the
> > > > downstream node, may accept or refuse what was proposed."
> > > >
> > > > Please send me your technical comments about the technical
> > > correctness of
> > > > this text only. Please, delay discussions about the
> > > usefulness of these
> > > > features and the way to implement them to another time.
> > > What is important is
> > > > that each feature works. Your profile, implementation, or
> > > configuration
> > > > should determine what you like and what you want to
> > > support, not this
> > > > signalling.
> > > >
> > > > Take your time to read the text and to answer, it is 10PM
> > > in my time zone
> > > > and I will leave my office. I'll be back on Monday morning
> > > to read your
> > > > answers.
> > > >
> > > > Many thanks to all of you and have a nice week-end.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > Eric Mannie
> > > > Technology & Standards Strategy Manager
> > > > Network Engineering Strategy
> > > > EBONE
> > > >
> > > > Terhulpsesteenweg 6A
> > > > 1560 Hoeilaart - Belgium
> > > >
> > > > Tel:    +32 2 658 56 52
> > > > Mobile: +32 496 58 56 52
> > > > Fax:    +32 2 658 51 18
> > > > E-mail: [email-masked]
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > 
> 

Delivery-date: Tue, 29 May 2001 18:03:28 -0700
From: John Drake <[email-masked]>
To: 'Eve Varma' <[email-masked]>, John Drake <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: RE: Arbitrary concatenation proposals
Date: Tue, 29 May 2001 17:56:55 -0700

Oh now

-----Original Message-----
From: Eve Varma [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:54 PM
To: John Drake
Cc: 'Mannie, Eric'; [email-masked]; [email-masked];
q11/15; t1x1.5; [email-masked]'; [email-masked]'; Dimitri
Papadimitriou (E-mail)
Subject: Re: Arbitrary concatenation proposals

Why don't you ask one of the authors of the draft directly?  

                       Eve

John Drake wrote:
> 
> This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
> heart
> regarding tranparency and arbitrary concatenation?
> 
> I.e., just last week Zhi-Wei Lin was using the phrases "if an idea stinks,
> it doesn't
> matter how many times some idea is presented, it still stinks that many
> times" and
> "if you see a million flies eating feces, would you also eat?" to describe
> them.
> 
> Certainly, he didn't feel that way when he included them in his draft?
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 2:33 PM
> To: [email-masked]; [email-masked]; q11/15; t1x1.5
> Cc: [email-masked]'; [email-masked]'; Dimitri Papadimitriou
> (E-mail)
> Subject: Arbitrary concatenation proposals
> 
> Dear All,
> 
> About the industry support for *arbitrary* concatenation, *transparency*
and
> *AUG-X, TUG-X, VTG*, I would like to recommend the reading of the
following
> draft that was presented at the last IETF meeting:
> 
>
http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
> est-00.txt
> 
>       "Common Label and Label Request Specification
>         for Automatic Switched Transport Network"
> 
> Abstract: "This draft completes the [GMPLS-REORG] draft and details
> technology specific issues. It proposes different approach and enhancement
> to [GMPLS-SIG] and [GMPLS-SIGEN]...."
> 
> In this draft the authors proposed signal types that combine the coding of
> the type of signal itself (including AUG-X, TUG-X and VTG), plus
> transparency, plus arbitrary concatenation, etc.
> 
> I would like to know if their products support arbitrary concatenation,
> AUG-X, TUG-X, etc ?
> 
> The authors (all from the same company) requested to incorporate their
> proposal for arbitrary concatenation, transparency, and the "group type"
of
> signals into GMPLS. During this meeting, the authors were strongly
convinced
> that their proposal should have been merged within GMPLS. This was also
> extensively discussed by e-mails.
> 
> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just want
> >us to be clear...no more, no less....
> 
> Well, I hope this helps, at least this vendor considered these features
> sufficiently important to write a draft of 16 pages, to present it and to
> defend it.
> 
> Of course, Errera Humanum Est (or something like that :-)
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 17:35:15 -0700
From: John Drake <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: RE: Arbitrary concatenation proposals
Date: Tue, 29 May 2001 17:28:48 -0700

This is really odd.  Perhaps Eve would enlighten us on Lucent's change of
heart
regarding tranparency and arbitrary concatenation?  

I.e., just last week Zhi-Wei Lin was using the phrases "if an idea stinks,
it doesn't
matter how many times some idea is presented, it still stinks that many
times" and 
"if you see a million flies eating feces, would you also eat?" to describe
them.  

Certainly, he didn't feel that way when he included them in his draft?

Thanks,

John
-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 2:33 PM
To: [email-masked]; [email-masked]; q11/15; t1x1.5
Cc: [email-masked]'; [email-masked]'; Dimitri Papadimitriou
(E-mail)
Subject: Arbitrary concatenation proposals

Dear All,

About the industry support for *arbitrary* concatenation, *transparency* and
*AUG-X, TUG-X, VTG*, I would like to recommend the reading of the following
draft that was presented at the last IETF meeting:

http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
est-00.txt

      "Common Label and Label Request Specification
        for Automatic Switched Transport Network"

Abstract: "This draft completes the [GMPLS-REORG] draft and details
technology specific issues. It proposes different approach and enhancement
to [GMPLS-SIG] and [GMPLS-SIGEN]...."

In this draft the authors proposed signal types that combine the coding of
the type of signal itself (including AUG-X, TUG-X and VTG), plus
transparency, plus arbitrary concatenation, etc.

I would like to know if their products support arbitrary concatenation,
AUG-X, TUG-X, etc ?

The authors (all from the same company) requested to incorporate their
proposal for arbitrary concatenation, transparency, and the "group type" of
signals into GMPLS. During this meeting, the authors were strongly convinced
that their proposal should have been merged within GMPLS. This was also
extensively discussed by e-mails.

>Again, in terms of metrics, what is considered "interesting for the
>industry"? By the vendor community or the carrier community? I just want
>us to be clear...no more, no less....

Well, I hope this helps, at least this vendor considered these features
sufficiently important to write a draft of 16 pages, to present it and to
defend it.

Of course, Errera Humanum Est (or something like that :-)

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 17:25:42 -0700
From: John Drake <[email-masked]>
To: 'Rob Coltun' <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 17:18:50 -0700

Rob,

It was my understanding that that BGP Capabilities and BGP Multiprotocol
extensions include a set of code points called "vendor-specific".

For TE, draft-ietf-isis-traffic-02.txt (and presumably the same for OSPF),
there is the following: 

       Sub-TLV type   Length (octets)  Name

           250-254                     Reserved for cisco specific
extensions

More importantly, what I thought Eric was saying was that the capabilities
under
discussion, i.e., transparency and arbitrary concatenation, didn't require
any
changes to the SONET/SDH standards.  Rather, it would require changes to the
cross-connects between the SONET/SDH spans.  Since these are new boxes, it
doesn't
sound like such a big deal.

Thanks,

John
-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Friday, May 25, 2001 4:20 PM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 17:04:41 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, 'Bala Rajagopalan' <[email-masked]>,  [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 17:03:08 -0700

Hi Maarten, what's your list of proprietary features mine includes:
(1) Extended concatenation types
(2) Semi-transparency feature (all except section and line -- and of course
path)
(3) Path group/AUG-N signal type
Are there others? I'd be happy to remove or include in the specification any
of the above IF we can move forward.  I'm also happy to work with any other
vendors and carriers on interoperability of these non-standard features.  If
some of the folks that attend ITU want to take these forward to ITU or T1
I'd be happy to co-author.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, May 28, 2001 12:48 AM
To: Heiles Juergen
Cc: 'Mannie, Eric'; 'Fong, Man Wing'; Bernstein, Greg; 'Bala
Rajagopalan'; [email-masked]; [email-masked];
t1x1.5; q11/15
Subject: [IP-Optical] Re: Proposed text for the concatenation

All,

Let's treat all GMPLS specifications associated with non-standard
transport plane features as proprietary features, and either 
A) remove those from GMPLS, 
B) move those into an informal appendix of GMPLS or 
C) move those into a separate informal GMPLS extension document
addressing GMPLS constructs for non-standard (proprietary) transport
plane features.

In my opinion after all this debate, alternatives A or C seems best.

Regards,

Maarten

> 
> -------- Original Message --------
> Subject: RE: Proposed text for the concatenation
> Date: Wed, 23 May 2001 14:57:22 +0200
> From: Heiles Juergen <[email-masked]>
> To: "'Mannie, Eric'" <[email-masked]>,"'Fong, Man
> Wing'"<[email-masked]>,"'Bernstein, Greg'"
> <[email-masked]>,"'Bala Rajagopalan'" <[email-masked]>
> CC: [email-masked],
> [email-masked],"t1x1.5"<[email-masked]>, q11/15
> <[email-masked]>
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the
> document for any proprietary solution, where will we stop (I want B3
> transparency and I over connection setup for containers (without POH)?
> Do we really want to define the signaling support for single, two, three
> vendor solutions. I would leave this to the vendors. They implemented a
> proprietary transport plane solution so they can also define their
> proprietary control plane solution. If we have a broader interest in the
> feature we should look at the application and consider if it should be
> standardized both for the transport plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and
> has been in use for years), a stand alone control plane doesn't.
> Interworking at the control plane doesn't help much if the transport
> plane doesn't interwork. So it should be a common standardization
> activity both in the control and in the transport plane.
> - If we define something proprietary we need information about the
> feature, we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know
> what implications they have on the transport plane, they might exclude
> each other. That can happen as we focus only on the control plane and
> don't care about the implications at the transport plane. We can
> generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you
> cannot kill a good solution that fits network needs by blocking it from
> a standard. If someone builds it and shows its advantages operators will
> start to ask for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we
> can come form a proprietary  feature to interworking or a standard. And
> don't start to explain how the feature could be implemented. It will
> bring you into more trouble. This is a control plane document, nothing
> more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in
> detail, but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the
> two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not
> real transparency what is needed, it is functional transparency. For
> example for B2. Or for the DCC bytes you might allow byte slips. But
> what implications has this on the DCN? It is easy to define a feature
> for the control plane and don't care about the transport plane
> implications.
> Although you are a strong supporter of transparency, you were very fast
> in dropping the already included B2 transparency. Because it is not a
> straight forward solution? Requires some awkward processing? And some
> people don't understand how it works? That might be also true for other
> features (flexible arbitrary concatenation). So why include one and not
> the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't
> know it exactly, we just guess. Is this a good base to achieve
> interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it
> cannot be part of a AUG/STS group signal type while all other types of
> concatenation can be. If it is supported you might not need a label set.
> A label for the first time slot is enough. The network element detects
> which other belong to the group. So from the currently available
> information it is difficult to tell if the control plane support is
correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although
> with flexible arbitrary contiguous concatenation as both require a label
> set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new
> proposed section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in
> G.783. It should be noted that AUG/TUG are not and were never intended
> to be networking entities. They were introduced as internal signal
> structures in order to better describe the SDH multiplex process.
> VC-11/12/2/3/4, MS and RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the
> underlying VC-N structure. IF you multiplex the signal you still have to
> do pointer processing for the individual VCs. As a AUG/STS group or TUG
> has no overhead of its own, any supervision has to be performed on the
> individual VCs. So what will it buy us ?(ok, ok better not to ask the
> question, some one supports it and has its good reasons to do so as it
> is the case for any of the above features)
> 
> Regards
> 
>         Juergen

Delivery-date: Tue, 29 May 2001 14:53:20 -0700
Date: Tue, 29 May 2001 23:47:28 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Eve Varma <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] RE: GMPLS Last Calls

This is a multi-part message in MIME format.
--------------93BC902C1D9A45DC41894277
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Eve,

I think there is a section dedicated to the UNI within the
GMPLS Architecture document (see section 7. UNI and NNI)... 
please re-read carefully the document it might be useful 
before the OIF NNI conference-call. This is a demonstration 
of my previous statement: "Today GMPLS specification can be 
accomodated to any UNI/NNI interfaces coming from wherever 
you want"

Kind Regards,
Dimitri. 

Eve Varma wrote:
> 
> Hi Dimitri,
> 
>    Sorry, I'm a bit confused by your response. My input is based upon
> looking at the email flying around. I tried to cite some requirements
> from different sources related to the optical control plane that could
> be used for input, as they have started to be discussed on the mailing
> list.  The GMPLS arch document does mention UNI also, so I think the
> input from the documents related to UNI are also relevant.  Re the BT
> document, you'll have to ask the BT authors.
> 
>                                   Eve
> 
> Dimitri Papadimitriou wrote:
> >
> > Hi,
> >
> > In this e-mail you speak about a "Requirements Design Team"
> > do you refer to the NNI OIF project here i guess ?
> >
> > I wouldn't like to (re-)explain here the nice "reception" offered
> > during the San Diego IETF meeting on the BT draft. Moreover, what's
> > sound very strange here is that the author himself didn't present
> > his draft during the last IETF meeting (since there was a -01 version)!
> > Are you serious when you speak about ASON UNI requirements at the
> > IETF ?
> >
> > You speak about GMPLS profiles for the UNI at the OIF, and potentially
> > in the future for ASTN/ASON which are completely independent of the
> > current GMPLS specification (self-consistency). We don't taylor a
> > protocol suite based on the model to which we have to apply it since
> > if the model change - you have to re-design your protocol ! -. Today
> > GMPLS can be accomodated to any UNI/NNI interfaces coming from
> > wherever you want. Why ? Because from the beginning it is a model
> > independent specification ! By defining the profile you desire you
> > can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also,
> > don't spend to many time at the OIF to define the architecture it is
> > already done...
> >
> > Now you mention one question which is under discussion about the
> > correlation between the planes... the good point is that with the
> > current work done at the IETF and OIF a solution will be found.
> > However this does not mean AT ALL that the current GMPLS
> > specifications are not going toward a very good direction. Therefore
> > i don't think we need the additional text as you propose. In fact this
> > is clearly an extended problem of the "restoration" issue already
> > discussed on this mailing list and we already agree upon.
> >
> > Thanks,
> > - Dimitri.
> >
> > Eve Varma wrote:
> > >
> > > Hi all,
> > >
> > > Watching the various emails regarding the GMPLS drafts, I see several
> > > issues being raised related to some concerns that service provider
> > > requirements haven't been sufficiently reflected in the GMPLS signaling
> > > specifications - or at least, not been tested against.  (An initial set
> > > of requirements was provided by BT on
> > > Considerations on the development of an Optical Control Plane -
> > > http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
> > > Monica has mentioned other currently available sources of service
> > > provider requirements as well, such as the Carriers Optical Services
> > > Framework and Associated Requirements for the UNI, developed in the OIF
> > > and submitted to T1 and ITU-T.  Some requirements were also submitted
> > > earlier in the draft Requirements on the ASON UNI -
> > > http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
> > > )
> > >
> > > For example, assuring separation of the control plane from the data
> > > plane continues to arise - the GMPLS architecture document mentions this
> > > separation, but it's not clear how the GMPLS signaling specifications
> > > reflect the implications of this decoupling.  This is best illustrated
> > > in the handling of control plane failures.  In particular, what happens
> > > to established circuit connections if the control plane fails? If the
> > > control plane recovers, how do we sync the connection state?  As an
> > > example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
> > > the reservation state in routers and hosts. RSVP soft state is created
> > > and periodically refreshed by Path and Resv messages. The state is
> > > deleted if no matching refresh messages arrive before the expiration of
> > > a "cleanup timeout" interval." This means that if for whatever reason
> > > control messages are lost, the associated data paths will be released.
> > > Thus there is strong failure correlation between the control plane and
> > > data plane, which is inconsistent with the GMPLS architecture document,
> > > and also results in tearing down optical connections resulting from even
> > > temporary failures in the control plane.
> > >
> > > I also understand the other comments from Hirokazu and Shehzad re
> > > exclusion of NSAP, having been at the last OIF meeting where there was
> > > considerable and spirited discussion of this issue.  The current GMPLS
> > > architecture document specifically excludes NSAP, and from the last OIF
> > > meeting 6 out of 12 operators discussing this issue felt there was some
> > > need to support NSAP addressing.
> > >
> > > Given that the Requirements Design Team will be starting shortly, I
> > > concur with Yuri's suggestion for inclusion of a clear statement of what
> > > is - and isn't - covered in the GMPLS Signaling Description, RSVP
> > > Extensions, LDP Extensions drafts.   A suggestion for such text is
> > > provided below (the intro will need to be tailored to each draft):
> > >
> > > "Overall, the objective of Generalized MPLS is to adapt MPLS signaling
> > > and other protocols to enable their applicability to various switching
> > > technologies.   A key motivating application has been applicability to
> > > support a distributed control plane for various circuit-switching
> > > technologies.   The signaling specifications contained within the these
> > > drafts offer a starting point towards this goal; their current scope and
> > > applicability, and areas for further assessment, are summarized below:
> > >
> > > These drafts provide some extensions to traditional MPLS signaling and
> > > the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
> > > standard track documents) have not been modified.   It is noted that
> > > MPLS signaling has been designed with a focus upon packet-switched
> > > network based applications, utilizing  requirements and architectural
> > > constructs suitable for such applications.   There may be significant
> > > distinguishing characteristics with regard to requirements and
> > > architectural considerations  for a distributed control plane that
> > > supports circuit-switched network applications.  One well acknowledged
> > > instance involves the decoupling of the control plane from the data
> > > plane.  Such differences may have substantive impact on the signaling
> > > mechanisms, the details of which require further study.  In addition,
> > > upon further study of operational requirements and circuit-switching
> > > technology specific aspects, further signaling extensions may be
> > > required.
> > >
> > > These drafts are focussed upon intra-area signaling interfaces, and do
> > > not address issues and considerations related to other domains of
> > > usage.   Applicability to inter-area and inter-domain interfaces
> > > requires further study."
> > >
> > > Hope this helps us move forward.
> > >
> > > Cheers,
> > >   Eve
> > >
> > > itu
> > >
> > > [email-masked] wrote:
> > > >
> > > > Hi,
> > > >
> > > > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
> > > > drafts.
> > > >
> > > > (1) Decoupling of the control plane from the data plane should be clearly
> > > > stated.
> > > >
> > > > This decoupling clearly has an impact on how the protocols should be defined
> > > > to cope with control plane failures.
> > > >
> > > > (2) Exclusion of NSAP
> > > >
> > > > The GMPLS architecture document, (which logically speaking should perhaps
> > > > have been put forward for last call, ahead of the functional description)
> > > > explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> > > > communications channels (DCC bytes) therefore the use of alternative
> > > > addressing within the same channels may have an adverse effect on
> > > > interworking with legacy equipment, particularly with regard to management.
> > > > This raises the general concern of what level of compatibility is
> > > > required/desired with legacy SDH/SONET equipment.  This debate whilst likely
> > > > to be contentious, is unavoidable as the interworking of control plane,
> > > > management plane and transport will have a direct impact on how this
> > > > equipment is deployed and the economics of whether such deployments will
> > > > ever pay off.
> > > >
> > > > (3) Requirements from both security and OSS has not been discussed fully
> > > > yet.
> > > >
> > > > Security concerns have not been fully addressed, particularly at the
> > > > architectural level.  The use of separate control network may necessitate
> > > > the need for 24 hour staff to protect against 'Denial of Service' attacks as
> > > > currently happens for IP router networks.  The interaction between the
> > > > management plane and control plane need to be addressed, for example it is
> > > > undesirable to have multiple alarms generated when circuits are created and
> > > > torn down otherwise the management of a large scale network will become
> > > > impossible.  Discussions on service aspects need to take place, otherwise
> > > > the adoption of GMPLS equipment may be hampered, by these (solvable)
> > > > concerns.
> > > >
> > > > Best regards
> > > >
> > > > Shehzad Mirza
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Hirokazu Ishimatsu [SMTP:[email-masked]]
> > > > > Sent: 29 May 2001 02:46
> > > > > To:   George Swallow; ccamp; mpls
> > > > > Cc:   ip-optical; tsg15q11; tsg13q10
> > > > > Subject:      [IP-Optical] RE: GMPLS Last Calls
> > > > >
> > > > > Hi,
> > > > >
> > > > > From a carrier's perspective, my concerns about GMPLS signaling drafts
> > > > > are as follows:
> > > > >
> > > > > (1) Decoupling of the control plane from the data plane should be clearly
> > > > >      stated.
> > > > > (2) Exclusion of NSAP
> > > > > (3) Requirements from both security and OSS (Operating Support System)
> > > > >      has not been discussed fully yet.
> > > > >
> > > > > Best regards,
> > > > > Hirokazu Ishimatsu
> > > > > Japan Telecom
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] [mailto:[email-masked]]On
> > > > > > Behalf Of George Swallow
> > > > > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > > > > To: [email-masked]; [email-masked]
> > > > > > Subject: GMPLS Last Calls
> > > > > >
> > > > > >
> > > > > > This message initiates a last call on four GMPLS drafts.  The last
> > > > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > > > >
> > > > > > The drafts are:
> > > > > >
> > > > > >     1.  Generalized MPLS - Signaling Functional Description
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > > > >
> > > > > >
> > > > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > > > >
> > > > > >
> > > > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > > > >
> > > > > >
> > > > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > > > >
> > > > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > > > >
> > > > > >
> > > > > > The last call closes May 29, 12 pm GMT.
> > > > > >
> > > > > >
> > > > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > > > >
> > > > > >
> > > > > > ======================================================================
> > > > > > George Swallow       Cisco Systems                   (978) 244-8143
> > > > > >                      250 Apollo Drive
> > > > > >                      Chelmsford, Ma 01824
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IP-Optical mailing list
> > > > > [email-masked]
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------93BC902C1D9A45DC41894277
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------93BC902C1D9A45DC41894277--

Delivery-date: Tue, 29 May 2001 14:47:01 -0700
Date: Tue, 29 May 2001 16:43:01 -0500
From: Ben Mack-Crane <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
CC: "'Zhi-Wei Lin'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Guangzhi Li'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>
Subject: Re: Transparency at the IETF and OIF

Eric,

I think the debate on transparency indicates that the issue is not as clear
as we might think.  The OIF document you cite defines forms of transparency
that are very straightforward (flags 1,2) not the more complex forms in in 
the current GMPLS drafts (flags 3..10).  Also, these are easily provided in 
O-E-O or O-O-O networks operating at the lambda level, but there is no 
standard for providing these over TDM multiplexed SONET/SDH links.

So you cite broad support, but for what functionality?  If two vendors implement
the same signaling but different TDM multiplexing, that doesn't achieve 
interoperability.  Is there any way in the drafts to determine the scope
of application of the various signaling elements (that is, whether they
apply to UNI or NNI, whether they apply to specific network layers/technologies)?

Regards,
Ben

"Mannie, Eric" wrote:
> 
> Dear all,
> 
> About the transparency and its importance (especially for the people that
> want to remove it from the standard track, or remove purely and simply :-)
> 
> Extracted from the carrier OIF requirements for the UNI (oif2000.155.1):
> 
>    Multiple levels of transparent services SHALL be supported:
>    ·    SONET/SDH Line and Section terminating.
>    ·    SONET/SDH Section terminating with Line transparency.
>    ·    SONET/SDH with Line and Section transparency.
>    ·    Non-SONET/SDH transparent bit-streams. [later version]
> 
> This document was co-authored by ATT (Monica and John), UUNET, C&W, WorldCom
> and Deutshe Telekom. I agree with this requirement.
> 
> The document also list all the members of the OIF carrier group: AT&T, Cable
> & Wireless, Deutsche Telekom (D-Nova), Enron, GTS, KDD, Korea Telecom, NTT,
> Palm, Sita, Sprint, TDK, Telecom Italia, CSELT, UUNET, WorldCom.
> 
> There are 6 BIG carriers telling that they want to be able to control
> transparency at the UNI. Of course it means that they want transparency at
> the NNI because otherwise it doesn't make any sense, the transparency being
> implemented at the NNI, not the UNI.
> 
> I said many times that transparency is useful at the GMPLS UNI, whatever is
> happening at the NNI. This is exactly the point that make the OIF and the
> carrier group of the OIF.
> 
> So, what I am proposing is to keep the transparency that we have today in
> GMPLS for the UNI. This is not related to any transmission plane issue,
> because it is not implemented at the UNI.
> 
> Transparency is also supported by the OIF UNI by the way. This
> standardization body is considering it as an important feature. I don't see
> any valid reason in that context why we should not have it in GMPLS at the
> UNI.
> 
> I am very surprised that people fighting against transparency in GMPLS at
> the IETF (UNI as I explained already many times) are indeed co-authors
> and/or work for companies that approved transparency for the OIF UNI.
> 
> Here is the list of manufacturers that approved transparency at the OIF UNI:
> *Lucent*, Nortel, Alcatel, Tenor, Tellium, Callient, Sycamore, Acceligth,
> Ciena, Lucent, Brightwave, Caspian, Nayna, ONI, Cisco, Juniper, Zaffire,
> Avici, Laurel, Sorrento, etc.
> 
> To summarize, transparency is:
> 
> 1) requested by at least 6 big carriers.
> 2) requested by at least 20 manufacturers.
> 3) part the OIF UNI (from a standardization body).
> 4) implemented in many products.
> 
> >Again, in terms of metrics, what is considered "interesting for the
> >industry"? By the vendor community or the carrier community? I just want
> >us to be clear...no more, no less....
> 
> Is that a good "metric" ?
> 
> I think that we have a rough consensus to keep transparency in the standard
> track !
> 
> Amazing that nobody reacted against the OIF carriers requirements for the
> UNI, and against the OIF UNI specification... Even more amazing that some
> people have two different languages, one for IETF and one for the OIF !
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 14:36:41 -0700
From: "Mannie, Eric" <[email-masked]>
To: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "Dimitri Papadimitriou (E-mail)" <[email-masked]>
Subject: Arbitrary concatenation proposals
Date: Tue, 29 May 2001 23:33:09 +0200

Dear All,

About the industry support for *arbitrary* concatenation, *transparency* and
*AUG-X, TUG-X, VTG*, I would like to recommend the reading of the following
draft that was presented at the last IETF meeting:

http://search.ietf.org/internet-drafts/draft-lin-ccamp-ipo-common-label-requ
est-00.txt

      "Common Label and Label Request Specification
        for Automatic Switched Transport Network"

Abstract: "This draft completes the [GMPLS-REORG] draft and details
technology specific issues. It proposes different approach and enhancement
to [GMPLS-SIG] and [GMPLS-SIGEN]...."

In this draft the authors proposed signal types that combine the coding of
the type of signal itself (including AUG-X, TUG-X and VTG), plus
transparency, plus arbitrary concatenation, etc.

I would like to know if their products support arbitrary concatenation,
AUG-X, TUG-X, etc ?

The authors (all from the same company) requested to incorporate their
proposal for arbitrary concatenation, transparency, and the "group type" of
signals into GMPLS. During this meeting, the authors were strongly convinced
that their proposal should have been merged within GMPLS. This was also
extensively discussed by e-mails.

>Again, in terms of metrics, what is considered "interesting for the
>industry"? By the vendor community or the carrier community? I just want
>us to be clear...no more, no less....

Well, I hope this helps, at least this vendor considered these features
sufficiently important to write a draft of 16 pages, to present it and to
defend it.

Of course, Errera Humanum Est (or something like that :-)

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 14:31:31 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 14:54:52 -0700

Hi Neil,

Actually, I am not sure which operator design team has been referred to in some
of the latest emails on this list. Maybe I missed something, but I wasn't aware
that there was going to be an operators design team for GMPLS.

My understanding was that there would be a couple design teams in the TE
WG to nail down some requirements documents, but those did not seem
related to the current discussions.

Please elucidate if I missed something.

Thanks,
-Vishal

On Tuesday, May 29, 2001 1:24 PM, [email-masked] 
[SMTP:[email-masked]] wrote:
> Hi Vishal.....I am waiting to hear what is happening with the operator
> 'design team'.  It seems to me that their 1st task ought to be to create an
> agreed set of requirements.
>
> neil
>
> > -----Original Message-----
> > From: Vishal Sharma [mailto:[email-masked]]
> > Sent: 29 May 2001 20:57
> > To: 'Debanjan Saha'; 'Mannie, Eric'; 'Lazer, Monica A, NNAD';
> > 'Bernstein, Greg'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> >
> >
> > Debanjan,
> >
> > Excellent idea! I think this is what I had also proposed a
> > few days ago,
> > when Eve had first provided a reference to the BT document.
> > However, I think it would be really helpful (now, and in the
> > future) to
> > have all the carrier requirements articulated in one place.
> >
> > That would not only allow us to keep track of the various issues, but
> > also eliminate redundant ones (so that duplication does not needlessly
> > crowd the field and our discussions), prioritize the issues,
> > and start
> > addressing
> > them one-by-one in a systematic manner, beginning with the
> > most relevant
> > or most substantive ones.
> >
> > Thanks,
> >
> > -Vishal
> >
> > On Tuesday, May 29, 2001 11:59 AM, Debanjan Saha
> > [SMTP:[email-masked]]
> > wrote:
> > > Monica,
> > > As Eric said, it's very difficult to keep track of all
> > > the questions that have been asked. Would someone (possibly
> > > you :-)) put them together in one list so that we all can
> > > discuss them in a more coordinated way. Thanks in advance,
> > > Debanjan
> > >
> > > -----Original Message-----
> > > From: Mannie, Eric [mailto:[email-masked]]
> > > Sent: Tuesday, May 29, 2001 1:20 PM
> > > To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> > >
> > >
> > > > The text does not look good
> > >
> > > Monica, I didn't sent the same e-mail and text again, apparently one
> > > exploder is re-sending old e-mails, you read the text that
> > was send last
> > > week :-)
> > >
> > > Anyway, it should be time for everybody to calm down and to behave.
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> > > Sent: Tuesday, May 29, 2001 5:46 PM
> > > To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> > >
> > >
> > > Eric,
> > > The text does not look good. Many have expressed concerns
> > about having
> > > support for arbitrary concatenation show as if it is a
> > standard transport
> > > feature.
> > > I am flabbergasted by the fact that many comments, which
> > expressed the same
> > > or similar concerns from many companies, have simply been ignored.
> > > Below are comments that   I sent out. They were not
> > addressed or replied to.
> > > So I assumed that there were no objections. I now see that they were
> > > ignored.
> > >
> > > Eric,
> > > Below I have some additional specific comments for the
> > document GMPLS
> > > Extensions for SONET and SDH Control
> > >
> > >
> > > CCT field (3 bits)
> > > Since arbitrary contiguous concatenation is not a standard
> > concatenation, it
> > > falls within the vendor proprietary set of solutions.
> > >
> > > So the CCT bits may be used as follows:
> > > 000	No contiguous concatenation requested
> > > 001	Standard contiguous concatenation
> > > others	Vendor specific contiguous concatenation
> > >
> > > Alternatively, a better solution is to use only 2 bits for
> > this field and
> > > use one bit to show whether contiguous concatenation is
> > requested and the
> > > second bit to show whether it is standard or non-standard contiguous
> > > concatenation.
> > >
> > >
> > > NCC field (16 bits)
> > > This information is not sufficient.
> > > NCC needs better description than a zero or non-zero number.
> > >
> > > SDH and SONET Labels
> > >
> > > Text in this section (Section 3, paragraphs 5 and 6)
> > indicates that the
> > > GMPLS proposal limits virtual concatenation to remain
> > within a single
> > > (component) link. If I understand this correctly, it means
> > that GMPLS will
> > > not allow inverse multiplexing (virtual concatenation) in
> > the transport
> > > plane if it requires different component links. This is too
> > limiting.
> > >
> > > Annex 1 (sent out by Eric Mannie on 5/22)
> > > Defines another type of concatenation - Flexible arbitrary
> > contiguous
> > > concatenation without describing precisely how it affects
> > the OH bits. This
> > > means that it will be impossible to have this type of
> > concatenation in a
> > > multi vendor environment based only on the GMPLS signaling.
> > If the transport
> > > plane is proprietary, having the option in the signaling
> > message will not
> > > fix the interoperability problem between two different
> > vendors supporting
> > > their proprietary versions of arbitrary concatenation.
> > >
> > > Annex 2 (sent out by Eric Mannie on 5/22)
> > > Arbitrary contiguous concatenation needs definition work for
> > > interoperability.
> > > Flexible arbitrary contiguous concatenation may be
> > available today to
> > > support contiguous signals, but it is not defined in the
> > current standards.
> > > Clear agreements on OH usage are needed between supporting vendors.
> > > Maintenance and tracking of the signal needs to be well understood.
> > >
> > >
> > >
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > [email-masked]
> > >
> > >
> > > -----Original Message-----
> > > From: Bernstein, Greg [mailto:[email-masked]]
> > > Sent: Monday, May 21, 2001 11:21 PM
> > > To: Mannie, Eric; [email-masked]
> > > Cc: [email-masked]
> > > Subject: [IP-Optical] RE: Proposed text for the concatenation
> > >
> > > The text looks good Eric.  I'm happy to help with any text
> > to make the
> > > definition of arbitrary flexible concatenation clearer.
> > >
> > > Greg B.
> > >
> > >
> > > -----Original Message-----
> > > From: Mannie, Eric [mailto:[email-masked]]
> > > Sent: Friday, May 18, 2001 1:28 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Proposed text for the concatenation
> > >
> > >
> > > Dear All,
> > >
> > > I am pleased to see so many people discussing so much on
> > these mailing
> > > lists, but now as an editor of
> > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > would like to make some progress.
> > >
> > > Please, carefully read the following text that clarifies
> > the contiguous
> > > concatenation part of the draft and that introduces one simple new
> > > concatenation type.
> > >
> > > "This field indicates the type of SONET/SDH contiguous
> > concatenation to
> > > apply on the Elementary Signal. It is set to zero to
> > indicate that no
> > > contiguous concatenation is requested (default value). The
> > values are
> > > defined in the following table:
> > >
> > >        Bits   Contiguous Concatenation Type
> > >       -----   ----------------------------------
> > >        000     No contiguous concatenation requested
> > >        001     Standard contiguous concatenation
> > >        010     Arbitrary contiguous concatenation
> > >        011     Flexible arbitrary contiguous concatenation
> > >       others   Vendor specific concatenation types
> > >
> > > Standard contiguous concatenation refers to the contiguous
> > concatenation as
> > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > contiguous
> > > concatenation relaxes the limitations of these standards in
> > terms of the
> > > location where a contiguous signal can start, and in terms
> > of the number of
> > > concatenated VC's/SPE's that can compose this signal.
> > >
> > > Flexible arbitrary contiguous concatenation is an
> > optimisation of the
> > > arbitrary contiguous concatenation that allows to "inverse
> > multiplex" a
> > > contiguously concatenated signal on a per multiplex
> > section/line basis. In
> > > order to be effectively used, an upstream node must
> > indicate that its
> > > supports this feature to its immediate downstream node,
> > using the CCT field.
> > > The downstream node can in that case use that feature and
> > return a list of
> > > labels, one for each element of the "inverse multiplex";
> > instead of one
> > > single label indicating the beginning of the contiguous signal.
> > >
> > > This is not a definition. For this to have any value as a
> > standard document,
> > > it needs to be submitted to appropriate tranport plane
> > standards bodies.
> > > This is support for proprietary solutions. Not more, not less.
> > >
> > > The three types of contiguous concatenation defined here
> > before defines
> > > indeed a hierarchy of flexibility in the contiguous
> > concatenation. If
> > > selected, the flexible arbitrary contiguous concatenation,
> > indicates that
> > > any of the three types of contiguous concatenation can be
> > chosen by the
> > > downstream node. It is up to the downstream node to choose
> > the one that it
> > > wants to use. The upstream node, when receiving the labels from the
> > > downstream node, may accept or refuse what was proposed."
> > >
> > > Please send me your technical comments about the technical
> > correctness of
> > > this text only. Please, delay discussions about the
> > usefulness of these
> > > features and the way to implement them to another time.
> > What is important is
> > > that each feature works. Your profile, implementation, or
> > configuration
> > > should determine what you like and what you want to
> > support, not this
> > > signalling.
> > >
> > > Take your time to read the text and to answer, it is 10PM
> > in my time zone
> > > and I will leave my office. I'll be back on Monday morning
> > to read your
> > > answers.
> > >
> > > Many thanks to all of you and have a nice week-end.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > Eric Mannie
> > > Technology & Standards Strategy Manager
> > > Network Engineering Strategy
> > > EBONE
> > >
> > > Terhulpsesteenweg 6A
> > > 1560 Hoeilaart - Belgium
> > >
> > > Tel:    +32 2 658 56 52
> > > Mobile: +32 496 58 56 52
> > > Fax:    +32 2 658 51 18
> > > E-mail: [email-masked]
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > 

Delivery-date: Tue, 29 May 2001 14:25:02 -0700
Date: Tue, 29 May 2001 23:24:07 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Eve Varma <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] RE: GMPLS Last Calls

This is a multi-part message in MIME format.
--------------04BBA6BE70D5D55BD1C0ACA0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eve,

There are today lot of design teams at the TE WG, PPVPN etc.
Do you speak here about the ones being proposed at the TE WG 
on "network survivability" and "hierarchical TE" ? I think
that some additional information would be useful to understand
to which one you refer here.

Thanks,
Dimitri.

Eve Varma wrote:
> 
> Hi Dimitri,
>    Sorry - missed your first question.  I was not referring to an NNI
> OIF team; I was referring to the IETF team being formed.
>                          Eve
> 
> Dimitri Papadimitriou wrote:
> >
> > Hi,
> >
> > In this e-mail you speak about a "Requirements Design Team"
> > do you refer to the NNI OIF project here i guess ?
> >
> > I wouldn't like to (re-)explain here the nice "reception" offered
> > during the San Diego IETF meeting on the BT draft. Moreover, what's
> > sound very strange here is that the author himself didn't present
> > his draft during the last IETF meeting (since there was a -01 version)!
> > Are you serious when you speak about ASON UNI requirements at the
> > IETF ?
> >
> > You speak about GMPLS profiles for the UNI at the OIF, and potentially
> > in the future for ASTN/ASON which are completely independent of the
> > current GMPLS specification (self-consistency). We don't taylor a
> > protocol suite based on the model to which we have to apply it since
> > if the model change - you have to re-design your protocol ! -. Today
> > GMPLS can be accomodated to any UNI/NNI interfaces coming from
> > wherever you want. Why ? Because from the beginning it is a model
> > independent specification ! By defining the profile you desire you
> > can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also,
> > don't spend to many time at the OIF to define the architecture it is
> > already done...
> >
> > Now you mention one question which is under discussion about the
> > correlation between the planes... the good point is that with the
> > current work done at the IETF and OIF a solution will be found.
> > However this does not mean AT ALL that the current GMPLS
> > specifications are not going toward a very good direction. Therefore
> > i don't think we need the additional text as you propose. In fact this
> > is clearly an extended problem of the "restoration" issue already
> > discussed on this mailing list and we already agree upon.
> >
> > Thanks,
> > - Dimitri.
> >
> > Eve Varma wrote:
> > >
> > > Hi all,
> > >
> > > Watching the various emails regarding the GMPLS drafts, I see several
> > > issues being raised related to some concerns that service provider
> > > requirements haven't been sufficiently reflected in the GMPLS signaling
> > > specifications - or at least, not been tested against.  (An initial set
> > > of requirements was provided by BT on
> > > Considerations on the development of an Optical Control Plane -
> > > http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
> > > Monica has mentioned other currently available sources of service
> > > provider requirements as well, such as the Carriers Optical Services
> > > Framework and Associated Requirements for the UNI, developed in the OIF
> > > and submitted to T1 and ITU-T.  Some requirements were also submitted
> > > earlier in the draft Requirements on the ASON UNI -
> > > http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
> > > )
> > >
> > > For example, assuring separation of the control plane from the data
> > > plane continues to arise - the GMPLS architecture document mentions this
> > > separation, but it's not clear how the GMPLS signaling specifications
> > > reflect the implications of this decoupling.  This is best illustrated
> > > in the handling of control plane failures.  In particular, what happens
> > > to established circuit connections if the control plane fails? If the
> > > control plane recovers, how do we sync the connection state?  As an
> > > example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
> > > the reservation state in routers and hosts. RSVP soft state is created
> > > and periodically refreshed by Path and Resv messages. The state is
> > > deleted if no matching refresh messages arrive before the expiration of
> > > a "cleanup timeout" interval." This means that if for whatever reason
> > > control messages are lost, the associated data paths will be released.
> > > Thus there is strong failure correlation between the control plane and
> > > data plane, which is inconsistent with the GMPLS architecture document,
> > > and also results in tearing down optical connections resulting from even
> > > temporary failures in the control plane.
> > >
> > > I also understand the other comments from Hirokazu and Shehzad re
> > > exclusion of NSAP, having been at the last OIF meeting where there was
> > > considerable and spirited discussion of this issue.  The current GMPLS
> > > architecture document specifically excludes NSAP, and from the last OIF
> > > meeting 6 out of 12 operators discussing this issue felt there was some
> > > need to support NSAP addressing.
> > >
> > > Given that the Requirements Design Team will be starting shortly, I
> > > concur with Yuri's suggestion for inclusion of a clear statement of what
> > > is - and isn't - covered in the GMPLS Signaling Description, RSVP
> > > Extensions, LDP Extensions drafts.   A suggestion for such text is
> > > provided below (the intro will need to be tailored to each draft):
> > >
> > > "Overall, the objective of Generalized MPLS is to adapt MPLS signaling
> > > and other protocols to enable their applicability to various switching
> > > technologies.   A key motivating application has been applicability to
> > > support a distributed control plane for various circuit-switching
> > > technologies.   The signaling specifications contained within the these
> > > drafts offer a starting point towards this goal; their current scope and
> > > applicability, and areas for further assessment, are summarized below:
> > >
> > > These drafts provide some extensions to traditional MPLS signaling and
> > > the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
> > > standard track documents) have not been modified.   It is noted that
> > > MPLS signaling has been designed with a focus upon packet-switched
> > > network based applications, utilizing  requirements and architectural
> > > constructs suitable for such applications.   There may be significant
> > > distinguishing characteristics with regard to requirements and
> > > architectural considerations  for a distributed control plane that
> > > supports circuit-switched network applications.  One well acknowledged
> > > instance involves the decoupling of the control plane from the data
> > > plane.  Such differences may have substantive impact on the signaling
> > > mechanisms, the details of which require further study.  In addition,
> > > upon further study of operational requirements and circuit-switching
> > > technology specific aspects, further signaling extensions may be
> > > required.
> > >
> > > These drafts are focussed upon intra-area signaling interfaces, and do
> > > not address issues and considerations related to other domains of
> > > usage.   Applicability to inter-area and inter-domain interfaces
> > > requires further study."
> > >
> > > Hope this helps us move forward.
> > >
> > > Cheers,
> > >   Eve
> > >
> > > itu
> > >
> > > [email-masked] wrote:
> > > >
> > > > Hi,
> > > >
> > > > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
> > > > drafts.
> > > >
> > > > (1) Decoupling of the control plane from the data plane should be clearly
> > > > stated.
> > > >
> > > > This decoupling clearly has an impact on how the protocols should be defined
> > > > to cope with control plane failures.
> > > >
> > > > (2) Exclusion of NSAP
> > > >
> > > > The GMPLS architecture document, (which logically speaking should perhaps
> > > > have been put forward for last call, ahead of the functional description)
> > > > explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> > > > communications channels (DCC bytes) therefore the use of alternative
> > > > addressing within the same channels may have an adverse effect on
> > > > interworking with legacy equipment, particularly with regard to management.
> > > > This raises the general concern of what level of compatibility is
> > > > required/desired with legacy SDH/SONET equipment.  This debate whilst likely
> > > > to be contentious, is unavoidable as the interworking of control plane,
> > > > management plane and transport will have a direct impact on how this
> > > > equipment is deployed and the economics of whether such deployments will
> > > > ever pay off.
> > > >
> > > > (3) Requirements from both security and OSS has not been discussed fully
> > > > yet.
> > > >
> > > > Security concerns have not been fully addressed, particularly at the
> > > > architectural level.  The use of separate control network may necessitate
> > > > the need for 24 hour staff to protect against 'Denial of Service' attacks as
> > > > currently happens for IP router networks.  The interaction between the
> > > > management plane and control plane need to be addressed, for example it is
> > > > undesirable to have multiple alarms generated when circuits are created and
> > > > torn down otherwise the management of a large scale network will become
> > > > impossible.  Discussions on service aspects need to take place, otherwise
> > > > the adoption of GMPLS equipment may be hampered, by these (solvable)
> > > > concerns.
> > > >
> > > > Best regards
> > > >
> > > > Shehzad Mirza
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Hirokazu Ishimatsu [SMTP:[email-masked]]
> > > > > Sent: 29 May 2001 02:46
> > > > > To:   George Swallow; ccamp; mpls
> > > > > Cc:   ip-optical; tsg15q11; tsg13q10
> > > > > Subject:      [IP-Optical] RE: GMPLS Last Calls
> > > > >
> > > > > Hi,
> > > > >
> > > > > From a carrier's perspective, my concerns about GMPLS signaling drafts
> > > > > are as follows:
> > > > >
> > > > > (1) Decoupling of the control plane from the data plane should be clearly
> > > > >      stated.
> > > > > (2) Exclusion of NSAP
> > > > > (3) Requirements from both security and OSS (Operating Support System)
> > > > >      has not been discussed fully yet.
> > > > >
> > > > > Best regards,
> > > > > Hirokazu Ishimatsu
> > > > > Japan Telecom
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked] [mailto:[email-masked]]On
> > > > > > Behalf Of George Swallow
> > > > > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > > > > To: [email-masked]; [email-masked]
> > > > > > Subject: GMPLS Last Calls
> > > > > >
> > > > > >
> > > > > > This message initiates a last call on four GMPLS drafts.  The last
> > > > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > > > >
> > > > > > The drafts are:
> > > > > >
> > > > > >     1.  Generalized MPLS - Signaling Functional Description
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > > > >
> > > > > >
> > > > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > > > >
> > > > > >
> > > > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > > > >
> > > > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > > > >
> > > > > >
> > > > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > > > >
> > > > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > > > >
> > > > > >
> > > > > > The last call closes May 29, 12 pm GMT.
> > > > > >
> > > > > >
> > > > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > > > >
> > > > > >
> > > > > > ======================================================================
> > > > > > George Swallow       Cisco Systems                   (978) 244-8143
> > > > > >                      250 Apollo Drive
> > > > > >                      Chelmsford, Ma 01824
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > IP-Optical mailing list
> > > > > [email-masked]
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------04BBA6BE70D5D55BD1C0ACA0
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------04BBA6BE70D5D55BD1C0ACA0--

Delivery-date: Tue, 29 May 2001 14:24:12 -0700
From: John Drake <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, 'Rob Coltun' <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 14:18:45 -0700

fine with me

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, May 28, 2001 4:06 AM
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 14:12:26 -0700
From: John Drake <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>, "'Tarapore, Percy S'" <[email-masked]>, "'C. R. Kalmanek'" <[email-masked]>,  John Drake <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Tue, 29 May 2001 14:00:55 -0700

fine with me

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Friday, May 25, 2001 2:23 PM
To: 'Tarapore, Percy S'; Bala Rajagopalan; 'C. R. Kalmanek'; John Drake
Cc: [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

This would be fine with me. John? Lou?

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Tarapore, Percy S [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:34 PM
> To: 'Bala Rajagopalan'; 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> 
> Bala,
> 
> Are you suggesting that restoration signaling requirements be 
> formulated in
> a separate GMPLS draft at a later date? If so, the current 
> draft should add
> text regarding the current scope (link protection only) as 
> well as future
> work (restoration) in Section 7.
> 
> Percy
> 
> -----Original Message-----
> From: Bala Rajagopalan [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 1:57 PM
> To: 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> 
> 
> Chuck:
> 
> I believe that the restoration issue can be
> dealt with indepedent of the current drafts
> on last call. Do you see any obstacles to
> adding new objects/semantics (if any) to support
> restoration requirements as they arise?
> 
> BTW, there are some drafts floating around
> on shared mesh.
> 
> regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 1:08 PM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> > 
> > 
> > I fully agree: there are a whole spectrum of options that we
> > need to sort through, and clear requirements are needed to
> > guide that process.  Our concern is with the last call.  It
> > doesn't make sense to progress drafts to RFC that are likely 
> > in hindsight to be viewed as having serious deficiencies in
> > meeting restoration requirements.
> > 
> > chuck
> > 
> > John Drake wrote:
> > > 
> > > The point is that in GMPLS, as in regular MPLS, restoration 
> > consists of
> > > rerouting from the endpoints upon
> > > notification of failure.  There are a whole spectrum of 
> > path and span
> > > protection possibilites beyond this
> > > that people (including us) have proposed, but in the 
> absence of firm
> > > requirements, it's hard to know which
> > > to pursue.  I'm not sure 'shared mesh restoration' 
> > completely covers it.
> > > 
> > > Thanks,
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 9:54 AM
> > > To: John Drake
> > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); 
> [email-masked];
> > > [email-masked]
> > > Subject: Re: GMPLS Last Calls
> > > 
> > > John,
> > > 
> > > While there currently are no restoration requirements from the
> > > TE (or other) group, what Percy is saying is that shared mesh
> > > restoration WILL be a requirement from those groups.  Since the
> > > current GMPLS drafts don't meet this requirement, they are
> > > unlikely to meet key SP needs.
> > > 
> > > I don't understand a process that starts the requirements
> > > development after last call for the signaling specifications.
> > > 
> > > chuck
> > > 
> > > John Drake wrote:
> > > >
> > > > Percy,
> > > >
> > > > There has been work on protocols for path restoration in 
> > mesh networks by
> > > a
> > > > number of
> > > > people.  However, at the last IETF Kireeti and Vijay 
> > clearly indicated
> > > that
> > > > this work,
> > > > while interesting, wouldn't be allowed to progress in 
> advance of a
> > > > restoration requirements
> > > > draft from the TE group.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > > Sent: Thursday, May 24, 2001 11:55 AM
> > > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > There is a significant issue related to the absence of 
> > restoration in the
> > > > signaling draft
> > > >
> > > 
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt). Very specifically, Section 7 of this draft deals 
> > with the case
> > > > involving protection information for link protection. While link
> > > protection
> > > > schemes may be desirable for fast recovery related to 
> > high priority LSP's,
> > > > more cost-effective shared mesh restoration schemes would 
> > be preferred for
> > > > the majority of traffic from a Service Provider's 
> > perspective. This
> > > > observation is supported by the fact that many vendors 
> > are currently
> > > > developing proprietary schemes for shared mesh 
> > restoration. Hence, in
> > > > addition to the protection information, GMPLS signaling 
> > needs to reflect a
> > > > minimum set of information/attributes required for shared 
> > mesh restoration
> > > > without jeopardizing vendor proprietary solutions.
> > > >
> > > > The need for multiple types of restoration capabilities 
> > is well documented
> > > > in the OIF/UNI I-D
> > > >
> > > 
> > http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> > ework-uni-00.t
> > > > xt as follows:
> > > >
> > > > " Multiple types of facilities available for restoration 
> > are needed
> > > >    within the network. The following options should be 
> > considered for
> > > >    allocation of facilities to support restoration of failed
> > > >    connections:
> > > >    - Dedicated restoration capacity
> > > >    - Shared restoration capacity. This allows the network 
> > to ensure
> > > >      high quality service for customers, while still 
> managing its
> > > >      physical resources efficiently.
> > > >    - Un-restorable
> > > >    - Pre-emptable"
> > > >
> > > > The OIF/UNI I-D supports a range of different restoration 
> > schemes through
> > > > the use of service level as a connection attribute. This 
> > attribute is
> > > > defined as follows:
> > > >
> > > > " an integer attribute that indicates a class of service. 
> > A carrier may
> > > > specify a range of different classes of service (e.g. 
> > gold, silver,
> > > bronze)
> > > > with predefined characteristics (e.g. restoration plans). 
> > The pre-defined
> > > > service types correspond to different types of network 
> > restoration (e.g.
> > > no
> > > > restoration, 1+1 protection), connection set-up and hold 
> > priorities,
> > > > reversion strategies for the connection after failures 
> > have been repaired,
> > > > and retention strategies."
> > > >
> > > > It is therefore important that GMPLS be extended to be 
> > able to support
> > > such
> > > > restoration schemes.
> > > >
> > > > Percy S. Tarapore
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: Ash, Gerald R (Jerry)
> > > > Sent: Thursday, May 24, 2001 2:20 PM
> > > > To: [email-masked]; [email-masked]
> > > > Cc: Ash, Gerald R (Jerry)
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > Quoting from the CCAMP/IETF-50 meeting minutes re the 
> > GMPLS Architecture
> > > > draft:
> > > >
> > > > "Eve - Had hoped that CCAMP formation and expression of 
> > requirements would
> > > > enable us to do more with architecture than reverse 
> > architect proposed
> > > > solution. Think we should also look at carrier 
> > requirements and look for
> > > > discrepancies with architecture.
> > > > Curtis - requirements of carriers not being addressed?
> > > > Eve - happy to discuss on mailing list in absence of time"
> > > >
> > > > There are still no documented service provider (SP) 
> > requirements driving
> > > the
> > > > proposed GMPLS protocol extensions.  This is inconsistent 
> > with the current
> > > > initiatives to provide SP requirements prior to protocol 
> > extensions being
> > > > accepted, such as for protection/restoration, network 
> > hierarchy, MPLS OAM,
> > > > MPLS/DiffServ TE, multi-area TE, etc.
> > > >
> > > > Here is a sample of SP requirements that are not being 
> > addressed (other
> > > > requirements from our perspective are forthcoming):
> > > >
> > > > 1. Restoration requirements, particularly in support of 
> > mesh restoration,
> > > > need to be supported by GMPLS.  For example, Section 7 of 
> > the Generalized
> > > > Signaling I-D
> > > >
> > > 
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt)
> > > > primarily discusses link protection, restoration 
> > capabilities are largely
> > > > missing and need to be included.
> > > >
> > > > 2. Standards explicitly supported by GMPLS, such as 
> > G.707, G.709, etc.,
> > > > should be clearly identified in the text and referenced 
> > in the GMPLS I-Ds,
> > > > e.g., in Section 3.1 of the Generalized Signaling I-D, 
> add "G.707
> > > [Reference
> > > > G.707] is supported by the Generalized Label Request."
> > > >
> > > > As per Eve's comment at IETF-50, SPs are encouraged to 
> post their
> > > > requirements to the list.  It would also help if more SPs 
> > were invited to
> > > > co-author the GMPLS drafts, to help ensure that SP 
> > requirements are more
> > > > adequately reflected and addressed.
> > > >
> > > > Jerry Ash
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: George Swallow [mailto:[email-masked]]
> > > > Sent: Monday, May 14, 2001 1:52 PM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: GMPLS Last Calls
> > > >
> > > > This message initiates a last call on four GMPLS 
> drafts.  The last
> > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > >
> > > > The drafts are:
> > > >
> > > >     1.  Generalized MPLS - Signaling Functional Description
> > > >
> > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > >
> > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > >
> > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > >
> > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > >
> > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > >
> > > > The last call closes May 29, 12 pm GMT.
> > > >
> > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > >
> > > > 
> > 
> ======================================================================
> > > > George Swallow       Cisco Systems                   
> > (978) 244-8143
> > > >                      250 Apollo Drive
> > > >                      Chelmsford, Ma 01824
> > 
> 

Delivery-date: Tue, 29 May 2001 14:11:28 -0700
From: Debanjan Saha <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Guangzhi Li'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>
Subject: RE: Transparency at the IETF and OIF
Date: Tue, 29 May 2001 17:08:43 -0400

Eric,
I completely agree with you. I think transparency is a very
important attribute for a lightpath and it should be supported
in GMPLS.
Debanjan

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 3:35 PM
To: 'Zhi-Wei Lin'; [email-masked]'; [email-masked]';
[email-masked]'
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5;
[email-masked]'; [email-masked]'; 'Guangzhi Li'; 'Heiles
Juergen'
Subject: Transparency at the IETF and OIF
Importance: High

Dear all,

About the transparency and its importance (especially for the people =
that
want to remove it from the standard track, or remove purely and simply =
:-)

Extracted from the carrier OIF requirements for the UNI =
(oif2000.155.1):

   Multiple levels of transparent services SHALL be supported:
   =B7	SONET/SDH Line and Section terminating.=20
   =B7	SONET/SDH Section terminating with Line transparency.=20
   =B7	SONET/SDH with Line and Section transparency.=20
   =B7	Non-SONET/SDH transparent bit-streams. [later version]

This document was co-authored by ATT (Monica and John), UUNET, C&W, =
WorldCom
and Deutshe Telekom. I agree with this requirement.

The document also list all the members of the OIF carrier group: AT&T, =
Cable
& Wireless, Deutsche Telekom (D-Nova), Enron, GTS, KDD, Korea Telecom, =
NTT,
Palm, Sita, Sprint, TDK, Telecom Italia, CSELT, UUNET, WorldCom.=09

There are 6 BIG carriers telling that they want to be able to control
transparency at the UNI. Of course it means that they want transparency =
at
the NNI because otherwise it doesn't make any sense, the transparency =
being
implemented at the NNI, not the UNI.

I said many times that transparency is useful at the GMPLS UNI, =
whatever is
happening at the NNI. This is exactly the point that make the OIF and =
the
carrier group of the OIF.

So, what I am proposing is to keep the transparency that we have today =
in
GMPLS for the UNI. This is not related to any transmission plane issue,
because it is not implemented at the UNI.

Transparency is also supported by the OIF UNI by the way. This
standardization body is considering it as an important feature. I don't =
see
any valid reason in that context why we should not have it in GMPLS at =
the
UNI.

I am very surprised that people fighting against transparency in GMPLS =
at
the IETF (UNI as I explained already many times) are indeed co-authors
and/or work for companies that approved transparency for the OIF UNI.

Here is the list of manufacturers that approved transparency at the OIF =
UNI:
*Lucent*, Nortel, Alcatel, Tenor, Tellium, Callient, Sycamore, =
Acceligth,
Ciena, Lucent, Brightwave, Caspian, Nayna, ONI, Cisco, Juniper, =
Zaffire,
Avici, Laurel, Sorrento, etc.

To summarize, transparency is:

1) requested by at least 6 big carriers.
2) requested by at least 20 manufacturers.
3) part the OIF UNI (from a standardization body).
4) implemented in many products.

>Again, in terms of metrics, what is considered "interesting for the
>industry"? By the vendor community or the carrier community? I just =
want
>us to be clear...no more, no less....

Is that a good "metric" ?

I think that we have a rough consensus to keep transparency in the =
standard
track !

Amazing that nobody reacted against the OIF carriers requirements for =
the
UNI, and against the OIF UNI specification... Even more amazing that =
some
people have two different languages, one for IETF and one for the OIF !

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 13:47:26 -0700
Date: Tue, 29 May 2001 22:40:31 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Eve Varma <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] RE: GMPLS Last Calls

This is a multi-part message in MIME format.
--------------076141E8FCA7BD2DE27A0322
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

In this e-mail you speak about a "Requirements Design Team"
do you refer to the NNI OIF project here i guess ? 

I wouldn't like to (re-)explain here the nice "reception" offered
during the San Diego IETF meeting on the BT draft. Moreover, what's 
sound very strange here is that the author himself didn't present 
his draft during the last IETF meeting (since there was a -01 version)! 
Are you serious when you speak about ASON UNI requirements at the 
IETF ?

You speak about GMPLS profiles for the UNI at the OIF, and potentially 
in the future for ASTN/ASON which are completely independent of the 
current GMPLS specification (self-consistency). We don't taylor a 
protocol suite based on the model to which we have to apply it since 
if the model change - you have to re-design your protocol ! -. Today 
GMPLS can be accomodated to any UNI/NNI interfaces coming from
wherever you want. Why ? Because from the beginning it is a model 
independent specification ! By defining the profile you desire you
can apply it to the OIF UNI / ASON UNI (if still needed) / etc. Also, 
don't spend to many time at the OIF to define the architecture it is 
already done...

Now you mention one question which is under discussion about the 
correlation between the planes... the good point is that with the
current work done at the IETF and OIF a solution will be found.
However this does not mean AT ALL that the current GMPLS 
specifications are not going toward a very good direction. Therefore 
i don't think we need the additional text as you propose. In fact this
is clearly an extended problem of the "restoration" issue already 
discussed on this mailing list and we already agree upon.

Thanks,
- Dimitri. 

Eve Varma wrote:
> 
> Hi all,
> 
> Watching the various emails regarding the GMPLS drafts, I see several
> issues being raised related to some concerns that service provider
> requirements haven't been sufficiently reflected in the GMPLS signaling
> specifications - or at least, not been tested against.  (An initial set
> of requirements was provided by BT on
> Considerations on the development of an Optical Control Plane -
> http://search.ietf.org/internet-drafts/draft-freeland-octrl-cons-01.txt.
> Monica has mentioned other currently available sources of service
> provider requirements as well, such as the Carriers Optical Services
> Framework and Associated Requirements for the UNI, developed in the OIF
> and submitted to T1 and ITU-T.  Some requirements were also submitted
> earlier in the draft Requirements on the ASON UNI -
> http://search.ietf.org/internet-drafts/draft-lin-mpls-ipo-ason-uni-00.txt.
> )
> 
> For example, assuring separation of the control plane from the data
> plane continues to arise - the GMPLS architecture document mentions this
> separation, but it's not clear how the GMPLS signaling specifications
> reflect the implications of this decoupling.  This is best illustrated
> in the handling of control plane failures.  In particular, what happens
> to established circuit connections if the control plane fails? If the
> control plane recovers, how do we sync the connection state?  As an
> example, from RSVP RFC: "RSVP takes a "soft state" approach to managing
> the reservation state in routers and hosts. RSVP soft state is created
> and periodically refreshed by Path and Resv messages. The state is
> deleted if no matching refresh messages arrive before the expiration of
> a "cleanup timeout" interval." This means that if for whatever reason
> control messages are lost, the associated data paths will be released.
> Thus there is strong failure correlation between the control plane and
> data plane, which is inconsistent with the GMPLS architecture document,
> and also results in tearing down optical connections resulting from even
> temporary failures in the control plane.
> 
> I also understand the other comments from Hirokazu and Shehzad re
> exclusion of NSAP, having been at the last OIF meeting where there was
> considerable and spirited discussion of this issue.  The current GMPLS
> architecture document specifically excludes NSAP, and from the last OIF
> meeting 6 out of 12 operators discussing this issue felt there was some
> need to support NSAP addressing.
> 
> Given that the Requirements Design Team will be starting shortly, I
> concur with Yuri's suggestion for inclusion of a clear statement of what
> is - and isn't - covered in the GMPLS Signaling Description, RSVP
> Extensions, LDP Extensions drafts.   A suggestion for such text is
> provided below (the intro will need to be tailored to each draft):
> 
> "Overall, the objective of Generalized MPLS is to adapt MPLS signaling
> and other protocols to enable their applicability to various switching
> technologies.   A key motivating application has been applicability to
> support a distributed control plane for various circuit-switching
> technologies.   The signaling specifications contained within the these
> drafts offer a starting point towards this goal; their current scope and
> applicability, and areas for further assessment, are summarized below:
> 
> These drafts provide some extensions to traditional MPLS signaling and
> the basic signaling mechanisms provided in RSVP and LDP Ids (RFCs and
> standard track documents) have not been modified.   It is noted that
> MPLS signaling has been designed with a focus upon packet-switched
> network based applications, utilizing  requirements and architectural
> constructs suitable for such applications.   There may be significant
> distinguishing characteristics with regard to requirements and
> architectural considerations  for a distributed control plane that
> supports circuit-switched network applications.  One well acknowledged
> instance involves the decoupling of the control plane from the data
> plane.  Such differences may have substantive impact on the signaling
> mechanisms, the details of which require further study.  In addition,
> upon further study of operational requirements and circuit-switching
> technology specific aspects, further signaling extensions may be
> required.
> 
> These drafts are focussed upon intra-area signaling interfaces, and do
> not address issues and considerations related to other domains of
> usage.   Applicability to inter-area and inter-domain interfaces
> requires further study."
> 
> Hope this helps us move forward.
> 
> Cheers,
>   Eve
> 
> itu
> 
> [email-masked] wrote:
> >
> > Hi,
> >
> > I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
> > drafts.
> >
> > (1) Decoupling of the control plane from the data plane should be clearly
> > stated.
> >
> > This decoupling clearly has an impact on how the protocols should be defined
> > to cope with control plane failures.
> >
> > (2) Exclusion of NSAP
> >
> > The GMPLS architecture document, (which logically speaking should perhaps
> > have been put forward for last call, ahead of the functional description)
> > explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
> > communications channels (DCC bytes) therefore the use of alternative
> > addressing within the same channels may have an adverse effect on
> > interworking with legacy equipment, particularly with regard to management.
> > This raises the general concern of what level of compatibility is
> > required/desired with legacy SDH/SONET equipment.  This debate whilst likely
> > to be contentious, is unavoidable as the interworking of control plane,
> > management plane and transport will have a direct impact on how this
> > equipment is deployed and the economics of whether such deployments will
> > ever pay off.
> >
> > (3) Requirements from both security and OSS has not been discussed fully
> > yet.
> >
> > Security concerns have not been fully addressed, particularly at the
> > architectural level.  The use of separate control network may necessitate
> > the need for 24 hour staff to protect against 'Denial of Service' attacks as
> > currently happens for IP router networks.  The interaction between the
> > management plane and control plane need to be addressed, for example it is
> > undesirable to have multiple alarms generated when circuits are created and
> > torn down otherwise the management of a large scale network will become
> > impossible.  Discussions on service aspects need to take place, otherwise
> > the adoption of GMPLS equipment may be hampered, by these (solvable)
> > concerns.
> >
> > Best regards
> >
> > Shehzad Mirza
> >
> >
> >
> > > -----Original Message-----
> > > From: Hirokazu Ishimatsu [SMTP:[email-masked]]
> > > Sent: 29 May 2001 02:46
> > > To:   George Swallow; ccamp; mpls
> > > Cc:   ip-optical; tsg15q11; tsg13q10
> > > Subject:      [IP-Optical] RE: GMPLS Last Calls
> > >
> > > Hi,
> > >
> > > From a carrier's perspective, my concerns about GMPLS signaling drafts
> > > are as follows:
> > >
> > > (1) Decoupling of the control plane from the data plane should be clearly
> > >      stated.
> > > (2) Exclusion of NSAP
> > > (3) Requirements from both security and OSS (Operating Support System)
> > >      has not been discussed fully yet.
> > >
> > > Best regards,
> > > Hirokazu Ishimatsu
> > > Japan Telecom
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On
> > > > Behalf Of George Swallow
> > > > Sent: Tuesday, May 15, 2001 2:52 AM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: GMPLS Last Calls
> > > >
> > > >
> > > > This message initiates a last call on four GMPLS drafts.  The last
> > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > >
> > > > The drafts are:
> > > >
> > > >     1.  Generalized MPLS - Signaling Functional Description
> > > >
> > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > >
> > > >
> > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > >
> > > >
> > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > >
> > > >
> > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > >
> > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > >
> > > >
> > > > The last call closes May 29, 12 pm GMT.
> > > >
> > > >
> > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > >
> > > >
> > > > ======================================================================
> > > > George Swallow       Cisco Systems                   (978) 244-8143
> > > >                      250 Apollo Drive
> > > >                      Chelmsford, Ma 01824
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------076141E8FCA7BD2DE27A0322
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------076141E8FCA7BD2DE27A0322--

Delivery-date: Tue, 29 May 2001 13:41:53 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  'Guangzhi Li' <[email-masked]>, 'Heiles Juergen' <[email-masked]>
Subject: Transparency at the IETF and OIF
Date: Tue, 29 May 2001 22:34:36 +0200

Dear all,

About the transparency and its importance (especially for the people =
that
want to remove it from the standard track, or remove purely and simply =
:-)

Extracted from the carrier OIF requirements for the UNI =
(oif2000.155.1):

   Multiple levels of transparent services SHALL be supported:
   =B7	SONET/SDH Line and Section terminating.=20
   =B7	SONET/SDH Section terminating with Line transparency.=20
   =B7	SONET/SDH with Line and Section transparency.=20
   =B7	Non-SONET/SDH transparent bit-streams. [later version]

This document was co-authored by ATT (Monica and John), UUNET, C&W, =
WorldCom
and Deutshe Telekom. I agree with this requirement.

The document also list all the members of the OIF carrier group: AT&T, =
Cable
& Wireless, Deutsche Telekom (D-Nova), Enron, GTS, KDD, Korea Telecom, =
NTT,
Palm, Sita, Sprint, TDK, Telecom Italia, CSELT, UUNET, WorldCom.=09

There are 6 BIG carriers telling that they want to be able to control
transparency at the UNI. Of course it means that they want transparency =
at
the NNI because otherwise it doesn't make any sense, the transparency =
being
implemented at the NNI, not the UNI.

I said many times that transparency is useful at the GMPLS UNI, =
whatever is
happening at the NNI. This is exactly the point that make the OIF and =
the
carrier group of the OIF.

So, what I am proposing is to keep the transparency that we have today =
in
GMPLS for the UNI. This is not related to any transmission plane issue,
because it is not implemented at the UNI.

Transparency is also supported by the OIF UNI by the way. This
standardization body is considering it as an important feature. I don't =
see
any valid reason in that context why we should not have it in GMPLS at =
the
UNI.

I am very surprised that people fighting against transparency in GMPLS =
at
the IETF (UNI as I explained already many times) are indeed co-authors
and/or work for companies that approved transparency for the OIF UNI.

Here is the list of manufacturers that approved transparency at the OIF =
UNI:
*Lucent*, Nortel, Alcatel, Tenor, Tellium, Callient, Sycamore, =
Acceligth,
Ciena, Lucent, Brightwave, Caspian, Nayna, ONI, Cisco, Juniper, =
Zaffire,
Avici, Laurel, Sorrento, etc.

To summarize, transparency is:

1) requested by at least 6 big carriers.
2) requested by at least 20 manufacturers.
3) part the OIF UNI (from a standardization body).
4) implemented in many products.

>Again, in terms of metrics, what is considered "interesting for the
>industry"? By the vendor community or the carrier community? I just =
want
>us to be clear...no more, no less....

Is that a good "metric" ?

I think that we have a rough consensus to keep transparency in the =
standard
track !

Amazing that nobody reacted against the OIF carriers requirements for =
the
UNI, and against the OIF UNI specification... Even more amazing that =
some
people have two different languages, one for IETF and one for the OIF !

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

Delivery-date: Tue, 29 May 2001 13:34:18 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 21:23:43 +0100

Hi Vishal.....I am waiting to hear what is happening with the operator
'design team'.  It seems to me that their 1st task ought to be to create an
agreed set of requirements.

neil

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: 29 May 2001 20:57
> To: 'Debanjan Saha'; 'Mannie, Eric'; 'Lazer, Monica A, NNAD';
> 'Bernstein, Greg'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> 
> 
> Debanjan,
> 
> Excellent idea! I think this is what I had also proposed a 
> few days ago,
> when Eve had first provided a reference to the BT document.
> However, I think it would be really helpful (now, and in the 
> future) to
> have all the carrier requirements articulated in one place.
> 
> That would not only allow us to keep track of the various issues, but
> also eliminate redundant ones (so that duplication does not needlessly
> crowd the field and our discussions), prioritize the issues, 
> and start 
> addressing
> them one-by-one in a systematic manner, beginning with the 
> most relevant
> or most substantive ones.
> 
> Thanks,
> 
> -Vishal
> 
> On Tuesday, May 29, 2001 11:59 AM, Debanjan Saha 
> [SMTP:[email-masked]] 
> wrote:
> > Monica,
> > As Eric said, it's very difficult to keep track of all
> > the questions that have been asked. Would someone (possibly
> > you :-)) put them together in one list so that we all can
> > discuss them in a more coordinated way. Thanks in advance,
> > Debanjan
> >
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: Tuesday, May 29, 2001 1:20 PM
> > To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> >
> >
> > > The text does not look good
> >
> > Monica, I didn't sent the same e-mail and text again, apparently one
> > exploder is re-sending old e-mails, you read the text that 
> was send last
> > week :-)
> >
> > Anyway, it should be time for everybody to calm down and to behave.
> >
> > Eric
> >
> > -----Original Message-----
> > From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> > Sent: Tuesday, May 29, 2001 5:46 PM
> > To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
> >
> >
> > Eric,
> > The text does not look good. Many have expressed concerns 
> about having
> > support for arbitrary concatenation show as if it is a 
> standard transport
> > feature.
> > I am flabbergasted by the fact that many comments, which 
> expressed the same
> > or similar concerns from many companies, have simply been ignored.
> > Below are comments that   I sent out. They were not 
> addressed or replied to.
> > So I assumed that there were no objections. I now see that they were
> > ignored.
> >
> > Eric,
> > Below I have some additional specific comments for the 
> document GMPLS
> > Extensions for SONET and SDH Control
> >
> >
> > CCT field (3 bits)
> > Since arbitrary contiguous concatenation is not a standard 
> concatenation, it
> > falls within the vendor proprietary set of solutions.
> >
> > So the CCT bits may be used as follows:
> > 000	No contiguous concatenation requested
> > 001	Standard contiguous concatenation
> > others	Vendor specific contiguous concatenation
> >
> > Alternatively, a better solution is to use only 2 bits for 
> this field and
> > use one bit to show whether contiguous concatenation is 
> requested and the
> > second bit to show whether it is standard or non-standard contiguous
> > concatenation.
> >
> >
> > NCC field (16 bits)
> > This information is not sufficient.
> > NCC needs better description than a zero or non-zero number.
> >
> > SDH and SONET Labels
> >
> > Text in this section (Section 3, paragraphs 5 and 6) 
> indicates that the
> > GMPLS proposal limits virtual concatenation to remain 
> within a single
> > (component) link. If I understand this correctly, it means 
> that GMPLS will
> > not allow inverse multiplexing (virtual concatenation) in 
> the transport
> > plane if it requires different component links. This is too 
> limiting.
> >
> > Annex 1 (sent out by Eric Mannie on 5/22)
> > Defines another type of concatenation - Flexible arbitrary 
> contiguous
> > concatenation without describing precisely how it affects 
> the OH bits. This
> > means that it will be impossible to have this type of 
> concatenation in a
> > multi vendor environment based only on the GMPLS signaling. 
> If the transport
> > plane is proprietary, having the option in the signaling 
> message will not
> > fix the interoperability problem between two different 
> vendors supporting
> > their proprietary versions of arbitrary concatenation.
> >
> > Annex 2 (sent out by Eric Mannie on 5/22)
> > Arbitrary contiguous concatenation needs definition work for
> > interoperability.
> > Flexible arbitrary contiguous concatenation may be 
> available today to
> > support contiguous signals, but it is not defined in the 
> current standards.
> > Clear agreements on OH usage are needed between supporting vendors.
> > Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > [email-masked]
> >
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Monday, May 21, 2001 11:21 PM
> > To: Mannie, Eric; [email-masked]
> > Cc: [email-masked]
> > Subject: [IP-Optical] RE: Proposed text for the concatenation
> >
> > The text looks good Eric.  I'm happy to help with any text 
> to make the
> > definition of arbitrary flexible concatenation clearer.
> >
> > Greg B.
> >
> >
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 1:28 PM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Proposed text for the concatenation
> >
> >
> > Dear All,
> >
> > I am pleased to see so many people discussing so much on 
> these mailing
> > lists, but now as an editor of 
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> >
> > Please, carefully read the following text that clarifies 
> the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> >
> > "This field indicates the type of SONET/SDH contiguous 
> concatenation to
> > apply on the Elementary Signal. It is set to zero to 
> indicate that no
> > contiguous concatenation is requested (default value). The 
> values are
> > defined in the following table:
> >
> >        Bits   Contiguous Concatenation Type
> >       -----   ----------------------------------
> >        000     No contiguous concatenation requested
> >        001     Standard contiguous concatenation
> >        010     Arbitrary contiguous concatenation
> >        011     Flexible arbitrary contiguous concatenation
> >       others   Vendor specific concatenation types
> >
> > Standard contiguous concatenation refers to the contiguous 
> concatenation as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary 
> contiguous
> > concatenation relaxes the limitations of these standards in 
> terms of the
> > location where a contiguous signal can start, and in terms 
> of the number of
> > concatenated VC's/SPE's that can compose this signal.
> >
> > Flexible arbitrary contiguous concatenation is an 
> optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse 
> multiplex" a
> > contiguously concatenated signal on a per multiplex 
> section/line basis. In
> > order to be effectively used, an upstream node must 
> indicate that its
> > supports this feature to its immediate downstream node, 
> using the CCT field.
> > The downstream node can in that case use that feature and 
> return a list of
> > labels, one for each element of the "inverse multiplex"; 
> instead of one
> > single label indicating the beginning of the contiguous signal.
> >
> > This is not a definition. For this to have any value as a 
> standard document,
> > it needs to be submitted to appropriate tranport plane 
> standards bodies.
> > This is support for proprietary solutions. Not more, not less.
> >
> > The three types of contiguous concatenation defined here 
> before defines
> > indeed a hierarchy of flexibility in the contiguous 
> concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, 
> indicates that
> > any of the three types of contiguous concatenation can be 
> chosen by the
> > downstream node. It is up to the downstream node to choose 
> the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> >
> > Please send me your technical comments about the technical 
> correctness of
> > this text only. Please, delay discussions about the 
> usefulness of these
> > features and the way to implement them to another time. 
> What is important is
> > that each feature works. Your profile, implementation, or 
> configuration
> > should determine what you like and what you want to 
> support, not this
> > signalling.
> >
> > Take your time to read the text and to answer, it is 10PM 
> in my time zone
> > and I will leave my office. I'll be back on Monday morning 
> to read your
> > answers.
> >
> > Many thanks to all of you and have a nice week-end.
> >
> > Kind regards,
> >
> > Eric
> >
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> >
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> >
> > Tel:    +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax:    +32 2 658 51 18
> > E-mail: [email-masked]
> >
> >
> >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 

Delivery-date: Tue, 29 May 2001 13:09:40 -0700
Date: Tue, 29 May 2001 16:05:39 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi Eric,

Some comments:

> Let's be democratic as you said, my notion of democracy is not to remove
> these two features from the draft because your don't implement them.

I never said to remove because I don't implement, nor did I ever say I
implement. You're jumping to conclusions. Let's all take your advice and
calm down. What I meant (and everyone can have their own interpretations
of some of my analogies) was that given the discussions of why something
is in and why we include and what the implications for the
interoprability, then we need to be precise and provide description of
the criteria for inclusion and provide adequate means to allow
interoperability.

Rob's suggestion of having two separate documents make sense, and is ONE
way forward. You might have other suggestions that may equally make
sense.

> We said *many* times that we didn't want to include all features from all
> manufacturers but just as small set of basic features that seems to be
> interesting for the industry. The proof is that you don't have in the draft

Again, in terms of metrics, what is considered "interesting for the
industry"? By the vendor community or the carrier community? I just want
us to be clear...no more, no less....

> You are trying to present this work as if it was made and decided by a small
> set of people, that's not right and not fair. The fact is that you didn't
> pay attention to it and came very late into the process trying to impose
> your own ideas to the group. We had exactly the same kind of discussion
> since more than two months with your colleagues one by one, I guess this is
> part of your strategy.

Again, please don't jump to conclusions and stay calm. I didn't mean to
criticize, maybe I did use some analogies to the extreme, but seems
everyone's temper was at edge...As to paying attention to the work,
etc., we all know how much discussion about adding features goes on on
the public email. Not to criticize anyone, but just stating a fact. I
also remember that this is been discussed continuously for a few months
as well, so it's not something that was simply started now. Maybe the
realization about the implications of adding this was something that
came to light for a few people, including myself...

And I'm not strategizing to take over the world...far from it, I'm
terrible at playing strategy or role-playing games... :-(

> We proposed, as requested by your colleagues, to make a distinction between
> what is defined in SDH/SONET and what is not. I agreed that's a good idea to
> clarify the draft. In addition, these two mechanisms are 100% optional. Now
> of course you want more, you want to remove everything (that's what you call
> democracy). Obviously, you don't want to reach a consensus, does it worth to
> continue these discussions ?

I don't see what I said would trigger you to say that I want to "remove
everything"? All I've tried to do is to try to inject some of my logic
into this discussion (obviously I failed miserably), by laying out the
rationales, and then deciding. This was based on all the back-and-forth
volleying of "standard, non-standard, proprietary" discussions. 

Zhi

"Mannie, Eric" wrote:
> 
> Hello Zhi,
> 
> Let's be adult as you said many times, we are speaking about TWO features
> (not hundreds as you like to present it):
> 
> - transparency.
> - concatenation.
> 
> You are afraid that implementation will not interoperate ? You should better
> speak first about the two signaling protocols that we have in GMPLS. GMPLS
> has options, like all control planes and nobody has to implement everything.
> This is signaling not a transmission format.
> 
> >So, what is the metric for deciding? I'm sure there are many vendors who
> >are reading this waiting to add their "unique" features to the document
> >as well...
> 
> We said *many* times that we didn't want to include all features from all
> manufacturers but just as small set of basic features that seems to be
> interesting for the industry. The proof is that you don't have in the draft
> these hundreds of famous features that are you are afraid by. What else
> should I repeat ?
> 
> Let's be democratic as you said, my notion of democracy is not to remove
> these two features from the draft because your don't implement them.
> 
> I understood from the many e-mails send by your company since three weeks
> that you don't want to see any transparency and any new form of
> concatenation in the draft. However this draft is not your product
> description. It is not a product description, it is a signaling
> specification with options.
> 
> You are trying to present this work as if it was made and decided by a small
> set of people, that's not right and not fair. The fact is that you didn't
> pay attention to it and came very late into the process trying to impose
> your own ideas to the group. We had exactly the same kind of discussion
> since more than two months with your colleagues one by one, I guess this is
> part of your strategy.
> 
> We proposed, as requested by your colleagues, to make a distinction between
> what is defined in SDH/SONET and what is not. I agreed that's a good idea to
> clarify the draft. In addition, these two mechanisms are 100% optional. Now
> of course you want more, you want to remove everything (that's what you call
> democracy). Obviously, you don't want to reach a consensus, does it worth to
> continue these discussions ?
> 
> Regards,
> 
> Eric
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 5:38 AM
> To: Mannie, Eric
> Cc: 'Guo-Qiang Wang'; [email-masked];
> [email-masked]; q11/15; t1x1.5
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi,
> 
> I think your questions cannot be answered either way. Whether features
> are needed for one or two vendors is up to each vendor to decide what
> they want.
> 
> As for how many vendor is needed for a standard. Again this question
> doesn't really apply. We as engineers and the development community has
> to study a problem to make sure that it will not unduly impact existing
> networks, that what we are looking at should be sound and technically
> superior and that it will help provide added value to networks. As these
> transport capabilities will likely require people of transport expertise
> to study first, that's what we should do. Let's not get too "trigger
> happy" and include something "just because it's there", and then decide
> to remove when "standards say no". That like "putting the cart in front
> of the horse".
> 
> As to how many companies and how many people's names are on the
> contribution. Let's be intelligent adults here. As someone once asked
> me, "if you see a million flies eating feces, would you also eat?"
> (sorry people! it is disgusting but I had to give an extreme analogy).
> Sometimes the majority may not be correct. I am not saying I am correct
> either. It all depends on the background knowledge base and the
> underlying motive of the people...
> 
> As to how many processes followed, how many meetings held, how many
> conferences given, how many emails exchanged...an idea doesn't get
> better with repetition. As someone once said at some standards meeting
> "if an idea stinks, it doesn't matter how many times some idea is
> presented, it still stinks that many times". So the number of times is
> not a reason for making a decision.
> 
> Let's be technical, let the experts in the right group decide, and we
> should not jump the gun. Let's be adults and let's help make the telecom
> industry and the standards process a respectable place...
> 
> "Mannie, Eric" wrote:
> 
> > I don't work for a vendor :-) Who told you that some features are needed
> > only for one or two vendors ? How do you quantify the number of vendors
> that
> > are needed to have a standard ? We work on a consensus based and this
> draft
> > has 17 companies on it with 30 people. Usually it is much much less at the
> > IETF, you only have a small number of co-authors. I already gave a summary
> > of the process that we followed, all the meetings that we hold, all the
> > conference call that we hold, all the e-mails that we exchanged, etc.
> >
> > You described one model in your e-mail, that's a valid model but this is
> not
> > THE (only) model. There are plenty of other models that can be fulfilled
> > with GMPLS.
> >
> > Kind regards,
> >
> > Eric
> >
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 12:34:43 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Debanjan Saha'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 12:57:05 -0700

Debanjan,

Excellent idea! I think this is what I had also proposed a few days ago,
when Eve had first provided a reference to the BT document.
However, I think it would be really helpful (now, and in the future) to
have all the carrier requirements articulated in one place.

That would not only allow us to keep track of the various issues, but
also eliminate redundant ones (so that duplication does not needlessly
crowd the field and our discussions), prioritize the issues, and start 
addressing
them one-by-one in a systematic manner, beginning with the most relevant
or most substantive ones.

Thanks,

-Vishal

On Tuesday, May 29, 2001 11:59 AM, Debanjan Saha [SMTP:[email-masked]] 
wrote:
> Monica,
> As Eric said, it's very difficult to keep track of all
> the questions that have been asked. Would someone (possibly
> you :-)) put them together in one list so that we all can
> discuss them in a more coordinated way. Thanks in advance,
> Debanjan
>
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 1:20 PM
> To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
>
>
> > The text does not look good
>
> Monica, I didn't sent the same e-mail and text again, apparently one
> exploder is re-sending old e-mails, you read the text that was send last
> week :-)
>
> Anyway, it should be time for everybody to calm down and to behave.
>
> Eric
>
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 5:46 PM
> To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
> Cc: [email-masked]
> Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
>
>
> Eric,
> The text does not look good. Many have expressed concerns about having
> support for arbitrary concatenation show as if it is a standard transport
> feature.
> I am flabbergasted by the fact that many comments, which expressed the same
> or similar concerns from many companies, have simply been ignored.
> Below are comments that   I sent out. They were not addressed or replied to.
> So I assumed that there were no objections. I now see that they were
> ignored.
>
> Eric,
> Below I have some additional specific comments for the document GMPLS
> Extensions for SONET and SDH Control
>
>
> CCT field (3 bits)
> Since arbitrary contiguous concatenation is not a standard concatenation, it
> falls within the vendor proprietary set of solutions.
>
> So the CCT bits may be used as follows:
> 000	No contiguous concatenation requested
> 001	Standard contiguous concatenation
> others	Vendor specific contiguous concatenation
>
> Alternatively, a better solution is to use only 2 bits for this field and
> use one bit to show whether contiguous concatenation is requested and the
> second bit to show whether it is standard or non-standard contiguous
> concatenation.
>
>
> NCC field (16 bits)
> This information is not sufficient.
> NCC needs better description than a zero or non-zero number.
>
> SDH and SONET Labels
>
> Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> GMPLS proposal limits virtual concatenation to remain within a single
> (component) link. If I understand this correctly, it means that GMPLS will
> not allow inverse multiplexing (virtual concatenation) in the transport
> plane if it requires different component links. This is too limiting.
>
> Annex 1 (sent out by Eric Mannie on 5/22)
> Defines another type of concatenation - Flexible arbitrary contiguous
> concatenation without describing precisely how it affects the OH bits. This
> means that it will be impossible to have this type of concatenation in a
> multi vendor environment based only on the GMPLS signaling. If the transport
> plane is proprietary, having the option in the signaling message will not
> fix the interoperability problem between two different vendors supporting
> their proprietary versions of arbitrary concatenation.
>
> Annex 2 (sent out by Eric Mannie on 5/22)
> Arbitrary contiguous concatenation needs definition work for
> interoperability.
> Flexible arbitrary contiguous concatenation may be available today to
> support contiguous signals, but it is not defined in the current standards.
> Clear agreements on OH usage are needed between supporting vendors.
> Maintenance and tracking of the signal needs to be well understood.
>
>
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> [email-masked]
>
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 11:21 PM
> To: Mannie, Eric; [email-masked]
> Cc: [email-masked]
> Subject: [IP-Optical] RE: Proposed text for the concatenation
>
> The text looks good Eric.  I'm happy to help with any text to make the
> definition of arbitrary flexible concatenation clearer.
>
> Greg B.
>
>
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 1:28 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Proposed text for the concatenation
>
>
> Dear All,
>
> I am pleased to see so many people discussing so much on these mailing
> lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> would like to make some progress.
>
> Please, carefully read the following text that clarifies the contiguous
> concatenation part of the draft and that introduces one simple new
> concatenation type.
>
> "This field indicates the type of SONET/SDH contiguous concatenation to
> apply on the Elementary Signal. It is set to zero to indicate that no
> contiguous concatenation is requested (default value). The values are
> defined in the following table:
>
>        Bits   Contiguous Concatenation Type
>       -----   ----------------------------------
>        000     No contiguous concatenation requested
>        001     Standard contiguous concatenation
>        010     Arbitrary contiguous concatenation
>        011     Flexible arbitrary contiguous concatenation
>       others   Vendor specific concatenation types
>
> Standard contiguous concatenation refers to the contiguous concatenation as
> it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> concatenation relaxes the limitations of these standards in terms of the
> location where a contiguous signal can start, and in terms of the number of
> concatenated VC's/SPE's that can compose this signal.
>
> Flexible arbitrary contiguous concatenation is an optimisation of the
> arbitrary contiguous concatenation that allows to "inverse multiplex" a
> contiguously concatenated signal on a per multiplex section/line basis. In
> order to be effectively used, an upstream node must indicate that its
> supports this feature to its immediate downstream node, using the CCT field.
> The downstream node can in that case use that feature and return a list of
> labels, one for each element of the "inverse multiplex"; instead of one
> single label indicating the beginning of the contiguous signal.
>
> This is not a definition. For this to have any value as a standard document,
> it needs to be submitted to appropriate tranport plane standards bodies.
> This is support for proprietary solutions. Not more, not less.
>
> The three types of contiguous concatenation defined here before defines
> indeed a hierarchy of flexibility in the contiguous concatenation. If
> selected, the flexible arbitrary contiguous concatenation, indicates that
> any of the three types of contiguous concatenation can be chosen by the
> downstream node. It is up to the downstream node to choose the one that it
> wants to use. The upstream node, when receiving the labels from the
> downstream node, may accept or refuse what was proposed."
>
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
>
> Take your time to read the text and to answer, it is 10PM in my time zone
> and I will leave my office. I'll be back on Monday morning to read your
> answers.
>
> Many thanks to all of you and have a nice week-end.
>
> Kind regards,
>
> Eric
>
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
>
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
>
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
>
>
>
>
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 12:00:03 -0700
From: Debanjan Saha <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 14:59:19 -0400

Monica,
As Eric said, it's very difficult to keep track of all
the questions that have been asked. Would someone (possibly
you :-)) put them together in one list so that we all can
discuss them in a more coordinated way. Thanks in advance,
Debanjan

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:20 PM
To: 'Lazer, Monica A, NNAD'; 'Bernstein, Greg'; [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation

> The text does not look good

Monica, I didn't sent the same e-mail and text again, apparently one
exploder is re-sending old e-mails, you read the text that was send last
week :-)

Anyway, it should be time for everybody to calm down and to behave.

Eric

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:46 PM
To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation

Eric,
The text does not look good. Many have expressed concerns about having
support for arbitrary concatenation show as if it is a standard transport
feature. 
I am flabbergasted by the fact that many comments, which expressed the same
or similar concerns from many companies, have simply been ignored.
Below are comments that   I sent out. They were not addressed or replied to.
So I assumed that there were no objections. I now see that they were
ignored. 

Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control

CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.

NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Monday, May 21, 2001 11:21 PM
To: Mannie, Eric; [email-masked]
Cc: [email-masked]
Subject: [IP-Optical] RE: Proposed text for the concatenation

The text looks good Eric.  I'm happy to help with any text to make the
definition of arbitrary flexible concatenation clearer.

Greg B.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

This is not a definition. For this to have any value as a standard document,
it needs to be submitted to appropriate tranport plane standards bodies.
This is support for proprietary solutions. Not more, not less. 

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

       

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 11:29:39 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 20:27:24 +0200

Hello Tony,

>Still nobody answers the question of why not use virtual concatenation,
>which does all that is required and more. Or do people have too much half
>baked silicon!

I think that people are receiving too many e-mails, personally I cannot
treat all of them, that becomes a full time job :-) People don't always have
the answer to our questions neither, and they are not paid to spend all
their time answering on mailing lists :-)

Kind regards,

Eric

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: 29 May 2001 16:26
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I think there is some confusion in the intention of introducing the
concatenation options.  A few points:
(1) The two additional concatenation options introduced in Eric's proposal
"arbitrary contiguous" and "flexible arbitrary" are the progressive
loosening of the existing "contiguous concatenation" restrictions of G.707
or T1.105.
(2) Several vendors offer one or both of these extensions.
(3) Equipment that offers these extensions can always work with equipment
that doesn't offer these extensions. 
(4) These are not proprietary features using the definition of "proprietary"
as furnished by Randy Bush in a recent e-mail.
(5) GMPLS routing and signaling can be used to negotiate the use of these
features within a network of mixed equipment and hence make the best use of
all types of equipment. 

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 11:24:26 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 20:19:53 +0200

> The text does not look good

Monica, I didn't sent the same e-mail and text again, apparently one
exploder is re-sending old e-mails, you read the text that was send last
week :-)

Anyway, it should be time for everybody to calm down and to behave.

Eric

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:46 PM
To: 'Bernstein, Greg'; Mannie, Eric; [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation

Eric,
The text does not look good. Many have expressed concerns about having
support for arbitrary concatenation show as if it is a standard transport
feature. 
I am flabbergasted by the fact that many comments, which expressed the same
or similar concerns from many companies, have simply been ignored.
Below are comments that   I sent out. They were not addressed or replied to.
So I assumed that there were no objections. I now see that they were
ignored. 

Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control

CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.

NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Monday, May 21, 2001 11:21 PM
To: Mannie, Eric; [email-masked]
Cc: [email-masked]
Subject: [IP-Optical] RE: Proposed text for the concatenation

The text looks good Eric.  I'm happy to help with any text to make the
definition of arbitrary flexible concatenation clearer.

Greg B.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

This is not a definition. For this to have any value as a standard document,
it needs to be submitted to appropriate tranport plane standards bodies.
This is support for proprietary solutions. Not more, not less. 

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

       

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 11:13:06 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Eric Gray'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 11:33:08 -0700

Eric, Greg,

I agree with your thoughs and summary. I see nothing wrong in deferring a 
couple
items for further study (FFS), and moving the basic draft forward. As Greg 
observed,
vendors are already implementing some of the basic signaling (and even
routing) specifications.

Also, Eric, your summary appears very good to me. I think it would be 
constructive
to try to wrap this discussion up, and proceed with the basic specifications.
The items left for futher study can, of course, continue to be discussed
(or better yet, written about).

I too would be happy to work on the FFS items to work through the issues,
and ensure that they are  progressed to the satisfaction of vendors and
providers.

Thanks,
-Vishal

On Thursday, May 24, 2001 4:17 PM, Bernstein, Greg [SMTP:[email-masked]] 
wrote:
> Very good summary Eric. Like yourself, I'm not sure what's wrong with the
> signaling protocol including industry practices even if they are not covered
> by existing standards.  In some cases the extensions are perhaps too minor
> in scope or too controversial to warrant extension of ITU/ANSI standards.
> The "arbitrary contiguous concatenation" and the "flexible arbitrary
> concatenation" examples are cases in point.  In both cases we are just
> talking about an optional loosening of specified constraints.
>
> I didn't realize that others already supported "arbitrary contiguous
> concatenation". You probably have a better view into the wide range of SDH
> products than I.  I think your proposed text is good.  I'd be happy to work
> with yourself and others in bringing these items into ITU/ANSI/ETSI or
> wherever, but I don't think that the GMPLS SDH/SONET draft needs to wait on
> such an effort, i.e., folks are implementing these specs now and
> demonstrating interoperability.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 8:15 PM
> To: 'Stephen Trowbridge'
> Cc: [email-masked]; [email-masked]; 'Eric Gray';
> [email-masked]'; Bernstein, Greg; [email-masked]';
> [email-masked]'
> Subject: RE: Proposed text for the concatenation
>
>
> Hello Stephen,
>
> >I think this goes against earlier email that says T1X1 and ITU-T
> >are responsible for specification of SONET/SDH. There are two
> >standardized forms of concatenation. Your proposal includes only
> >one of the standardized forms and two that are, for the moment,
> >proprietary. If we accept that SONET/SDH is the responsibility
> >of T1X1/ITU-T...the other concatenation proposals must go to
> >T1X1/ITU-T before they can be considered standardized.
>
> Transparency and contiguous arbitrary concatenation were done in the current
> draft with the significant participation of ITU-T experts that regularly
> attend and participate to ITU-T meetings (several of them working for your
> company by the way). We reached a consensus for the current draft between a
> significant number of people working on different sides, all were SDH/SONET
> experts. The most active co-authors even hold an half-day editing session in
> parallel with the last OIF meeting in Paris. See the explanations hereafter.
>
> We should stop the debate ITU-T against IETF, my company is member of both
> and the folks that work on GMPLS to control SDH/SONET since one year and a
> half are SDH/SONET experts !
>
> We gave some explanations in our document to better describe what we are
> speaking about, it has *nothing* to do with the way to implement it. Anybody
> is free to describe what he/she is talking about. We gave our explanation of
> a few interesting SDH/SONET behaviours in order to be sure that people will
> understand what we are talking about.
>
> Moreover, it is not because something is not defined in an SDH standard that
> it doesn't work or doesn't exist, specially if this doesn't require any
> change to the standards ! Note that there is a life outside of the G.707
> standard.
>
> Sending flames to mailing lists without trying to understand how it works is
> confusing for everybody.
>
> In that context, one should make the difference between:
>
> 1) SDH/SONET features that need an additional standard to be able to
> interoperate:
> ----------------------------------------------------------------------------
> ------
>
> In that case this is NOT at all in the scope of the IETF of course. I never
> heard anybody at the IETF proposing to do SDH/SONET standards, it does not
> make sense. The IETF management was *very* clear about that. It is well
> understood and agreed. There is non reason to come back to this point
> constantly, and there is no reason to use it as an argument each time we
> speak about SDH/SONET at the IETF !
>
> 2) SDH/SONET features that don't need any new SDH/SONET standard:
> -----------------------------------------------------------------
>
> Let's speak about the three features that are disturbing a *few* folks.
>
>
> About arbitrary contiguous concatenation:
> ----------------------------------------
>
> Arbitrary contiguous concatenation (as described it in the proposed text)
> don't need any standard, it is just a way to use SDH/SONET. It is already
> implemented since a while by many manufacturers in legacy equipment's. In
> that case there is NO reason why we should not define features to control it
> in the GMPLS signaling. It is not because it is not described in G.707 that
> you cannot do it, or that it doesn't work. What do you want to standardize,
> a written permission to do it maybe ?
>
> About transparency:
> -------------------
>
> Transparency at the GMPLS UNI does NOT require any SDH/SONET standard
> because it is NOT implemented at the UNI, it is 100% about signaling. We
> never said that GMPLS MUST be used at both the UNI and NNI. The NNI could be
> in a proprietary cloud of a single manufacturer. So, there is NO reason to
> remove it from the GMPLS signaling.
>
> If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
> at the NNI between two manufacturers needs an agreement to interoperate.
> This agreement can be achieved in very different ways: through the use of a
> standard, an implementation agreement made by a forum, or an implementation
> agreement between two manufacturers (e.g. at the request of an operator).
>
> ITU-T is not the only standardization body that produced SDH standards, ETSI
> also made SDH standards that were published as ETSI standards. T1X1 is not
> the only body with ITU-T that can work on SDH, ETSI is there as well. The
> OIF is also publishing standards, and at the last OIF there was a session
> dedicated to transparency. We can expect to see more contributions at the
> next OIF meeting. Some contributions could also be presented to T1X1.
> Anyway, that's not the business of IETF and has nothing to do with
> transparency in the GMPLS signaling at the UNI.
>
> About flexible arbitrary contiguous concatenation:
> --------------------------------------------------
>
> What is the additional standard that we need to support flexible arbitrary
> contiguous concatenation. Could someone describe what should be standardized
> and why two implementations could not interoperate ?
>
> The GMPLS signaling gives the type, the number, the order, and the position
> of all components. Flexible arbitrary contiguous concatenation in GMPLS is
> only an indication send to the downstream node that it could use this
> feature. The upstream node doesn't request it, it simply says to the
> downstream node that it supports it. The downstream node can either decide
> to ignore it and use a standard contiguous concatenation, or an arbitrary
> contiguous concatenation; or it could refuse the connection request. This is
> a local optimization to deal with local external fragmentation of the
> multiplex that will happen if you route very dynamic demands. Traditional
> ITU-T folks don't understand the interest since they don't think in terms of
> dynamic circuit establishment.
>
> There is NO interoperability issue between nodes that implement it and nodes
> that doesn't implement it. Again, a written permission to do it doesn't need
> to be written in a standard.
>
> Kind regards,
>
> Eric
>
> Eric Mannie
> EBONE (GTS)
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 11:06 PM
> To: Mannie, Eric
> Cc: [email-masked]; [email-masked]
> Subject: Re: Proposed text for the concatenation
>
>
> Eric,
> I think this goes against earlier email that says T1X1 and ITU-T
> are responsible for specification of SONET/SDH. There are two
> standardized forms of concatenation. Your proposal includes only
> one of the standardized forms and two that are, for the moment,
> proprietary. If we accept that SONET/SDH is the responsibility
> of T1X1/ITU-T, then for the moment I think the options can only
> be:
> - No concatenation
> - Standard Contiguous concatenation
> - Standard Virtual concatenation
> - (all others are, for the moment proprietary) vendor specific
>   concatenation types
> The other concatenation proposals must go to T1X1/ITU-T before
> they can be considered standardized.
> Regards,
> Steve Trowbridge
>
> "Mannie, Eric" wrote:
> >
> > Dear All,
> >
> > I am pleased to see so many people discussing so much on these mailing
> > lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> >
> > Please, carefully read the following text that clarifies the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> >
> > "This field indicates the type of SONET/SDH contiguous concatenation to
> > apply on the Elementary Signal. It is set to zero to indicate that no
> > contiguous concatenation is requested (default value). The values are
> > defined in the following table:
> >
> >        Bits   Contiguous Concatenation Type
> >       -----   ----------------------------------
> >        000     No contiguous concatenation requested
> >        001     Standard contiguous concatenation
> >        010     Arbitrary contiguous concatenation
> >        011     Flexible arbitrary contiguous concatenation
> >       others   Vendor specific concatenation types
> >
> > Standard contiguous concatenation refers to the contiguous concatenation
> as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> > concatenation relaxes the limitations of these standards in terms of the
> > location where a contiguous signal can start, and in terms of the number
> of
> > concatenated VC's/SPE's that can compose this signal.
> >
> > Flexible arbitrary contiguous concatenation is an optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse multiplex" a
> > contiguously concatenated signal on a per multiplex section/line basis. In
> > order to be effectively used, an upstream node must indicate that its
> > supports this feature to its immediate downstream node, using the CCT
> field.
> > The downstream node can in that case use that feature and return a list of
> > labels, one for each element of the "inverse multiplex"; instead of one
> > single label indicating the beginning of the contiguous signal.
> >
> > The three types of contiguous concatenation defined here before defines
> > indeed a hierarchy of flexibility in the contiguous concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, indicates that
> > any of the three types of contiguous concatenation can be chosen by the
> > downstream node. It is up to the downstream node to choose the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> >
> > Please send me your technical comments about the technical correctness of
> > this text only. Please, delay discussions about the usefulness of these
> > features and the way to implement them to another time. What is important
> is
> > that each feature works. Your profile, implementation, or configuration
> > should determine what you like and what you want to support, not this
> > signalling.
> >
> > Take your time to read the text and to answer, it is 10PM in my time zone
> > and I will leave my office. I'll be back on Monday morning to read your
> > answers.
> >
> > Many thanks to all of you and have a nice week-end.
> >
> > Kind regards,
> >
> > Eric
> >
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> >
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> >
> > Tel:    +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax:    +32 2 658 51 18
> > E-mail: [email-masked]
> >
> >
>
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 11:04:14 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Eric Gray' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 11:00:49 -0700

Hi Eric (Gray), Ciena supports all the concatenation extensions discussed in
the draft. Note that LTE only equipment doesn't need to do anything special
to support the transport of virtually concatenated signals.
The transparency options are larger and apply to more than one type of
equipment. Hence, I might not offer all types on the same box (DWDM, Core
Switching, Metro Switch). 

Are the complaints from BT, Lucent, Siemens and AT&T primarily directed at:
(1) Extended concatenation types
(2) Semi-transparency feature
(3) Path group/AUG-N signal type
Are there other problems?  Would leaving these for further study get us out
of this deadlock? I.e., some don't want these in a separate specification,
some do. Note that various companies have implemented an earlier less mature
form of this spec and acheived some measure of interoperability, i.e., the
closed door UNH OIF session and the upcomming supercom demo. It would be
very helpful for the industry in general to move this forward now even
without some of the more "advanced features". 

Note, however, I do receive pressure from carriers to be open and to provide
these features.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 10:26 AM
To: Bernstein, Greg
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Greg,

    I think it is fair to both ask and answer the question -

        'which companies support feature X'

- on these mailing lists.  An answer is certainly relevant, it
need not be in the form of a product announcement and it is
much better than a choice of poking around in the dark at
shadows of 'some vendors' or being one of a few hundred
people to call the oracle.

    For once, I'd like to see a straight forward answer.  How
naive I must be...

--
Eric Gray

You wrote:

> Hi Tony, I didn't think we were supposed to advertise on these e-mail
> exploders so I didn't name names. See comments below.
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> Phone: (510) 573-2237
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 8:32 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Greg,
>
> From your points:
>
> (1) progressive loosening ... equates to non-compliant.
> >> Actually not, this equipment is completely G.707/T1.105 compliant. This
> is an extension not a further restriction.
>
> (2) Which vendors? Let's here some names. Or even better, from the vendors
> themselves.
> >> Don't want to plug any particular company, but feel free to give me a
> call.
>
> (3) How does this equipment negotiate feature availability?
> >> Numerous ways: with "end systems (across a UNI)" this is what the
service
> discovery part of the OIF UNI is about, with "peers" this is what the
> routing extensions are partially about.
> (4) Of course it's proprietary!
> >> Actually "proprietary" means "no one else can offer it". Like in the
old
> PBX days where the manufacturers would patent a "feature" like
"distinctive
> ringing" so that no one else could offer it or that license fees would
need
> to be paid.  I took this definition from Randy Bush. I would say this is a
> non-standard feature.
> (5) Has this level of signalling been proposed yet?
> >> Partially, via GMPLS SONET/SDH extensions.
>
> Still nobody answers the question of why not use virtual concatenation,
> which does all that is required and more. Or do people have too much half
> baked silicon!
> >> Virtual concatenation is really a PTE function that uses path overhead
> and is not "path transparent". The concatenation extensions (arbitrary and
> flexible) are fairly straight forward line (MS) layer extensions that
> prevent the need for re-grooming.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: 29 May 2001 16:26
> To: [email-masked]'; [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> I think there is some confusion in the intention of introducing the
> concatenation options.  A few points:
> (1) The two additional concatenation options introduced in Eric's proposal
> "arbitrary contiguous" and "flexible arbitrary" are the progressive
> loosening of the existing "contiguous concatenation" restrictions of G.707
> or T1.105.
> (2) Several vendors offer one or both of these extensions.
> (3) Equipment that offers these extensions can always work with equipment
> that doesn't offer these extensions.
> (4) These are not proprietary features using the definition of
"proprietary"
> as furnished by Randy Bush in a recent e-mail.
> (5) GMPLS routing and signaling can be used to negotiate the use of these
> features within a network of mixed equipment and hence make the best use
of
> all types of equipment.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 1:51 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Eric,
>
> This is not describing just a way to use SONET/SDH as it changes every box
> in the network! To use this there are changes/additions required to G,707
> and G.783.
>
> Neither is this a new feature. Concatenation is already described and
> explained.
>
> I do not understand the linkage between GMPLS and concatenation. the two
are
> independent up to the point that you may wish to attempt variable
bandwidth
> allocation. At this point extensions to concatenation are requires, and as
I
> have already stated this work is already under discussion in ITU.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: 28 May 2001 12:06
> To: 'Rob Coltun'; John Drake
> Cc: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Hello Rob,
>
> > Is it really that big an issue to just keep them in a separate RFC?
>
> Even if there is absolutely no standard required from ITU-T ? Nothing is
> needed for arbitrary concatenation, AUG-X, TUG, etc. We are just
describing
> a way to use SDH/SONET. There was no technical discussion about that.
>
> Do you mean that any feature that is not defined by ITU-T should not be
> published in the standard track ? For instance the concept of waveband
> switching ? The signal types ? The link protection ? The protection and
> restoration ?
>
> What is the added-value of GMPLS if we cannot take some freedom with the
> existing standards ? Our added-value is to match the new developments of
the
> industry, with the added-value that was added and not only the published
> standards from ITU-T.
>
> We already agreed on the following approach:
>
> - all mechanisms are optional (zero means I don't care).
> - we indicate clearly what is not defined in ITU-T/T1X1 standards.
>
> Can we simply use this approach ?
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Saturday, May 26, 2001 1:20 AM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
>
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
>
> We've said from the beginning that we didn't want to define new "data
plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
>
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the
industry.
> This standard stuff is certainly not easy.
>
> Is it really that big an issue to just keep them in a separate RFC?
>
> thanks,
> ---rob
>
> John Drake wrote:
>
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base
TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Tue, 29 May 2001 11:01:37 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'John Drake' <[email-masked]>, 'Heiles Juergen' <[email-masked]>,  "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, 'Bala Rajagopalan' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatena tion
Date: Tue, 29 May 2001 19:53:49 +0200

Dear All,

I am currently receiving copies of e-mail that were sent seven days ago by
different people. Are you experiencing the same problem ?

Monica, please check the e-mail dates, apparently you received a duplicate
e-mail. I think also that you already received the e-mail from John.

Rgds,

Eric

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 5:41 PM
To: 'John Drake'; 'Heiles Juergen'; Mannie, Eric; 'Fong, Man Wing';
'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the
concatena tion

I thought I had already replied to this specific question.
For SONET/SDH - ITU has global standards. Items specific to US (i.e., SONET)
are in T1X1 and items specific to Europe are in ETSI. For transport to
inter-work it is essential that interfaces conform to these. Change
proposals also need to be submitted there. Or is IETF deciding to also work
on transport layer standards?
As far as GMPLS compliant being self-compliant - that is wonderful, but when
controlling SONT/SDH - it needs to be able to control inter-working
transport networks, so it needs to support the standard transport (see
T1X1/ITU).

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 7:52 PM
To: Lazer, Monica A, NNAD; 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man
Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatenation

Monica,

When you say standards compliant, which standards bodies are you
considering?  I.e., from one of Eric's
notes I got the impression that there were actually multiple bodies that had
defined SONET/SDH features.
Further, we could indicate that implementations of GMPLS signalling are are
GMPLS compliant - see 'self
defining term' in the index of Knuth vol 1.

Thanks,

John

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 1:42 PM
To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 10:27:45 -0700
Date: Tue, 29 May 2001 13:26:11 -0400
From: Eric Gray <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Greg,

    I think it is fair to both ask and answer the question -

        'which companies support feature X'

- on these mailing lists.  An answer is certainly relevant, it
need not be in the form of a product announcement and it is
much better than a choice of poking around in the dark at
shadows of 'some vendors' or being one of a few hundred
people to call the oracle.

    For once, I'd like to see a straight forward answer.  How
naive I must be...

--
Eric Gray

You wrote:

> Hi Tony, I didn't think we were supposed to advertise on these e-mail
> exploders so I didn't name names. See comments below.
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
> Phone: (510) 573-2237
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 8:32 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Greg,
>
> From your points:
>
> (1) progressive loosening ... equates to non-compliant.
> >> Actually not, this equipment is completely G.707/T1.105 compliant. This
> is an extension not a further restriction.
>
> (2) Which vendors? Let's here some names. Or even better, from the vendors
> themselves.
> >> Don't want to plug any particular company, but feel free to give me a
> call.
>
> (3) How does this equipment negotiate feature availability?
> >> Numerous ways: with "end systems (across a UNI)" this is what the service
> discovery part of the OIF UNI is about, with "peers" this is what the
> routing extensions are partially about.
> (4) Of course it's proprietary!
> >> Actually "proprietary" means "no one else can offer it". Like in the old
> PBX days where the manufacturers would patent a "feature" like "distinctive
> ringing" so that no one else could offer it or that license fees would need
> to be paid.  I took this definition from Randy Bush. I would say this is a
> non-standard feature.
> (5) Has this level of signalling been proposed yet?
> >> Partially, via GMPLS SONET/SDH extensions.
>
> Still nobody answers the question of why not use virtual concatenation,
> which does all that is required and more. Or do people have too much half
> baked silicon!
> >> Virtual concatenation is really a PTE function that uses path overhead
> and is not "path transparent". The concatenation extensions (arbitrary and
> flexible) are fairly straight forward line (MS) layer extensions that
> prevent the need for re-grooming.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: 29 May 2001 16:26
> To: [email-masked]'; [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> I think there is some confusion in the intention of introducing the
> concatenation options.  A few points:
> (1) The two additional concatenation options introduced in Eric's proposal
> "arbitrary contiguous" and "flexible arbitrary" are the progressive
> loosening of the existing "contiguous concatenation" restrictions of G.707
> or T1.105.
> (2) Several vendors offer one or both of these extensions.
> (3) Equipment that offers these extensions can always work with equipment
> that doesn't offer these extensions.
> (4) These are not proprietary features using the definition of "proprietary"
> as furnished by Randy Bush in a recent e-mail.
> (5) GMPLS routing and signaling can be used to negotiate the use of these
> features within a network of mixed equipment and hence make the best use of
> all types of equipment.
>
> Greg B.
> ***********************************
> Dr. Greg M. Bernstein
> Senior Scientist, Ciena Corporation
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 1:51 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Eric,
>
> This is not describing just a way to use SONET/SDH as it changes every box
> in the network! To use this there are changes/additions required to G,707
> and G.783.
>
> Neither is this a new feature. Concatenation is already described and
> explained.
>
> I do not understand the linkage between GMPLS and concatenation. the two are
> independent up to the point that you may wish to attempt variable bandwidth
> allocation. At this point extensions to concatenation are requires, and as I
> have already stated this work is already under discussion in ITU.
>
> Regards
>
>         Tony
>
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: 28 May 2001 12:06
> To: 'Rob Coltun'; John Drake
> Cc: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> Hello Rob,
>
> > Is it really that big an issue to just keep them in a separate RFC?
>
> Even if there is absolutely no standard required from ITU-T ? Nothing is
> needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
> a way to use SDH/SONET. There was no technical discussion about that.
>
> Do you mean that any feature that is not defined by ITU-T should not be
> published in the standard track ? For instance the concept of waveband
> switching ? The signal types ? The link protection ? The protection and
> restoration ?
>
> What is the added-value of GMPLS if we cannot take some freedom with the
> existing standards ? Our added-value is to match the new developments of the
> industry, with the added-value that was added and not only the published
> standards from ITU-T.
>
> We already agreed on the following approach:
>
> - all mechanisms are optional (zero means I don't care).
> - we indicate clearly what is not defined in ITU-T/T1X1 standards.
>
> Can we simply use this approach ?
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Saturday, May 26, 2001 1:20 AM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
>
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
>
> We've said from the beginning that we didn't want to define new "data plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
>
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the industry.
> This standard stuff is certainly not easy.
>
> Is it really that big an issue to just keep them in a separate RFC?
>
> thanks,
> ---rob
>
> John Drake wrote:
>
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Tue, 29 May 2001 09:18:47 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 09:17:21 -0700

Hi Tony, I didn't think we were supposed to advertise on these e-mail
exploders so I didn't name names. See comments below.
Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 
Phone: (510) 573-2237

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 8:32 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Greg,

>From your points:

(1) progressive loosening ... equates to non-compliant.  
>> Actually not, this equipment is completely G.707/T1.105 compliant. This
is an extension not a further restriction. 

(2) Which vendors? Let's here some names. Or even better, from the vendors
themselves.
>> Don't want to plug any particular company, but feel free to give me a
call.

(3) How does this equipment negotiate feature availability?
>> Numerous ways: with "end systems (across a UNI)" this is what the service
discovery part of the OIF UNI is about, with "peers" this is what the
routing extensions are partially about.
(4) Of course it's proprietary!
>> Actually "proprietary" means "no one else can offer it". Like in the old
PBX days where the manufacturers would patent a "feature" like "distinctive
ringing" so that no one else could offer it or that license fees would need
to be paid.  I took this definition from Randy Bush. I would say this is a
non-standard feature. 
(5) Has this level of signalling been proposed yet?
>> Partially, via GMPLS SONET/SDH extensions.

Still nobody answers the question of why not use virtual concatenation,
which does all that is required and more. Or do people have too much half
baked silicon!
>> Virtual concatenation is really a PTE function that uses path overhead
and is not "path transparent". The concatenation extensions (arbitrary and
flexible) are fairly straight forward line (MS) layer extensions that
prevent the need for re-grooming.

Regards

	Tony

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: 29 May 2001 16:26
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I think there is some confusion in the intention of introducing the
concatenation options.  A few points:
(1) The two additional concatenation options introduced in Eric's proposal
"arbitrary contiguous" and "flexible arbitrary" are the progressive
loosening of the existing "contiguous concatenation" restrictions of G.707
or T1.105.
(2) Several vendors offer one or both of these extensions.
(3) Equipment that offers these extensions can always work with equipment
that doesn't offer these extensions. 
(4) These are not proprietary features using the definition of "proprietary"
as furnished by Randy Bush in a recent e-mail.
(5) GMPLS routing and signaling can be used to negotiate the use of these
features within a network of mixed equipment and hence make the best use of
all types of equipment. 

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 08:54:55 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 11:53:33 -0400

Greg, 
It would probably be best if the arbitrary concatenation would be submitted
to T1X1 towards becoming an interoperable standard. 
>From your note I still don't see whether equipment supporting arbitrary
concatenation would interwork or not.
T1X1 meets in June :)
Use of GMPLS to negotiate features is of little help if those features do
not inter-work at the transport level.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 11:26 AM
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I think there is some confusion in the intention of introducing the
concatenation options.  A few points:
(1) The two additional concatenation options introduced in Eric's proposal
"arbitrary contiguous" and "flexible arbitrary" are the progressive
loosening of the existing "contiguous concatenation" restrictions of G.707
or T1.105.
(2) Several vendors offer one or both of these extensions.
(3) Equipment that offers these extensions can always work with equipment
that doesn't offer these extensions.
(4) These are not proprietary features using the definition of "proprietary"
as furnished by Randy Bush in a recent e-mail.
(5) GMPLS routing and signaling can be used to negotiate the use of these
features within a network of mixed equipment and hence make the best use of
all types of equipment.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

        Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 08:49:18 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatena tion
Date: Tue, 29 May 2001 11:47:16 -0400

Eric, 
I think that it needs to be stronger than a footnote. Proprietary features
have to be supported by extensions. This is why I proposed that arbitrary
concatenation is under "vendor proprietary concatenation methods"

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 5:01 PM
To: Lazer, Monica A, NNAD; 'Heiles Juergen'; 'Fong, Man Wing'; 'Bernstein,
Greg'; 'Bala Rajagopalan'; 'Maarten Vissers'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatenation

Hello Monica,

I fully agree with you and with the comments made by Dimitri, Lyndon and
Bala. The idea of the footnote to flag the features is a good consensus.

Is that ok for Juergen, Maarten and the others ?

Thanks,

Kind regards,

Eric

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 10:42 PM
To: 'Heiles Juergen'; Mannie, Eric; 'Fong, Man Wing'; 'Bernstein, Greg';
'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 08:47:51 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 16:31:32 +0100

Greg,

>From your points:

(1) progressive loosening ... equates to non-compliant.

(2) Which vendors? Let's here some names. Or even better, from the vendors
themselves.

(3) How does this equipment negotiate feature availability?

(4) Of course it's proprietary!

(5) Has this level of signalling been proposed yet?

Still nobody answers the question of why not use virtual concatenation,
which does all that is required and more. Or do people have too much half
baked silicon!

Regards

	Tony

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: 29 May 2001 16:26
To: [email-masked]'; [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

I think there is some confusion in the intention of introducing the
concatenation options.  A few points:
(1) The two additional concatenation options introduced in Eric's proposal
"arbitrary contiguous" and "flexible arbitrary" are the progressive
loosening of the existing "contiguous concatenation" restrictions of G.707
or T1.105.
(2) Several vendors offer one or both of these extensions.
(3) Equipment that offers these extensions can always work with equipment
that doesn't offer these extensions. 
(4) These are not proprietary features using the definition of "proprietary"
as furnished by Randy Bush in a recent e-mail.
(5) GMPLS routing and signaling can be used to negotiate the use of these
features within a network of mixed equipment and hence make the best use of
all types of equipment. 

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 08:46:26 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 11:45:39 -0400

Eric,
The text does not look good. Many have expressed concerns about having
support for arbitrary concatenation show as if it is a standard transport
feature. 
I am flabbergasted by the fact that many comments, which expressed the same
or similar concerns from many companies, have simply been ignored.
Below are comments that   I sent out. They were not addressed or replied to.
So I assumed that there were no objections. I now see that they were
ignored. 

Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control

CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.

NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Monday, May 21, 2001 11:21 PM
To: Mannie, Eric; [email-masked]
Cc: [email-masked]
Subject: [IP-Optical] RE: Proposed text for the concatenation

The text looks good Eric.  I'm happy to help with any text to make the
definition of arbitrary flexible concatenation clearer.

Greg B.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

This is not a definition. For this to have any value as a standard document,
it needs to be submitted to appropriate tranport plane standards bodies.
This is support for proprietary solutions. Not more, not less. 

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

       

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 08:43:51 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatena tion
Date: Tue, 29 May 2001 11:41:22 -0400

I thought I had already replied to this specific question.
For SONET/SDH - ITU has global standards. Items specific to US (i.e., SONET)
are in T1X1 and items specific to Europe are in ETSI. For transport to
inter-work it is essential that interfaces conform to these. Change
proposals also need to be submitted there. Or is IETF deciding to also work
on transport layer standards?
As far as GMPLS compliant being self-compliant - that is wonderful, but when
controlling SONT/SDH - it needs to be able to control inter-working
transport networks, so it needs to support the standard transport (see
T1X1/ITU).

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 7:52 PM
To: Lazer, Monica A, NNAD; 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man
Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [IP-Optical] RE: [T1X1.5] RE: Proposed text for the concatenation

Monica,

When you say standards compliant, which standards bodies are you
considering?  I.e., from one of Eric's
notes I got the impression that there were actually multiple bodies that had
defined SONET/SDH features.
Further, we could indicate that implementations of GMPLS signalling are are
GMPLS compliant - see 'self
defining term' in the index of Knuth vol 1.

Thanks,

John

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 1:42 PM
To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 08:27:19 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 08:26:05 -0700

I think there is some confusion in the intention of introducing the
concatenation options.  A few points:
(1) The two additional concatenation options introduced in Eric's proposal
"arbitrary contiguous" and "flexible arbitrary" are the progressive
loosening of the existing "contiguous concatenation" restrictions of G.707
or T1.105.
(2) Several vendors offer one or both of these extensions.
(3) Equipment that offers these extensions can always work with equipment
that doesn't offer these extensions. 
(4) These are not proprietary features using the definition of "proprietary"
as furnished by Randy Bush in a recent e-mail.
(5) GMPLS routing and signaling can be used to negotiate the use of these
features within a network of mixed equipment and hence make the best use of
all types of equipment. 

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 1:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 08:12:02 -0700
Date: Tue, 29 May 2001 09:11:28 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: Maarten Vissers <[email-masked]>, Yuri Landry <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [IP-Optical] Re: Protection switching in GMPLS ==> supporting G.841?

Dimitri,
ITU-T has an ongoing work program as well - it is not just a
set of static documents that never change.
In terms of protection, the current document, as you observe,
was developed to support SDH. However, as we define additional
layer technologies, it is clear that we have no need to reinvent
the wheel. The plans for G.841 are to split it into a series of
Recommendations, first by seperating out the generic aspects of
various protection architectures (e.g., SNC, shared protection
rings, etc.), and then developing a series of much smaller
documents describing the application of particular protection
architectures to different transport layer technologies.
I don't think this work needs to be complete and final for us
to be able to discuss how the protection architectures from G.841
apply to other layer technologies.
Regards,
Steve Trowbridge
Chairman, ITU-T WP 3/15

Dimitri Papadimitriou wrote:
> 
> Hello Maarten,
> 
> To which part of the document do yo refer here ? I suppose it
> is the section 7 of the GMPLS Signalling. G.841 is dedicated
> to "TYPES AND CHARACTERISTICS OF SDH NETWORK PROTECTION
> ARCHITECTURES" so it is a technology dependent document.
> 
> The main difference comes from the "objective" of these
> protection: in section 7 you describe the type of link
> selected in order to provide LSP link protection. G.841
> covers as indicated in the scope of the document:
> 
> "Protection schemes are classified as:
> - SDH trail protection (at the section or path layer);
> - SDH subnetwork connection protection (with inherent monitoring,
>   non-intrusive monitoring, and sub-layer monitoring)."
> 
> So this this document described the protection schemes while
> the scope of the GMPLS-SIG is only to determine the signalling
> extensions in order to provision link-protected LSP. If you
> have some doubts we could probably review this section together.
> What do you think about ?
> 
> - Dimitri.
> 
> Maarten Vissers wrote:
> >
> > All,
> >
> > Triggered by Yuri's email, I would like to offer another area for closer
> > look: protection switching. The standardised SDH protection switching
> > schemes are specified in G.841 with further support in G.783.
> >
> > When reading the protection switching text some time ago in the GMPLs
> > draft I noticed several extensions to be described beyond those in
> > G.841.
> >
> > My request is to review the latest text against G.841/G.783, identify
> > the extensions and (as now proposed by several of us) move those
> > extensions into a separate Informational document.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Hello All,
> > >
> > > So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> > > re-direct your attention to other drafts. Rob's suggestion should apply to
> > > other drafts too.
> > >
> > > One example, is the waveband switching and waveband label a standard or
> > > proprietary? Can author explain to me what exactly they means? How do they
> > > work? Any other standard reference? There are questions about it but no
> > > answer yet.
> > >
> > > Regards,
> > >
> > > Yuri.
> > >
> > > >From: "Lazer, Monica A, NNAD" <[email-masked]>
> > > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > > >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> > > ><[email-masked]>
> > > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> > > >tion
> > > >Date: Thu, 24 May 2001 18:11:36 -0400
> > > >
> > > >
> > > >Rob, You proposal makes a lot of sense. Having the signaling standard
> > > >support proprietary transport may jeopardize interoperability. The issue is
> > > >not about GMPLS supporting non-standard rates, the issue is about putting
> > > >in
> > > >formal and very specific support for a proprietary transport solution in a
> > > >standard document for signaling without taking the transport portion to a
> > > >standards body. Having formal signaling support for a proprietary
> > > >concatenation may cause interoperability issues when other vendors have a
> > > >different solution to the concatenation and while the signaling would
> > > >indicate the concatenation, the actual transport may not work.   On the
> > > >other hand we recognize that there may be a need for some interim support
> > > >for proprietary solutions.
> > > >
> > > >
> > > >Eric,
> > > >Below I have some additional specific comments for the document GMPLS
> > > >Extensions for SONET and SDH Control
> > > >
> > > >
> > > >CCT field (3 bits)
> > > >Since arbitrary contiguous concatenation is not a standard concatenation,
> > > >it
> > > >falls within the vendor proprietary set of solutions.
> > > >
> > > >So the CCT bits may be used as follows:
> > > >000    No contiguous concatenation requested
> > > >001    Standard contiguous concatenation
> > > >others Vendor specific contiguous concatenation
> > > >
> > > >Alternatively, a better solution is to use only 2 bits for this field and
> > > >use one bit to show whether contiguous concatenation is requested and the
> > > >second bit to show whether it is standard or non-standard contiguous
> > > >concatenation.
> > > >
> > > >
> > > >NCC field (16 bits)
> > > >This information is not sufficient.
> > > >NCC needs better description than a zero or non-zero number.
> > > >
> > > >SDH and SONET Labels
> > > >
> > > >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> > > >GMPLS proposal limits virtual concatenation to remain within a single
> > > >(component) link. If I understand this correctly, it means that GMPLS will
> > > >not allow inverse multiplexing (virtual concatenation) in the transport
> > > >plane if it requires different component links. This is too limiting.
> > > >
> > > >Annex 1 (sent out by Eric Mannie on 5/22)
> > > >Defines another type of concatenation - Flexible arbitrary contiguous
> > > >concatenation without describing precisely how it affects the OH bits. This
> > > >means that it will be impossible to have this type of concatenation in a
> > > >multi vendor environment based only on the GMPLS signaling. If the
> > > >transport
> > > >plane is proprietary, having the option in the signaling message will not
> > > >fix the interoperability problem between two different vendors supporting
> > > >their proprietary versions of arbitrary concatenation.
> > > >
> > > >Annex 2 (sent out by Eric Mannie on 5/22)
> > > >Arbitrary contiguous concatenation needs definition work for
> > > >interoperability.
> > > >Flexible arbitrary contiguous concatenation may be available today to
> > > >support contiguous signals, but it is not defined in the current standards.
> > > >Clear agreements on OH usage are needed between supporting vendors.
> > > >Maintenance and tracking of the signal needs to be well understood.
> > > >
> > > >
> > > >
> > > >Monica A. Lazer
> > > >Advanced Transport Technology and Architecture Planning
> > > >
> > > >908 234 8462
> > > >[email-masked]
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Rob Coltun [mailto:[email-masked]]
> > > >Sent: Thursday, May 24, 2001 7:24 PM
> > > >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> > > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > >concatenation
> > > >
> > > >All,
> > > >     despite the heated arguments I think the discussion is important to
> > > >have.
> > > >
> > > >I suggest that instead of  tagging non/pre-standard items in the current
> > > >drafts
> > > >that they be put into a separate Informational document  - this is the
> > > >cleanest thing to do.
> > > >We (the IETF) do have a tradition of publishing company proprietary
> > > >protocols
> > > >but not as standard track documents.
> > > >
> > > >thanks,
> > > >---rob
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >IP-Optical mailing list
> > > >[email-masked]
> > > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 29 May 2001 08:03:24 -0700
Date: Tue, 29 May 2001 11:06:30 -0400
From: Guangzhi Li <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
Cc: "'Ash, Gerald R (Jerry)'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: GMPLS Last Calls

Eric:

Are you speaking for yourself, GMPLS co-authors, or network working group ?

I think SPs give comments to GMPLS because they are interested in it. No body
blames anything. Everyone wants to help it working.

Thanks for your contribution.

-- Guangzhi

"Mannie, Eric" wrote:

> Hello Jerry
>
> >correct, as I mentioned, SPs have been formally asked for their
> >*requirements*, but not on the GMPLS extensions
>
> Sorry ! It is an OPEN process since the beginning, everybody can contribute
> and write a draft. There is no formal process where requirements from
> operators are asked for. I am not aware of any IETF rule about that !
>
> You were welcome to work with us since 1.5 years but you never came to us.
> You cannot blame us that you never worked on it (we are not responsible for
> that)! This is true for the thousands of internet drafts being written at
> the IETF.
>
> It is the responsibility of each company individually to decide if they want
> to contribute or not ! It is not the job of others companies to go to each
> possible operator/manufacturer and to lobby to have them involved.
>
> Regards,
>
> Eric

Delivery-date: Tue, 29 May 2001 05:28:43 -0700
Date: Tue, 29 May 2001 14:25:12 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Jonathan Lang <[email-masked]>, Bala Rajagopalan <[email-masked]>, "'Mannie, Eric'" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>
Subject: Re: [IP-Optical] RE: Dead of GMPLS ?

This is a multi-part message in MIME format.
--------------BC0CDAFA06D04EEB6E96FED9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan, Bala and Eric,

Bala wrote:
> I think the best way to move forward is to
> get some consensus on the set of well-defined
> features/capabilities that
> people agree have *current relevance*.

You wrote:
I thought that's what we had done in Paris.  Eric, Greg, Heiles,
Dimitri,
Eve, Dimitirios, myself, and others were in this meeting.  What I find
strange is that some of these same people are now arguing against what
we
all agreed to back then.

Today those people who are arguing against what we extensively 
discussed during this 1/2 day meeting but Jonathan you have to
take into account as well that the document was exchanged again
and again between those people during at least one month... so
they had the time to review the document during a period longer
than "common" last call period as well !!!

This makes me feel very uncomfortable... I agree with Jonathan i 
can not understand this behaviour today.

As stated by Eric (in one of his previous e-mails) if we agree
on the following approach:
- all mechanisms are optional (zero means I don't care)
- we clearly indicate what is not defined in ITU-T/T1X1 standards
Then people can apply the relevancy criteria they want (this is
clearly one of the main advantage of the current proposal).

Regards,
- Dimitri.

Jonathan Lang wrote:
> 
> Bala,
> >
> > Eric:
> >
> > I understand your frustration, but the current
> > state of affairs was waiting to happen given the
> > speed and zeal with which all sorts of features
> > were being proposed as candidates for GMPLS control.
> I'm not sure what you mean here.  The GMPLS work has been going on since
> late 1999.  There have been relatively few new features added since we met
> in Adelaide.  In fact, much of (what I would call) zealous material in the
> first version has actually been removed.
> 
> > I think the best way to move forward is to
> > get some consensus on the set of well-defined
> > features/capabilities that
> > people agree have *current relevance*.
> I thought that's what we had done in Paris.  Eric, Greg, Heiles, Dimitri,
> Eve, Dimitirios, myself, and others were in this meeting.  What I find
> strange is that some of these same people are now arguing against what we
> all agreed to back then.
> 
> > Other features, drop them/move to different drafts/what not.
> > It doesn't seem sensible to stop progress
> > on the most general aspects of gmpls for the
> > sake of supporting features whose
> > near-to-intermediate term
> > significance is dubious.
> I'm not sure about your assessment of the significance, but I agree that we
> shouldn't stop progress on the general aspects of gmpls.
> 
> Thanks,
> Jonathan
> 
> >
> > Regards,
> >
> >
> >
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> >
> > > -----Original Message-----
> > > From: Mannie, Eric [mailto:[email-masked]]
> > > Sent: Monday, May 28, 2001 11:37 AM
> > > To: 'Guo-Qiang Wang'
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; q16/15; John Drake
> > > Subject: RE: Dead of GMPLS ?
> > >
> > >
> > > Hello Guo-Qiang,
> > >
> > > >  If one non-SONET/SDH-standard feature could decide the
> > death or the
> > > liveness
> > > of GMPLS, it is the reason I strongly suggest you guys remove
> > > this feature
> > > to a separate document to keep GMPLS alive.  Up to now, all
> > > the arguments we
> > > have
> > > seen are focusing on non-SONET/SDH-standard issue, not on
> > > lambda switching
> > > and fiber switching.
> > >
> > > No, please read the included e-mails and the e-mails that I
> > > was referred to,
> > > they are talking about waveband switching, etc..
> > >
> > > We are now speaking about removing waveband switching, about
> > > where to put
> > > protection/restoration, and about scanning all the GMPLS
> > > drafts to see what
> > > should be removed (see the three e-mails from Maarten).
> > >
> > > I am discussing the general principle of moving all
> > > non-standard related
> > > features to separate documents. If you want to do it for
> > > technology A, to
> > > stay consistent you have to do it also for technology B, C, etc.
> > >
> > > Of course you have to remove lambda switching since this is
> > > proprietary
> > > (what are the parameters to control, to signal, etc... we
> > > don't know yet) -
> > > It is too early in this draft to speak about that before
> > > knowing how exactly
> > > the transmission plane will look like. There is no value of having a
> > > standardized control plane to control proprietary networks (as I
> > > understood).
> > >
> > > My list of features to remove contains at least:
> > >
> > > - SDH/SONET transparency.
> > > - SDH/SONET arbitrary concatenation, flexible concatenation.
> > > - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> > > - All kinds of end-to-end protection/restoration for any
> > > layer, except the
> > > IP layer.
> > > - The Waveband switching object and its concept.
> > > - The concept of LSC and FSC layers, i.e. concept of lambda
> > and fiber
> > > switching.
> > > - The label set object (only used for lambda issues).
> > > - LSP encoding type, bandwidth encoding and GPID have to be
> > simplified
> > > accordingly.
> > > - MPLS extensions to control G.709 (since multiplexing, etc
> > is not yet
> > > defined).
> > > - etc...
> > >
> > > Something else to add to this list ?
> > >
> > > Rgds,
> > >
> > > Eric
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Guo-Qiang Wang [mailto:[email-masked]]
> > > Sent: Monday, May 28, 2001 4:24 PM
> > > To: Mannie, Eric; 'Maarten Vissers'
> > > Cc: 'Yuri Landry'; [email-masked];
> > [email-masked];
> > > [email-masked]; [email-masked]; q16/15; John Drake
> > > Subject: RE: Dead of GMPLS ?
> > >
> > >
> > > Hi,
> > >   If one non-SONET/SDH-standard feature could decide the
> > death or the
> > > liveness
> > > of GMPLS, it is the reason I strongly suggest you guys remove
> > > this feature
> > > to a separate document to keep GMPLS alive. Up to now, all
> > > the arguments we
> > > have
> > > seen are focusing on non-SONET/SDH-standard issue, not on
> > > lambda switching
> > > and fiber switching.
> > >   Regards,
> > > G.Q Wang
> > > Technical Manager
> > > Emerging Network Technology
> > > Nortel Networks
> > > Tel: (613)765-4195 (ESN 395-4195)
> > > Fax: (613)768-1140
> > > [email-masked]
> > > -----Original Message-----
> > > From:   Mannie, Eric [SMTP:[email-masked]]
> > > Sent:   Monday, May 28, 2001 9:08 AM
> > > To:     'Maarten Vissers'
> > > Cc:     'Yuri Landry'; [email-masked];
> > > [email-masked];
> > > [email-masked]; [email-masked]; q16/15; John Drake
> > > Subject:        Dead of GMPLS ?
> > > Hello Maarten,
> > > E-mail 1:
> > > >Let's review the series of GMPLS
> > >                   ^^^^^^
> > > >draft documents to identify the non/pre-standard items and
> > then move
> > > >those items into separate Informational documents.
> > > ^                          ^^^^^^^^^^^^^^^^^^^^^^^
> > > E-mail 2:
> > > > Yuri started the discussion on wavebands some days ago.
> > > Wavebands are
> > > > yet undefined in the transport plane.
> > >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > E-mail 3:
> > > >Triggered by Yuri's email, I would like to offer another
> > > area for closer
> > > >look: protection switching. The standardised SDH protection
> > > switching
> > > >schemes are specified in G.841 with further support in G.783.
> > > >
> > > >When reading the protection switching text some time ago in
> > > the GMPLs
> > > >draft I noticed several extensions to be described beyond those in
> > > >G.841.
> > > >
> > > >My request is to review the latest text against G.841/G.783,
> > > identify
> > > >the extensions and (as now proposed by several of us) move those
> > > >extensions into a separate Informational document.
> > >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > The transmission plane for optical networks is not
> > standardized: DWDM
> > > systems are proprietary and don't interoperate.
> > > So I guess that we have to remove the concept of optical
> > > switching (lambda
> > > switching, fiber switching, waveband switching) from GMPLS if
> > > we want to
> > > follow your model of thinking. We also have to remove any
> > end-to-end
> > > protection/restoration and all non standardized SDH/SONET
> > > behaviors (even if
> > >
> > > they don't change the standards) as you said.
> > > Everything will become informational, except may be a very
> > small root
> > > specification (that will not be allowed to speak about any optical
> > > switching).
> > > Since the IETF will not have any standard (track) RFC, ITU-T
> > > will have to
> > > claim that there is no existing standard and do one...
> > > What is the benefit of moving all the interesting signaling
> > > features to
> > > informational RFC's ? If we don't have signaling standards
> > > why should we
> > > continue to work on GMPLS ? Why should we spend so much energy of
> > > informational documents that have no standard value ? That
> > > will be an easy
> > > marketing message "GMPLS: don't pay attention to it, it is only
> > > informational, you need a standard".
> > > Either GMPLS is dead, or we accept that GMPLS ALLOWS TO
> > > CONTROL STANDARDIZED
> > >
> > > AND NON STANDARDIZED DATA/TRANSMISSION PLANES.
> > > Regards,
> > > Eric
> > > -----Original Message-----
> > > From: Maarten Vissers [mailto:[email-masked]]
> > > Sent: Monday, May 28, 2001 11:03 AM
> > > To: John Drake
> > > Cc: 'Yuri Landry'; [email-masked];
> > > [email-masked];
> > > [email-masked]; [email-masked]; q16/15
> > > Subject: [IP-Optical] GMPLS: waveband switching
> > >
> > >
> > > John,
> > > Yuri started the discussion on wavebands some days ago.
> > Wavebands are
> > > yet undefined in the transport plane. Looking into it a few
> > > days ago, I
> > > tried to provide a definition of waveband and got immediately
> > > corrected
> > > by an optical expert, resulting in an adapted definition of
> > waveband
> > > (see email below).
> > > At this point in time, a waveband seems to be a group of
> > > Optical Channel
> > > (OCh) signals. It represents a partition, not a new layer
> > network. As
> > > such a waveband should be represented as a "group of OCh
> > > signals" within
> > > the OCh layer network.
> > > Regards,
> > > Maarten
> > >
> > >
> > >
> > > Maarten Vissers wrote:
> > > >
> > > > Manoj, Yuri,
> > > >
> > > > I received a message that my definition of waveband is too
> > > restricted.
> > > >
> > > > A waveband should be an optical multiplex, administered
> > as a single
> > > > bundle, not necessary contiguous in frequency slot.
> > > >
> > > >         E.g. there may be good technical reasons to consider a
> > > >         'waveband' created at an OADM formed by taking every 2nd
> > > >         wavelength in a 50GHz-spaced transmission band.
> > > >
> > > > In first instance the above definition may not be
> > > considered this as a
> > > > "band"; it
> > > > looks more like a "gapped-band" :-). Nevertheless, due to
> > technical
> > > > reasons we should consider a waveband as just another name for a
> > > > particular group of wavelengths, which may best be viewed
> > > as a group of
> > > > identified/listed wavelengths.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > Maarten Vissers wrote:
> > > > >
> > > > > Manoj, Yuri,
> > > > >
> > > > > In my current understanding, a waveband is a group of OCh
> > > (optical
> > > > > channel) signals located in a contiguous set of tributary (i.e.
> > > > > frequency) slots.
> > > > >
> > > > > A waveband is therefore related to partitioning, rather
> > > than a layering.
> > >
> > > > > A waveband shouldn't have an LSP encoding type itself,
> > > but instead be
> > > > > part of the OCh layer network. E.g. a specific RGT
> > > (requested groupting
> > > > > type) of "contiguous waveband" can be defined for this
> > > purpose with the
> > > > > RNC (requested number of components) indicating the size of the
> > > > > waveband.
> > > > >
> > > > > The above is simply a first shot; in general the issue
> > > can be more
> > > > > complex due to the fact that the frequency slot for a
> > > 2G5, a 10G and a
> > > > > 40G signal may have differnet bandwidths: e.g. 2G5 freq.
> > > slot width e.g.
> > >
> > > > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq.
> > > slot width e.g.
> > > > > 100 GHz. For the case of (future?) mixed rate WDM signals
> > > with bit rate
> > > > > optimized freq. slot widths, a waveband might need a
> > > start-of-waveband
> > > > > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Maarten
> > > > >
> > > > > Yuri Landry wrote:
> > > > > >
> > > > > > Mano,
> > > > > >
> > > > > > >            Can someone tell me the message
> > structure of Label
> > > Request and
> > > > > > >Label Mapping in GMPLS ?
> > > > > > >I am confused about the presence of LightPath Id in
> > > O-UNI messages
> > > and LSP
> > > > > > >Id in GMPLS messages ? Is there one-to-one mapping
> > > between these Ids
> > > or Is
> > > > > > >it like that both lightPath Id and LSP Id will be
> > > carried in GMPLS
> > > messages
> > > > > > >? LSP Id is not present in O-UNI messages. Can one
> > > LightPath Id be
> > > mapped
> > > > > > >to
> > > > > > >multiple LSP Ids or vice versa ?
> > > > > >
> > > > > > I think you mean Connection ID and LSP ID. A connection
> > > ID is an ID
> > > for
> > > > > > network connection, which may consist many LSPs. For
> > > example, the
> > > virtual
> > > > > > concatenation case.
> > > > > >
> > > > > > A LSP may tunnel through multiple pre-established
> > connections.
> > > > > >
> > > > > > >Also, for waveband switching, the genralized label has
> > > the format
> > > > > > >(wavebandId - start label - end label).
> > > > > > >When the label request message is received on incoming
> > > interface, how
> > >
> > > to
> > > > > > >identify that the waveband label is requested ?
> > > > > > >Is it the LSP encoding type or some other parameter in
> > > label request
> > > > > > >message
> > > > > > >? If it is the Lambda encoding type then how to
> > > identify that whether
> > >
> > > a
> > > > > > >lambda or waveband label is requested ?
> > > > > > >
> > > > > > >Also, it is mentioned that wavebandId (32 bits) is
> > > selected by the
> > > sender
> > > > > > >and reused in all the subsequent messages. What all
> > subsequent
> > > > > > >messages is it mentioning to ?
> > > > > > >
> > > > > > >Can wavebandId be present in Label Withdraw/Release
> > messages ?
> > > > > > >
> > > > > > >I am not able to workout the message structures for GMPLS.
> > > > > > >
> > > > > >
> > > > > > To me waveband label defined in GMPLS drafts is a joke.
> > > The reason to
> > > have
> > > > > > the waveband label is that someone claimed that the
> > > waveband's order
> > > might
> > > > > > flip when going through a switch. My suggestion is
> > > don't take it
> > > seriously.
> > > > > >
> > > > > > >I am not sure how these drafts are at last call.
> > > Atleast it should
> > > mention
> > > > > > >the message structures of various messages.
> > > > > > >
> > > > > >
> > > > > > Agree.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Yuri
> > > > > >
> > > _________________________________________________________________
> > > > > > Get your FREE download of MSN Explorer at
> > > http://explorer.msn.com
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > John Drake wrote:
> > > >
> > > > Yuri,
> > > >
> > > > I've attached a private note I sent to Dimitri regarding waveband
> > > switching.
> > > > It was originally put in at the suggestion of NorTel.  For
> > > both waveband
> > > > switching and fiber switching, you are dealing with a
> > > situation in which
> > > you
> > > > are using a standardized control plane to establish a
> > > multi-hop LSP with
> > > > proprietary encoding of data.  As I mentioned, this would
> > > be accomplished
> > > > using link coloring.
> > > >
> > > > Personally, I have no problem removing either waveband
> > > switching or fiber
> > > > switching, but we know have to accomodate them wrt the
> > > control plane, and
> > > I
> > > > seriously doubt that there will ever be a completely
> > > non-proprietary of
> > > > encoding the data for these types of LSPs.
> > > >
> > > > Note that I am using 'proprietary' in the exclusive sense.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > > -----Original Message-----
> > > > From: John Drake
> > > > Sent: Wednesday, March 28, 2001 11:15 AM
> > > > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> > > > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> > > > Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> > > >
> > > > Dimitri.
> > > >
> > > > It's probably better to think of waveband switching as a
> > > special form of
> > > > fiber switching; i.e., it has nothing to do with the
> > > SONET/SDH stuff at
> > > all.
> > > > Suppose the trunk side of a DWDM system is attached to a
> > > PXC.  In the
> > > fiber
> > > > switching case, the fiber between the DWDM system and a
> > > port on the PXC
> > > > contains the entire set of lambdas, while in the waveband
> > > switching case
> > > > there is a set of fibers between the DWDM system and a set
> > > of ports on the
> > >
> > > > PXC, each of which contains a separate waveband.
> > > >
> > > > In either case, the encoding of the signal on the fibers is
> > > completely
> > > > proprietary, and it's the job of routing to ensure that a
> > > correct path
> > > > through the network is obtained, such that the proprietary
> > > encoding is
> > > > maintained end-end.  This would probably be done through
> > > link coloring, so
> > >
> > > > that you only route across links that support NorTel
> > > waveband switching or
> > >
> > > > Tellabs waveband switching.
> > > >
> > > > So I think the signalling stuff is fine.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Yuri Landry [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 7:02 AM
> > > > To: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]
> > > > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > > concatena tion
> > > >
> > > > Hello All,
> > > >
> > > > So far, our discussions are focusing on the SONET/SDH
> > > draft. I'd like to
> > > > re-direct your attention to other drafts. Rob's suggestion
> > > should apply to
> > >
> > > > other drafts too.
> > > >
> > > > One example, is the waveband switching and waveband label a
> > > standard or
> > > > proprietary? Can author explain to me what exactly they
> > > means? How do they
> > >
> > > > work? Any other standard reference? There are questions
> > > about it but no
> > > > answer yet.
> > > >
> > > > Regards,
> > > >
> > > > Yuri.
> > > >
> > > > >From: "Lazer, Monica A, NNAD" <[email-masked]>
> > > > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > > > >[email-masked], q11/15 <[email-masked]>,
> > >   "t1x1.5"
> > > > ><[email-masked]>
> > > > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > concatena
> > > > >tion
> > > > >Date: Thu, 24 May 2001 18:11:36 -0400
> > > > >
> > > > >
> > > > >Rob, You proposal makes a lot of sense. Having the
> > > signaling standard
> > > > >support proprietary transport may jeopardize
> > > interoperability. The issue
> > > is
> > > > >not about GMPLS supporting non-standard rates, the issue
> > > is about putting
> > >
> > > > >in
> > > > >formal and very specific support for a proprietary
> > > transport solution in
> > > a
> > > > >standard document for signaling without taking the
> > > transport portion to a
> > >
> > > > >standards body. Having formal signaling support for a
> > proprietary
> > > > >concatenation may cause interoperability issues when other
> > > vendors have a
> > >
> > > > >different solution to the concatenation and while the
> > > signaling would
> > > > >indicate the concatenation, the actual transport may not
> > > work.   On the
> > > > >other hand we recognize that there may be a need for some
> > > interim support
> > >
> > > > >for proprietary solutions.
> > > > >
> > > > >
> > > > >Eric,
> > > > >Below I have some additional specific comments for the
> > > document GMPLS
> > > > >Extensions for SONET and SDH Control
> > > > >
> > > > >
> > > > >CCT field (3 bits)
> > > > >Since arbitrary contiguous concatenation is not a standard
> > > concatenation,
> > >
> > > > >it
> > > > >falls within the vendor proprietary set of solutions.
> > > > >
> > > > >So the CCT bits may be used as follows:
> > > > >000    No contiguous concatenation requested
> > > > >001    Standard contiguous concatenation
> > > > >others Vendor specific contiguous concatenation
> > > > >
> > > > >Alternatively, a better solution is to use only 2 bits for
> > > this field and
> > >
> > > > >use one bit to show whether contiguous concatenation is
> > > requested and the
> > >
> > > > >second bit to show whether it is standard or non-standard
> > > contiguous
> > > > >concatenation.
> > > > >
> > > > >
> > > > >NCC field (16 bits)
> > > > >This information is not sufficient.
> > > > >NCC needs better description than a zero or non-zero number.
> > > > >
> > > > >SDH and SONET Labels
> > > > >
> > > > >Text in this section (Section 3, paragraphs 5 and 6)
> > > indicates that the
> > > > >GMPLS proposal limits virtual concatenation to remain
> > > within a single
> > > > >(component) link. If I understand this correctly, it means
> > > that GMPLS
> > > will
> > > > >not allow inverse multiplexing (virtual concatenation) in
> > > the transport
> > > > >plane if it requires different component links. This is
> > > too limiting.
> > > > >
> > > > >Annex 1 (sent out by Eric Mannie on 5/22)
> > > > >Defines another type of concatenation - Flexible arbitrary
> > > contiguous
> > > > >concatenation without describing precisely how it affects
> > > the OH bits.
> > > This
> > > > >means that it will be impossible to have this type of
> > > concatenation in a
> > > > >multi vendor environment based only on the GMPLS
> > signaling. If the
> > > > >transport
> > > > >plane is proprietary, having the option in the signaling
> > > message will not
> > >
> > > > >fix the interoperability problem between two different
> > > vendors supporting
> > >
> > > > >their proprietary versions of arbitrary concatenation.
> > > > >
> > > > >Annex 2 (sent out by Eric Mannie on 5/22)
> > > > >Arbitrary contiguous concatenation needs definition work for
> > > > >interoperability.
> > > > >Flexible arbitrary contiguous concatenation may be
> > > available today to
> > > > >support contiguous signals, but it is not defined in the current
> > > standards.
> > > > >Clear agreements on OH usage are needed between supporting
> > > vendors.
> > > > >Maintenance and tracking of the signal needs to be well
> > > understood.
> > > > >
> > > > >
> > > > >
> > > > >Monica A. Lazer
> > > > >Advanced Transport Technology and Architecture Planning
> > > > >
> > > > >908 234 8462
> > > > >[email-masked]
> > > > >
> > > > >
> > > > >-----Original Message-----
> > > > >From: Rob Coltun [mailto:[email-masked]]
> > > > >Sent: Thursday, May 24, 2001 7:24 PM
> > > > >To: [email-masked]; [email-masked];
> > > q11/15; t1x1.5
> > > > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > > >concatenation
> > > > >
> > > > >All,
> > > > >     despite the heated arguments I think the discussion
> > > is important to
> > > > >have.
> > > > >
> > > > >I suggest that instead of  tagging non/pre-standard items
> > > in the current
> > > > >drafts
> > > > >that they be put into a separate Informational document  -
> > > this is the
> > > > >cleanest thing to do.
> > > > >We (the IETF) do have a tradition of publishing company
> > > proprietary
> > > > >protocols
> > > > >but not as standard track documents.
> > > > >
> > > > >thanks,
> > > > >---rob
> > > > >
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >IP-Optical mailing list
> > > > >[email-masked]
> > > > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >
> > > >
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
--------------BC0CDAFA06D04EEB6E96FED9
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------BC0CDAFA06D04EEB6E96FED9--

Delivery-date: Tue, 29 May 2001 05:13:24 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 13:02:09 +0100

So,

Two boxes which have the new features wish to use a link that traverses
older line systems. These do not support Arbitrary concatenation, so the
link won't work unless you upgrade the boxes!

You do have to change all of the boxes.

Of course, if you used virtual .......

Tony

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Tuesday, May 29, 2001 11:22 AM
> To:	[email-masked]'; [email-masked]; [email-masked]
> Subject:	RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hello Tony,
> 
> >This is not describing just a way to use SONET/SDH as it changes every
> box
> >in the network!
> 
> No, it doesn't change any box if you don't use these features. A feature
> in
> GMPLS doesn't mean that you are obliged to use it or to implement it. But
> which control plane will you use in your existing boxes ?
> 
> I don't think that you will have GMPLS as a simple software upgrade in
> your
> existing ADM's. Obviously you will have to deploy a new cloud with boxes
> able to run the control plane (in general you have a dedicated redundant
> hardware to run the control plane and a dedicated redundant hardware to
> run
> the routing algorithm in real-time on carrier class equipment's).
> 
> Interworking between an "ION" cloud and a non "ION" cloud (i.e. a
> traditional SDH/SONET cloud) is another issue.  In that case the control
> plane doesn't run on the non ION cloud and you need a manual provisioning
> there. Of course you must find a common denominator between the ION cloud
> and the non-ION cloud to support end-to-end circuits. However, end-to-end
> circuits that stay in the ION cloud will take benefits of the GMPLS
> features
> implemented by your manufacturer.
> 
> >To use this there are changes/additions required to G.707 and G.783.
> 
> What is important for interoperability is not the definition of a concept
> in
> a document but what is actually send between two nodes.
> 
> For arbitrary concatenation you don't change anything to the frame format,
> only each node must be able to recognize and treat the pointers and the
> VC-4-Xc. This concept is not defined in G.707 and G.783 but this has no
> impact. You negotiate this capability between each pair of node, if there
> is
> a node that doesn't support it, the circuit is refused. In addition, we
> expect that you will know this capability for each node/interface via the
> routing protocol. So the routing algorithm will find directly the adequate
> path.
> 
> Of course the ASIC's on that path must support the capability, this is an
> ASIC implementation issue, not a document issue. A manufacturer can
> implement whatever he likes in his ASIC's. GMPLS doesn't define what must
> be
> implemented in the transmission plane to be interoperable (that's the job
> for a profile). GMPLS gives tools in the control plane, some tools are
> optional of course.
> 
> Transparency at the GMPLS UNI has absolutely no impact on existing
> standards, the transmission plane and on existing ASIC's. It is only
> implemented at NNI. At the UNI this capability is signaled in GMPLS and
> the
> transmission plane doesn't care. At the NNI that will require a standard
> or
> an implementation agreement if and only if multiple vendors are used. So
> there are already many interesting scenarios in the short term where this
> feature can be helpful. In the long term if you want to go to multiple
> vendors you will need to ask them to reach a consensus to be able to
> interoperate. That could be easier than you think because transparency is
> software selectable for several of them, so when you buy the equipment you
> specify where you want to tunnel the overhead bytes.
> 
> There is in fact absolutely NO interoperability issue with any of these
> features if the circuit is refused when you try to cross a link where the
> two ends are incompatible, or where on end doesn't support transparency.
> Once again the routing protocol can advertise such capabilities. You can
> keep the control of your network in any case.
> 
> All these features are "negotiated" when you try to open a circuit, if the
> downstream node doesn't support a feature that connection attempt is
> refused.
> 
> >I do not understand the linkage between GMPLS and concatenation. the two
> are
> >independent up to the point that you may wish to attempt variable
> bandwidth
> >allocation. At this point extensions to concatenation are requires, and
> as
> I
> >have already stated this work is already under discussion in ITU.
> 
> GMPLS allows to open a circuit, that circuit can be a concatenated circuit
> between two IP routers. Variable bandwidth is orthogonal with that feature
> and is also possible with GMPLS if it can be supported by the control
> plane.
> If you are referring to LCAS, this is not a control plane that allows to
> open circuits dynamically.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 29, 2001 10:51 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> 
> Eric,
> 
> This is not describing just a way to use SONET/SDH as it changes every box
> in the network! To use this there are changes/additions required to G,707
> and G.783.
> 
> Neither is this a new feature. Concatenation is already described and
> explained.
> 
> I do not understand the linkage between GMPLS and concatenation. the two
> are
> independent up to the point that you may wish to attempt variable
> bandwidth
> allocation. At this point extensions to concatenation are requires, and as
> I
> have already stated this work is already under discussion in ITU.
> 
> Regards
> 
> 	Tony
> 
> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: 28 May 2001 12:06
> To: 'Rob Coltun'; John Drake
> Cc: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> 
> Hello Rob,
> 
> > Is it really that big an issue to just keep them in a separate RFC?
> 
> Even if there is absolutely no standard required from ITU-T ? Nothing is
> needed for arbitrary concatenation, AUG-X, TUG, etc. We are just
> describing
> a way to use SDH/SONET. There was no technical discussion about that.
> 
> Do you mean that any feature that is not defined by ITU-T should not be
> published in the standard track ? For instance the concept of waveband
> switching ? The signal types ? The link protection ? The protection and
> restoration ?
> 
> What is the added-value of GMPLS if we cannot take some freedom with the
> existing standards ? Our added-value is to match the new developments of
> the
> industry, with the added-value that was added and not only the published
> standards from ITU-T.
> 
> We already agreed on the following approach:
> 
> - all mechanisms are optional (zero means I don't care).
> - we indicate clearly what is not defined in ITU-T/T1X1 standards.
> 
> Can we simply use this approach ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Saturday, May 26, 2001 1:20 AM
> To: John Drake
> Cc: [email-masked]
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> 
> Hi John,
>     valid question -  I don't think this is true for BGP. There are
> extensions
> to BGP that the working group has adopted.
> Which TE drafts are you referring to?
> 
> We've said from the beginning that we didn't want to define new "data
> plane"
> functionality for technologies where the data plane is being defined
> elsewhere
> - whereas some of the functions aren't really new, and in cases might be
> de-facto standard
> we recognize that certain "data plane" functionality are beyond the scope
> of the IETF to define - so this keeps us more in line with (in this case)
> the ITU.
> 
> Note that IETF has defined the
> MPLS data plane - if some other body were to define new functionality
> for the MPLS data plane it would certainly cause confusion in the
> industry.
> This standard stuff is certainly not easy.
> 
> Is it really that big an issue to just keep them in a separate RFC?
> 
> thanks,
> ---rob
> 
> 
> John Drake wrote:
> 
> > Rob,
> >
> > Why isn't the proposed disclaimer sufficient?  If you look in the base
> TE
> > drafts, for example, there are codepoints defined for use by specific,
> > named, vendors.  I think the same is also true for BGP.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Rob Coltun [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 6:54 PM
> > To: [email-masked]
> > Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> >
> > All,
> >     despite the heated arguments I think the discussion is important to
> > have.
> >
> > I suggest that instead of  tagging non/pre-standard items in the current
> > drafts
> > that they be put into a separate Informational document  - this is the
> > cleanest thing to do.
> > We (the IETF) do have a tradition of publishing company proprietary
> > protocols
> > but not as standard track documents.
> >
> > thanks,
> > ---rob

Delivery-date: Tue, 29 May 2001 04:43:36 -0700
Date: Tue, 29 May 2001 07:40:35 -0400
To: Bala Rajagopalan <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: GMPLS Last Calls
Cc: "'Tarapore, Percy S'" <[email-masked]>, Bala Rajagopalan <[email-masked]>, "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>,[email-masked],[email-masked]

Sounds reasonable to me...

Lou

At 05:22 PM 5/25/01, Bala Rajagopalan wrote:

>This would be fine with me. John? Lou?
>
>regards,
>
>
>Bala Rajagopalan
>Tellium, Inc.
>2 Crescent Place
>P.O. Box 901
>Oceanport, NJ 07757-0901
>Tel: (732) 923-4237
>Fax: (732) 923-9804
>Email: [email-masked]
>
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 4:34 PM
> > To: 'Bala Rajagopalan'; 'C. R. Kalmanek'; John Drake
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> >
> > Bala,
> >
> > Are you suggesting that restoration signaling requirements be
> > formulated in
> > a separate GMPLS draft at a later date? If so, the current
> > draft should add
> > text regarding the current scope (link protection only) as
> > well as future
> > work (restoration) in Section 7.
> >
> > Percy
> >
> > -----Original Message-----
> > From: Bala Rajagopalan [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 1:57 PM
> > To: 'C. R. Kalmanek'; John Drake
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> >
> >
> > Chuck:
> >
> > I believe that the restoration issue can be
> > dealt with indepedent of the current drafts
> > on last call. Do you see any obstacles to
> > adding new objects/semantics (if any) to support
> > restoration requirements as they arise?
> >
> > BTW, there are some drafts floating around
> > on shared mesh.
> >
> > regards,
> >
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> >
> > > -----Original Message-----
> > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 1:08 PM
> > > To: John Drake
> > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > > [email-masked]
> > > Subject: Re: GMPLS Last Calls
> > >
> > >
> > > I fully agree: there are a whole spectrum of options that we
> > > need to sort through, and clear requirements are needed to
> > > guide that process.  Our concern is with the last call.  It
> > > doesn't make sense to progress drafts to RFC that are likely
> > > in hindsight to be viewed as having serious deficiencies in
> > > meeting restoration requirements.
> > >
> > > chuck
> > >
> > > John Drake wrote:
> > > >
> > > > The point is that in GMPLS, as in regular MPLS, restoration
> > > consists of
> > > > rerouting from the endpoints upon
> > > > notification of failure.  There are a whole spectrum of
> > > path and span
> > > > protection possibilites beyond this
> > > > that people (including us) have proposed, but in the
> > absence of firm
> > > > requirements, it's hard to know which
> > > > to pursue.  I'm not sure 'shared mesh restoration'
> > > completely covers it.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 9:54 AM
> > > > To: John Drake
> > > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry);
> > [email-masked];
> > > > [email-masked]
> > > > Subject: Re: GMPLS Last Calls
> > > >
> > > > John,
> > > >
> > > > While there currently are no restoration requirements from the
> > > > TE (or other) group, what Percy is saying is that shared mesh
> > > > restoration WILL be a requirement from those groups.  Since the
> > > > current GMPLS drafts don't meet this requirement, they are
> > > > unlikely to meet key SP needs.
> > > >
> > > > I don't understand a process that starts the requirements
> > > > development after last call for the signaling specifications.
> > > >
> > > > chuck
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Percy,
> > > > >
> > > > > There has been work on protocols for path restoration in
> > > mesh networks by
> > > > a
> > > > > number of
> > > > > people.  However, at the last IETF Kireeti and Vijay
> > > clearly indicated
> > > > that
> > > > > this work,
> > > > > while interesting, wouldn't be allowed to progress in
> > advance of a
> > > > > restoration requirements
> > > > > draft from the TE group.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > > > Sent: Thursday, May 24, 2001 11:55 AM
> > > > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > > > Subject: RE: GMPLS Last Calls
> > > > >
> > > > > There is a significant issue related to the absence of
> > > restoration in the
> > > > > signaling draft
> > > > >
> > > >
> > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > > ed-signaling-0
> > > > > 4.txt). Very specifically, Section 7 of this draft deals
> > > with the case
> > > > > involving protection information for link protection. While link
> > > > protection
> > > > > schemes may be desirable for fast recovery related to
> > > high priority LSP's,
> > > > > more cost-effective shared mesh restoration schemes would
> > > be preferred for
> > > > > the majority of traffic from a Service Provider's
> > > perspective. This
> > > > > observation is supported by the fact that many vendors
> > > are currently
> > > > > developing proprietary schemes for shared mesh
> > > restoration. Hence, in
> > > > > addition to the protection information, GMPLS signaling
> > > needs to reflect a
> > > > > minimum set of information/attributes required for shared
> > > mesh restoration
> > > > > without jeopardizing vendor proprietary solutions.
> > > > >
> > > > > The need for multiple types of restoration capabilities
> > > is well documented
> > > > > in the OIF/UNI I-D
> > > > >
> > > >
> > > http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> > > ework-uni-00.t
> > > > > xt as follows:
> > > > >
> > > > > " Multiple types of facilities available for restoration
> > > are needed
> > > > >    within the network. The following options should be
> > > considered for
> > > > >    allocation of facilities to support restoration of failed
> > > > >    connections:
> > > > >    - Dedicated restoration capacity
> > > > >    - Shared restoration capacity. This allows the network
> > > to ensure
> > > > >      high quality service for customers, while still
> > managing its
> > > > >      physical resources efficiently.
> > > > >    - Un-restorable
> > > > >    - Pre-emptable"
> > > > >
> > > > > The OIF/UNI I-D supports a range of different restoration
> > > schemes through
> > > > > the use of service level as a connection attribute. This
> > > attribute is
> > > > > defined as follows:
> > > > >
> > > > > " an integer attribute that indicates a class of service.
> > > A carrier may
> > > > > specify a range of different classes of service (e.g.
> > > gold, silver,
> > > > bronze)
> > > > > with predefined characteristics (e.g. restoration plans).
> > > The pre-defined
> > > > > service types correspond to different types of network
> > > restoration (e.g.
> > > > no
> > > > > restoration, 1+1 protection), connection set-up and hold
> > > priorities,
> > > > > reversion strategies for the connection after failures
> > > have been repaired,
> > > > > and retention strategies."
> > > > >
> > > > > It is therefore important that GMPLS be extended to be
> > > able to support
> > > > such
> > > > > restoration schemes.
> > > > >
> > > > > Percy S. Tarapore
> > > > > AT&T Labs
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ash, Gerald R (Jerry)
> > > > > Sent: Thursday, May 24, 2001 2:20 PM
> > > > > To: [email-masked]; [email-masked]
> > > > > Cc: Ash, Gerald R (Jerry)
> > > > > Subject: RE: GMPLS Last Calls
> > > > >
> > > > > Quoting from the CCAMP/IETF-50 meeting minutes re the
> > > GMPLS Architecture
> > > > > draft:
> > > > >
> > > > > "Eve - Had hoped that CCAMP formation and expression of
> > > requirements would
> > > > > enable us to do more with architecture than reverse
> > > architect proposed
> > > > > solution. Think we should also look at carrier
> > > requirements and look for
> > > > > discrepancies with architecture.
> > > > > Curtis - requirements of carriers not being addressed?
> > > > > Eve - happy to discuss on mailing list in absence of time"
> > > > >
> > > > > There are still no documented service provider (SP)
> > > requirements driving
> > > > the
> > > > > proposed GMPLS protocol extensions.  This is inconsistent
> > > with the current
> > > > > initiatives to provide SP requirements prior to protocol
> > > extensions being
> > > > > accepted, such as for protection/restoration, network
> > > hierarchy, MPLS OAM,
> > > > > MPLS/DiffServ TE, multi-area TE, etc.
> > > > >
> > > > > Here is a sample of SP requirements that are not being
> > > addressed (other
> > > > > requirements from our perspective are forthcoming):
> > > > >
> > > > > 1. Restoration requirements, particularly in support of
> > > mesh restoration,
> > > > > need to be supported by GMPLS.  For example, Section 7 of
> > > the Generalized
> > > > > Signaling I-D
> > > > >
> > > >
> > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > > ed-signaling-0
> > > > > 4.txt)
> > > > > primarily discusses link protection, restoration
> > > capabilities are largely
> > > > > missing and need to be included.
> > > > >
> > > > > 2. Standards explicitly supported by GMPLS, such as
> > > G.707, G.709, etc.,
> > > > > should be clearly identified in the text and referenced
> > > in the GMPLS I-Ds,
> > > > > e.g., in Section 3.1 of the Generalized Signaling I-D,
> > add "G.707
> > > > [Reference
> > > > > G.707] is supported by the Generalized Label Request."
> > > > >
> > > > > As per Eve's comment at IETF-50, SPs are encouraged to
> > post their
> > > > > requirements to the list.  It would also help if more SPs
> > > were invited to
> > > > > co-author the GMPLS drafts, to help ensure that SP
> > > requirements are more
> > > > > adequately reflected and addressed.
> > > > >
> > > > > Jerry Ash
> > > > > AT&T Labs
> > > > >
> > > > > -----Original Message-----
> > > > > From: George Swallow [mailto:[email-masked]]
> > > > > Sent: Monday, May 14, 2001 1:52 PM
> > > > > To: [email-masked]; [email-masked]
> > > > > Subject: GMPLS Last Calls
> > > > >
> > > > > This message initiates a last call on four GMPLS
> > drafts.  The last
> > > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > > >
> > > > > The drafts are:
> > > > >
> > > > >     1.  Generalized MPLS - Signaling Functional Description
> > > > >
> > > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > > >
> > > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > > >
> > > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > > >
> > > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > > >
> > > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > > >
> > > > > The last call closes May 29, 12 pm GMT.
> > > > >
> > > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > > >
> > > > >
> > >
> > ======================================================================
> > > > > George Swallow       Cisco Systems
> > > (978) 244-8143
> > > > >                      250 Apollo Drive
> > > > >                      Chelmsford, Ma 01824
> > >
> >

Delivery-date: Tue, 29 May 2001 03:42:45 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Cc: "Mak, L (Leen)" <[email-masked]>
Subject: RE: Status of the GMPLS extensions for SONET and SDH control draf t
Date: Tue, 29 May 2001 12:42:17 +0200

Eric,

Last week you gave a nice overview of the Status of the 
GMPLS extensions for SONET and SDH control draft.
I'd like to comment on some statements.
Excerpts from your email are marked by ">". 
My comments are marked by "Comment".

Leen Mak.

> There is up to now no reason to consider transparency and 
> concatenation as 
> being proprietary extensions given the support that these 
> features had from
> the community. 

Comment: what do you mean by community? I have seen only 
a few vendors and no operators speak in favor of this idea on 
the mailing lists. 

> They are implemented/being implemented by many

Comment: can you please substantiate this claim. I would
be happy to know which vendors you are referring to.

> Simply a few people argued that we need new ITU-T standards 
> to support these features,

Comment: to me it appears too that we need new ITU-T standards
to support these features. It is a common industry interest 
to have a clear definition of what is in SDH and what is out.
Even if a feature would be "negotiable" between NEs, there
should be an agreed standard describing what you get if an
NE says "yes" to a request for support of such feature.
The natural home for this is G.707. 

> 
> Please, carefully read the following text that clarifies the 
> contiguous concatenation part of the draft and that 
> introduces one simple new concatenation type.

Comment: this is exactly what should not be done: "introduce
one simple new concatenation type" in an IETF doc.

> Arbitrary contiguous concatenation (as described it in the 
> proposed text)
> don't need any standard, it is just a way to use SDH/SONET. 
> It is already
> implemented since a while by many manufacturers in legacy 
> equipment's. 

Comment: how many? Please substantiate this claim

> Transparency
> at the NNI between two manufacturers needs an agreement to 
> interoperate.
> This agreement can be achieved in very different ways: 
> through the use of a
> standard, an implementation agreement made by a forum, or an 
> implementation
> agreement between two manufacturers (e.g. at the request of 
> an operator).

Comment: Currently, interoperability according to the extended 
concatenation schemes requires obviuously an agreement between 
vendors and/or operators OUTSIDE the standards world (simply 
because these schemes are not in G.707). 
It would be only logical to let the signalling required for them 
be part of the same agreement - OUTSIDE the standards world. 

Delivery-date: Tue, 29 May 2001 03:26:37 -0700
From: "Mannie, Eric" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 12:22:26 +0200

Hello Tony,

>This is not describing just a way to use SONET/SDH as it changes every box
>in the network!

No, it doesn't change any box if you don't use these features. A feature in
GMPLS doesn't mean that you are obliged to use it or to implement it. But
which control plane will you use in your existing boxes ?

I don't think that you will have GMPLS as a simple software upgrade in your
existing ADM's. Obviously you will have to deploy a new cloud with boxes
able to run the control plane (in general you have a dedicated redundant
hardware to run the control plane and a dedicated redundant hardware to run
the routing algorithm in real-time on carrier class equipment's).

Interworking between an "ION" cloud and a non "ION" cloud (i.e. a
traditional SDH/SONET cloud) is another issue.  In that case the control
plane doesn't run on the non ION cloud and you need a manual provisioning
there. Of course you must find a common denominator between the ION cloud
and the non-ION cloud to support end-to-end circuits. However, end-to-end
circuits that stay in the ION cloud will take benefits of the GMPLS features
implemented by your manufacturer.

>To use this there are changes/additions required to G.707 and G.783.

What is important for interoperability is not the definition of a concept in
a document but what is actually send between two nodes.

For arbitrary concatenation you don't change anything to the frame format,
only each node must be able to recognize and treat the pointers and the
VC-4-Xc. This concept is not defined in G.707 and G.783 but this has no
impact. You negotiate this capability between each pair of node, if there is
a node that doesn't support it, the circuit is refused. In addition, we
expect that you will know this capability for each node/interface via the
routing protocol. So the routing algorithm will find directly the adequate
path.

Of course the ASIC's on that path must support the capability, this is an
ASIC implementation issue, not a document issue. A manufacturer can
implement whatever he likes in his ASIC's. GMPLS doesn't define what must be
implemented in the transmission plane to be interoperable (that's the job
for a profile). GMPLS gives tools in the control plane, some tools are
optional of course.

Transparency at the GMPLS UNI has absolutely no impact on existing
standards, the transmission plane and on existing ASIC's. It is only
implemented at NNI. At the UNI this capability is signaled in GMPLS and the
transmission plane doesn't care. At the NNI that will require a standard or
an implementation agreement if and only if multiple vendors are used. So
there are already many interesting scenarios in the short term where this
feature can be helpful. In the long term if you want to go to multiple
vendors you will need to ask them to reach a consensus to be able to
interoperate. That could be easier than you think because transparency is
software selectable for several of them, so when you buy the equipment you
specify where you want to tunnel the overhead bytes.

There is in fact absolutely NO interoperability issue with any of these
features if the circuit is refused when you try to cross a link where the
two ends are incompatible, or where on end doesn't support transparency.
Once again the routing protocol can advertise such capabilities. You can
keep the control of your network in any case.

All these features are "negotiated" when you try to open a circuit, if the
downstream node doesn't support a feature that connection attempt is
refused.

>I do not understand the linkage between GMPLS and concatenation. the two
are
>independent up to the point that you may wish to attempt variable bandwidth
>allocation. At this point extensions to concatenation are requires, and as
I
>have already stated this work is already under discussion in ITU.

GMPLS allows to open a circuit, that circuit can be a concatenated circuit
between two IP routers. Variable bandwidth is orthogonal with that feature
and is also possible with GMPLS if it can be supported by the control plane.
If you are referring to LCAS, this is not a control plane that allows to
open circuits dynamically.

Kind regards,

Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 10:51 AM
To: [email-masked]; [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 02:45:17 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked],  [email-masked]
Cc: [email-masked]
Subject: RE: [IP-Optical] RE: GMPLS Last Calls
Date: Tue, 29 May 2001 10:40:17 +0100

Hi,

I fully agree with Hirokokazu Ishimatsu's concerns on the GMPLS signalling
drafts.

(1) Decoupling of the control plane from the data plane should be clearly
stated.

This decoupling clearly has an impact on how the protocols should be defined
to cope with control plane failures.  

(2) Exclusion of NSAP

The GMPLS architecture document, (which logically speaking should perhaps
have been put forward for last call, ahead of the functional description)
explicitly excludes NSAP.  NSAP addressing is used within SDH/SONET
communications channels (DCC bytes) therefore the use of alternative
addressing within the same channels may have an adverse effect on
interworking with legacy equipment, particularly with regard to management.
This raises the general concern of what level of compatibility is
required/desired with legacy SDH/SONET equipment.  This debate whilst likely
to be contentious, is unavoidable as the interworking of control plane,
management plane and transport will have a direct impact on how this
equipment is deployed and the economics of whether such deployments will
ever pay off.

(3) Requirements from both security and OSS has not been discussed fully
yet.

Security concerns have not been fully addressed, particularly at the
architectural level.  The use of separate control network may necessitate
the need for 24 hour staff to protect against 'Denial of Service' attacks as
currently happens for IP router networks.  The interaction between the
management plane and control plane need to be addressed, for example it is
undesirable to have multiple alarms generated when circuits are created and
torn down otherwise the management of a large scale network will become
impossible.  Discussions on service aspects need to take place, otherwise
the adoption of GMPLS equipment may be hampered, by these (solvable)
concerns.

Best regards

Shehzad Mirza

 

> -----Original Message-----
> From:	Hirokazu Ishimatsu [SMTP:[email-masked]]
> Sent:	29 May 2001 02:46
> To:	George Swallow; ccamp; mpls
> Cc:	ip-optical; tsg15q11; tsg13q10
> Subject:	[IP-Optical] RE: GMPLS Last Calls
> 
> Hi,
> 
> From a carrier's perspective, my concerns about GMPLS signaling drafts
> are as follows:
> 
> (1) Decoupling of the control plane from the data plane should be clearly
>      stated.
> (2) Exclusion of NSAP
> (3) Requirements from both security and OSS (Operating Support System)
>      has not been discussed fully yet.
> 
> Best regards,
> Hirokazu Ishimatsu
> Japan Telecom
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of George Swallow
> > Sent: Tuesday, May 15, 2001 2:52 AM
> > To: [email-masked]; [email-masked]
> > Subject: GMPLS Last Calls
> > 
> > 
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> > 
> > The drafts are:
> > 
> >     1.  Generalized MPLS - Signaling Functional Description
> > 
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > 
> > 
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > 
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > 
> > 
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > 
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > 
> > 
> >     4.  GMPLS Extensions for SONET and SDH Control
> > 
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > 
> > 
> > The last call closes May 29, 12 pm GMT.
> > 
> > 
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > 
> > 
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
> > 
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 02:01:51 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 10:59:07 +0200

Hello Juergen,

Briefly,

> ...if we introduce flexible arbitrary contiguous concatenation

As you said flexible arbitrary contiguous concatenation is NOT part of the
current draft in WG last call. This feature is only being debated on the
mailing list as it was proposed to add it to the draft.

>We also have to state, that the combination of these proprietary features
with other reasonable proprietary or standard features is not always checked
and cannot be guaranteed.

Note that every toolbox has combination of features that doesn't make sense.
Sometimes it belongs to  the manufacturer itself (creativity) to find the
right combinations that could make sense to his customers and that will
differentiate his product from the others.

> It seems a common understanding now that we have at least to identify the
proprietary features

That's agreed but with the right terminology (e.g. not specified by
ITU-T/T1X1 etc).

> (either move them in an informative annex or a separate document). It
seems we don't have consensus to remove them at all.

Correct.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 2:36 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [IP-Optical] Re: Proposed text for the concatena tion

Eric and all,

let me again stress my view.
My major concern is to get usefull standards, RFCs, interworking agreements
or what ever you call it, that don't confuse people. If it is done in the
IETF, ITU, OIF, ... is an secondary issue. All have their pros and cons. As
soon as several bodies get involved it is getting more difficult to
synchronize the activities. With MPLS the IETF had both the transport and
control plane in its hands. With GMPLS it is different. GMPLS defines the
control plane signaling for already existing transport planes defined by
other bodies. Defining a control plane needs in my view solid knowledge of
the underlying transport plane. One of our (the Sonet/SDH guys) faults might
be that we got involved in the discussion to late.
I am following the GMPLS development for some time now and did sent some
comments on the email list over the last months. As I didn't get response
back and the comments seemed to be ignored I was thinking about stoping my
activities on the list. It changed at the Paris editing session when my
proposal for virtual concatenation was included. Thats why my name came on
the author list. But that doesn't mean that I am sure that the whole
document is correct or tht I fully agree with it as I hadn't time to go
through all the details togehter with the other GMPLS IDs. That might also
be the case for other people on the authors list. As I said before I
accepted the proprietary extensions at the Paris session as it seemed to me
that this is the way it works at the IETF (what does rough consensus mean?).
I brought up the issue of flexible arbitrary contiguous concatenation and
that triggered me. We try to define control plane support for a proprietary
transport plane features that we don't know much about. How are we sure that
the control plane support is correct. How are we sure that it can be
combined with other features. As Greg told me in a privat mail (see below)
flexible arbitrary concatenation cannot be supported by the STS group/AUG
signal type as explizit configuration (via management or signaling) of the
time slots is required. However the Sonet/SDH document says 
"STS Group-N is a collection of STS-1 SPE signals whose contiguous
concatenation relationship within the group need not be defined and is
permitted to change during the life of the STS-Group-N."
So that is not correct if we introduce flexible arbitrary contiguous
concatenation.
That is only one point, we may missed others as we don't have all the
information.
If the IETF accepts proprietary features, please make sure that you have the
necessary information. Otherwise you create a mess. Furthermore explizitly
state what is standard and what is not standard. Most readers don't have the
background knowledge of all the discussions we have.

Now how to deal with the proprietary features in the document:
It seems a common understanding now that we have at least to identify the
proprietary features (either move them in an informativ annex or a separate
document). It seems we don't have consensus to remove them at all.
We also have to state, that the combination of these proprietary features
with other reasonable proprietary or standard features is not always checked
and cannot be guaranteed. Note that it is also not possible to combine all
standard features, but that is described in the related standards.

Regards

Juergen

Hi Juergen, see comment below.  

Greg B.

-----Original Message-----
> (1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE
equipment
> and has nice consequences for avoiding re-grooming.
	[Juergen Heiles]  How will you tell the framer the starting time
slot and the remaining timeslots? Via TMN cnfiguration or GMPLS signaling?
Not in-band using some SOH? If you also want to support the STS Group, AUG
or partially transparent signal type defined in GMPLS you need the in-band
information.

*** This is what GMPLS or some kind of signaling protocol is good for. But
of course I can set it up via management too. A set of time slot numbers vs.
a set of numbers! What's the big deal...  Now in-band I can run GMPLS over a
DCC channel so I don't really differentiate between this and GMPLS (or any
other signaling protocol based method).
The STS Group concept/transparency:  Yes, you're right I wouldn't support
the "arbitrary concatenation" over this.  Since, its a "transparent" service
and the concatenation must be automatically detected, i.e., without
signaling.  

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Tue, 29 May 2001 02:00:11 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Tue, 29 May 2001 09:51:23 +0100

Eric,

This is not describing just a way to use SONET/SDH as it changes every box
in the network! To use this there are changes/additions required to G,707
and G.783.

Neither is this a new feature. Concatenation is already described and
explained.

I do not understand the linkage between GMPLS and concatenation. the two are
independent up to the point that you may wish to attempt variable bandwidth
allocation. At this point extensions to concatenation are requires, and as I
have already stated this work is already under discussion in ITU.

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 28 May 2001 12:06
To: 'Rob Coltun'; John Drake
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Tue, 29 May 2001 01:14:53 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, "Kullberg, Alan" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 29 May 2001 10:12:55 +0200

Hello Juergen

>hierachical LSP setup in Sonet/SDH and other transport planes is an issue
currently not addressed by GMPLS. The Sonet/SDH naming tree (TDM-LSR link
lable) for example doesn't fit with independent higher and lower order VC
setup.

Sorry, but you misunderstood it completely. In addition this is explained in
the draft. It doesn't make any sense to apply GMPLS to SONET/SDH without a
powerful hierarchical LSP setup. The same apply to other technologies. 

Hierarchical LSP setup is one of the first thing that we thought about. One
of the added-value of MPLS is exactly that it fits very well with
hierarchical LSP setup. This concept is a fundamental one in GMPLS for
SONET/SDH. See after.

>For example the route of a VC-4 may change (use different STM-N ports at
the equipment) while the endpoints are still the same. The VC-12 transported
via these VC-4 don't have to care about the STM-N port only about the VC-4
endpoints. The current definition requires the port and full multiplex
structure. AS not much thoughts are spent on the issue the current
definition might not work with future extensions that support hierachical
structures.

On the contrary this issue requested a lot of thought. Hierarchical LSP
setup is explained in the draft. In addition one of the reasons to introduce
AUG-X and STS Groups was to enable more forms of hierarchical LSP setups
(see after).

About the label don't confuse the coding and the usage. We designed the
label specifically to support hierarchical LSP setup. When you code a label
of course you don't have to encode the full multiplex structure. Either you
code:

 - the higher part
 - the lower part
 - a middle part
 - the full label

Where higher, lower and middle have flexible boundaries and are relative to
the link (forwarding adjacency) in which it is. Per the MPLS definition, a
label is local to an interface/link between two nodes. If this link is a
VC-4 link (i.e. a circuit established with GMPLS and advertised as link in
the routing protocol), you can open a VC-12 circuit through that link. In
that case the label for the VC-12 indicates where is the VC-12 in the VC-4
circuit. As a side effect that will fix the allocation of a TUG-2 and TUG-3
at the interface. It will be the responsibility of a local algorithm to
decide which TUG-2 and which TUG-3 to "allocate". Of course these TUG-2 and
TUG-3 cannot be used anymore to carry a VC-3. The two TUG-3 that left can be
used to carry a VC-3.

This is just an example, you could prefer to open first a TUG-3 circuit,
then a TUG-2 circuit in that TUG-3 and then finally the VC-12 circuit in the
TUG-2 circuit. The way that the user wants to allocate circuits and/or what
is implemented by the manufacturer is of course not defined in the draft.

By the way this is another reason why TUG-3, TUG-2 and VTG are important as
signal types. They allow to specify the allocation in the multiplex level
("layer") per level. The same applies to AUG-X and STS Groups.

Having a 32 bit value for the label allowing to code, in the most complex
case, a position in the full multiplex or in any subtree is very powerful.

If you would like to do it with different label types, you would need a lot
of label types, probably more than 20 different types. Instead we have one
single and simple label.

Please see the explanations in section 3 of the draft.

Kind regards,

Eric

> -----Original Message-----
> From:	Kullberg, Alan [SMTP:[email-masked]]
> Sent:	Thursday, May 24, 2001 5:44 PM
> To:	'Mannie, Eric'; 'Kireeti Kompella'
> Cc:	[email-masked]'; [email-masked]'
> Subject:	last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> The following paragraph is from section 3 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt.
> 
>   When hierarchical SDH/SONET LSPs are used, an LSP with a given
>    bandwidth can be used to tunnel lower order LSPs.  The higher
>    order SDH/SONET LSP behaves as a virtual link with a given
>    bandwidth (e.g. VC-3), it may also be used as a Forwarding
>    Adjacency. A lower order SDH/SONET LSP can be established through
>    that higher order LSP. Since a label is local to a (virtual) link,
>    the highest part of that label is non-significant and is set to
>    zero.
> 
> The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
> defined for TDM Switch Capable.  In order to support the hierarchy in the
> above paragraph, TDM Switch Capable would need to be split into multiple
> values, one for each level of the SDH/SONET multiplexing structure.
> 
> What do you think?
> 
> Alan
> 

Delivery-date: Tue, 29 May 2001 00:44:02 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, "'Saha, Sayandeb'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 29 May 2001 09:42:04 +0200

Hello Juergen,

>Requesting section/line overhead transparency but limiting the paylaod to a
STS-48-c-SPE doesn't make much sense to me.

An STS-48c signal with LOH DCC and E2 transparency is just an example to
illustrate the coding, not more as you said. That's right that this type of
signal is probably not very useful, it is not always easy rto find coding
examples for complex cases that make sense. But anyway, if somebody wants to
have a transparent STS-48c he can.

Of course if you want to have another "organisation" for the payload you can
provision an STS-48 circuit and then structure it as you like.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 2:37 AM
To: Mannie, Eric; 'Saha, Sayandeb'
Cc: [email-masked]'; [email-masked]'
Subject: RE: Editorial comments on
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

Eric,

that was one point I commented onthe draft version of the Sonet/SDH
document. Requesting section/line overhead transparency but limiting the
paylaod to a STS-48-c-SPE doesn't make much sense to me. Transparency at the
line/section layer but not at the path layer. Ok you could code it, but not
everything you can combine is usefull and we better avoid to define such
examples.

Regards

Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Wednesday, May 23, 2001 10:08 PM
> To:	'Saha, Sayandeb'
> Cc:	[email-masked]'; [email-masked]'
> Subject:	RE: Editorial comments on
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> Dear Sayan,
> 
> Thanks for the comments. However note that when requesting transparency
for
> an STS-48 signal for instance, the signal type to use is STS-48. You cant'
> concatenate STS-1's since concatenation of STS-1 is not defined, but
> concatenation of STS-1 SPE's is. If you ask the concatenation of 48 x
STS-1
> SPE's you are not speaking about the frame with its overhead, so you
cannot
> request transparency. So we took the decision to use well defined signal
> types when requesting transparency (e.g. STS-48). And we took the
convention
> to indicate in NCC the number of SPE's in that signal that must be
> concatenated. It took us some time to find a way to code each possible
> signal in a non ambiguous way. So I the original examples are correct.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Saha, Sayandeb [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 9:10 PM
> To: Mannie, Eric
> Cc: [email-masked]'; [email-masked]'
> Subject: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt 
> 
> 
> Hi ALL,
> I noticed the following in section 4 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt .
> 
>  The example number 16 is ...
> 
> 16. An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-48
>    Elementary Signal.
> 
> It should be 
> 
>    An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-1 SPE
>    Elementary Signal.
> 
> The example number 17 is ...
> 
> 17. An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-768 Elementary Signal.
> 
> It should be 
> 
>    An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-1 SPE Elementary Signal.
> 
> Regards
> -Sayan
> 
> 
> 
> 

Delivery-date: Tue, 29 May 2001 00:38:58 -0700
From: Jonathan Lang <[email-masked]>
To: Dimitrios Pendarakis <[email-masked]>, 'Jonathan Lang' <[email-masked]>, 'Fong Liaw' <[email-masked]>, 'suresh Katukam' <[email-masked]>
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Tue, 29 May 2001 00:34:29 -0700

Dimitrios,
  If you're using the RSVP Hello to detect the failure of the RSVP module
only, then this is fine.  If you're using the RSVP Hello to detect (or
rather, infer) control channel failures, I have a problem.  For starters, I
don't think it works for parallel (redundant) control channels; if control
channel redundancy is *not* important for SPs, then it's not as much of an
issue, however, I think you're overloading the semantics of the RSVP Hello.

  See additional comments inline.

Thanks,
Jonathan

> 
> Hi Jonathan,
> 
> What needs to be detected here is the inability to send and 
> receive signaling messages to and from your RSVP peer. In this 
> respect, using RSVP Hello is a more accurate mechanism for 
> detecting failures since it is part of the RSVP protocol and 
> independent of the link layer used to realize the control 
> channel. As you point out, if you prefer redundant control 
> channels for resiliency, and want to rely on LMP only, you have
> to correlate all LMP detected failures in order to declare a 
> control channel failure.
This is not correct.  LMP allows you to detect individual control channel
failures, even when there are multiple (redundant) control channels.  The
RSVP Hello cannot do this.

> With RSVP Hello you would rely on a 
> single set of event(s) to detect the failure.
To be clear, the failure of the RSVP module.

> To go even further, what if all your control channels are working
> fine, but your RSVP daemon has crashed, for whatever reason.
> LMP hellos will keep going across but RSVP messages will not...
This is where the RSVP Hello has its place.

> 
> All this points to the (certainly non-trivial) problem of failure 
> detection and correlation at different layers. I am not trying to
> say that RSVP Hello is the perfect or only mechanism we should rely 
> on, but it certainly has a place in addressing the problem.
agreed.  see above comment.

> 
> Thanks,
> Dimitris
> 
> PS. Hopefully we are not too far apart so we might not have
> to keep the discussion going for too long :-)
> In any case I believe it has some relevance here as well.
> 
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 6:56 PM
> > To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; 'suresh
> > Katukam'; [email-masked]
> > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > Subject: RE: Last call - RSVP problems
> > 
> > 
> > Dimitris,
> >   The RSVP Hello Extension is intended to detect node 
> failures and not
> > necessarily link (control channel) failures.  In particular, 
> > the tunnel
> > draft says, "It should be noted that node failure detection 
> > is not the same
> > as a link failure detection mechanism, particularly in the 
> > case of multiple
> > parallel unnumbered links."  What happens if you want 
> > redundant control
> > channels for control-channel resiliency?  I believe you would 
> > still want a
> > mechanism to detect control channel (link-layer) failures.
> > 
> >   In LMP, you can have multiple active control channels 
> > between a pair of
> > nodes.  You can configure control channels over shared 
> > Ethernet and over
> > SONET/SDH overhead, etc.  You send keep-alive Hellos over 
> each control
> > channel.  If you so desire, you can send all signaling 
> > messages over the
> > Ethernet control channels.  You can also choose to send all 
> > remaining LMP
> > messages over the SONET/SDH-based control channels.  Keeping 
> > RSVP Hellos as
> > "optional" would be fine.  Making them mandatory doesn't seem 
> > like the right
> > solution.
> > 
> > Thanks,
> > Jonathan
> > 
> > P.S.  Should we move this discussion on the OIF list??
> > 
> > > -----Original Message-----
> > > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 3:16 PM
> > > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; 
> > [email-masked]
> > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > Subject: RE: Last call - RSVP problems
> > > 
> > > 
> > > Hi Jonathan,
> > > 
> > > One point to consider is that the signaling control 
> > > channel might be realized over a different link layer 
> > > than LMP. For example, LMP might be running in-fiber
> > > over SONET/SDH overhead bytes, while RSVP is running 
> > > over an out-of-band network such a shared Ethernet.
> > > RSVP Hello allows independent detection of signaling 
> > > channel failure, so it's a useful option to keep.
> > > 
> > > Thanks,
> > > Dimitris
> > > 
> > > Dimitris Pendarakis
> > > Tellium, Inc.
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Jonathan Lang [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 5:30 PM
> > > > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > > Subject: RE: Last call - RSVP problems
> > > > 
> > > > 
> > > > Fong,
> > > > 
> > > > 
> > > > <snip>
> > > > > Same as (2), any proposals that remove the refresh mechanism 
> > > > > is going to be difficult to prove that all cases are covered.
> > > > > 
> > > > > Instead, we (will) recommend the following in OIF UNI 
> document:
> > > > >    
> > > > >    Use RSVP Hello to detect control channel failure.
> > > > Why wouldn't you use the LMP Hello to detect control channel 
> > > > failure?  This
> > > > is exactly what it is designed for.  From 
> > > > draft-ietf-mpls-lsp-tunnel-08.txt,
> > > > 
> > > >   "This (RSVP Hello) mechanism is intended to be used when 
> > > > notification of
> > > > link layer
> > > >    failures is not available and unnumbered links are not 
> > > > used, or when
> > > >    the failure detection mechanisms provided by the link 
> > > layer are not
> > > >    sufficient for timely node failure detection."
> > > >  
> > > > >    If a control channel failure is detected, LSPs states 
> > > > >    are maintained as if a node continues to receive 
> > > > >    RSVP refresh message from the failed control channel.
> > > > >    The recommended Hello timer will be in second range,
> > > > >    instead of ms range specified in RSVP-TE draft.  
> > > > > 
> > > > >    If a control channel failed permanently, manual 
> intervention 
> > > > >    may be required. This is to be studied.
> > > > > 
> > > > > p.s The text is currently being drafted as we type.
> > > > 
> > > 
> > 
> 

Delivery-date: Tue, 29 May 2001 00:38:56 -0700
From: Jonathan Lang <[email-masked]>
To: Bala Rajagopalan <[email-masked]>, "'Mannie, Eric'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], q16/15 <[email-masked]>
Subject: RE: [IP-Optical] RE: Dead of GMPLS ?
Date: Tue, 29 May 2001 00:34:30 -0700

Bala,
> 
> Eric:
> 
> I understand your frustration, but the current
> state of affairs was waiting to happen given the
> speed and zeal with which all sorts of features
> were being proposed as candidates for GMPLS control.
I'm not sure what you mean here.  The GMPLS work has been going on since
late 1999.  There have been relatively few new features added since we met
in Adelaide.  In fact, much of (what I would call) zealous material in the
first version has actually been removed.

> I think the best way to move forward is to
> get some consensus on the set of well-defined
> features/capabilities that
> people agree have *current relevance*.
I thought that's what we had done in Paris.  Eric, Greg, Heiles, Dimitri,
Eve, Dimitirios, myself, and others were in this meeting.  What I find
strange is that some of these same people are now arguing against what we
all agreed to back then.

> Other features, drop them/move to different drafts/what not.
> It doesn't seem sensible to stop progress
> on the most general aspects of gmpls for the
> sake of supporting features whose 
> near-to-intermediate term
> significance is dubious.
I'm not sure about your assessment of the significance, but I agree that we
shouldn't stop progress on the general aspects of gmpls.

Thanks,
Jonathan

> 
> Regards,
>    
> 
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: Mannie, Eric [mailto:[email-masked]]
> > Sent: Monday, May 28, 2001 11:37 AM
> > To: 'Guo-Qiang Wang'
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; q16/15; John Drake
> > Subject: RE: Dead of GMPLS ?
> > 
> > 
> > Hello Guo-Qiang,
> > 
> > >  If one non-SONET/SDH-standard feature could decide the 
> death or the
> > liveness 
> > of GMPLS, it is the reason I strongly suggest you guys remove 
> > this feature 
> > to a separate document to keep GMPLS alive.  Up to now, all 
> > the arguments we
> > have 
> > seen are focusing on non-SONET/SDH-standard issue, not on 
> > lambda switching
> > and fiber switching. 
> > 
> > No, please read the included e-mails and the e-mails that I 
> > was referred to,
> > they are talking about waveband switching, etc..
> > 
> > We are now speaking about removing waveband switching, about 
> > where to put
> > protection/restoration, and about scanning all the GMPLS 
> > drafts to see what
> > should be removed (see the three e-mails from Maarten).
> > 
> > I am discussing the general principle of moving all 
> > non-standard related
> > features to separate documents. If you want to do it for 
> > technology A, to
> > stay consistent you have to do it also for technology B, C, etc.
> > 
> > Of course you have to remove lambda switching since this is 
> > proprietary
> > (what are the parameters to control, to signal, etc... we 
> > don't know yet) -
> > It is too early in this draft to speak about that before 
> > knowing how exactly
> > the transmission plane will look like. There is no value of having a
> > standardized control plane to control proprietary networks (as I
> > understood).
> > 
> > My list of features to remove contains at least:
> > 
> > - SDH/SONET transparency.
> > - SDH/SONET arbitrary concatenation, flexible concatenation.
> > - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> > - All kinds of end-to-end protection/restoration for any 
> > layer, except the
> > IP layer.
> > - The Waveband switching object and its concept.
> > - The concept of LSC and FSC layers, i.e. concept of lambda 
> and fiber
> > switching.
> > - The label set object (only used for lambda issues).
> > - LSP encoding type, bandwidth encoding and GPID have to be 
> simplified
> > accordingly.
> > - MPLS extensions to control G.709 (since multiplexing, etc 
> is not yet
> > defined).
> > - etc...
> > 
> > Something else to add to this list ?
> > 
> > Rgds,
> > 
> > Eric
> > 
> > 
> > 
> > -----Original Message-----
> > From: Guo-Qiang Wang [mailto:[email-masked]]
> > Sent: Monday, May 28, 2001 4:24 PM
> > To: Mannie, Eric; 'Maarten Vissers'
> > Cc: 'Yuri Landry'; [email-masked]; 
> [email-masked];
> > [email-masked]; [email-masked]; q16/15; John Drake
> > Subject: RE: Dead of GMPLS ?
> > 
> > 
> > Hi, 
> >   If one non-SONET/SDH-standard feature could decide the 
> death or the
> > liveness 
> > of GMPLS, it is the reason I strongly suggest you guys remove 
> > this feature 
> > to a separate document to keep GMPLS alive. Up to now, all 
> > the arguments we
> > have 
> > seen are focusing on non-SONET/SDH-standard issue, not on 
> > lambda switching
> > and fiber switching. 
> >   Regards,  
> > G.Q Wang 
> > Technical Manager 
> > Emerging Network Technology 
> > Nortel Networks 
> > Tel: (613)765-4195 (ESN 395-4195) 
> > Fax: (613)768-1140 
> > [email-masked] 
> > -----Original Message----- 
> > From:   Mannie, Eric [SMTP:[email-masked]] 
> > Sent:   Monday, May 28, 2001 9:08 AM 
> > To:     'Maarten Vissers' 
> > Cc:     'Yuri Landry'; [email-masked]; 
> > [email-masked];
> > [email-masked]; [email-masked]; q16/15; John Drake
> > Subject:        Dead of GMPLS ? 
> > Hello Maarten, 
> > E-mail 1: 
> > >Let's review the series of GMPLS 
> >                   ^^^^^^ 
> > >draft documents to identify the non/pre-standard items and 
> then move 
> > >those items into separate Informational documents. 
> > ^                          ^^^^^^^^^^^^^^^^^^^^^^^ 
> > E-mail 2: 
> > > Yuri started the discussion on wavebands some days ago. 
> > Wavebands are 
> > > yet undefined in the transport plane. 
> >       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > E-mail 3: 
> > >Triggered by Yuri's email, I would like to offer another 
> > area for closer 
> > >look: protection switching. The standardised SDH protection 
> > switching 
> > >schemes are specified in G.841 with further support in G.783. 
> > > 
> > >When reading the protection switching text some time ago in 
> > the GMPLs 
> > >draft I noticed several extensions to be described beyond those in 
> > >G.841. 
> > > 
> > >My request is to review the latest text against G.841/G.783, 
> > identify 
> > >the extensions and (as now proposed by several of us) move those 
> > >extensions into a separate Informational document. 
> >  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> > The transmission plane for optical networks is not 
> standardized: DWDM 
> > systems are proprietary and don't interoperate. 
> > So I guess that we have to remove the concept of optical 
> > switching (lambda 
> > switching, fiber switching, waveband switching) from GMPLS if 
> > we want to 
> > follow your model of thinking. We also have to remove any 
> end-to-end 
> > protection/restoration and all non standardized SDH/SONET 
> > behaviors (even if
> > 
> > they don't change the standards) as you said. 
> > Everything will become informational, except may be a very 
> small root 
> > specification (that will not be allowed to speak about any optical 
> > switching). 
> > Since the IETF will not have any standard (track) RFC, ITU-T 
> > will have to 
> > claim that there is no existing standard and do one... 
> > What is the benefit of moving all the interesting signaling 
> > features to 
> > informational RFC's ? If we don't have signaling standards 
> > why should we 
> > continue to work on GMPLS ? Why should we spend so much energy of 
> > informational documents that have no standard value ? That 
> > will be an easy 
> > marketing message "GMPLS: don't pay attention to it, it is only 
> > informational, you need a standard". 
> > Either GMPLS is dead, or we accept that GMPLS ALLOWS TO 
> > CONTROL STANDARDIZED
> > 
> > AND NON STANDARDIZED DATA/TRANSMISSION PLANES. 
> > Regards, 
> > Eric 
> > -----Original Message----- 
> > From: Maarten Vissers [mailto:[email-masked]] 
> > Sent: Monday, May 28, 2001 11:03 AM 
> > To: John Drake 
> > Cc: 'Yuri Landry'; [email-masked]; 
> > [email-masked]; 
> > [email-masked]; [email-masked]; q16/15 
> > Subject: [IP-Optical] GMPLS: waveband switching 
> > 
> > 
> > John, 
> > Yuri started the discussion on wavebands some days ago. 
> Wavebands are 
> > yet undefined in the transport plane. Looking into it a few 
> > days ago, I 
> > tried to provide a definition of waveband and got immediately 
> > corrected 
> > by an optical expert, resulting in an adapted definition of 
> waveband 
> > (see email below). 
> > At this point in time, a waveband seems to be a group of 
> > Optical Channel 
> > (OCh) signals. It represents a partition, not a new layer 
> network. As 
> > such a waveband should be represented as a "group of OCh 
> > signals" within 
> > the OCh layer network. 
> > Regards, 
> > Maarten 
> > 
> > 
> > 
> > Maarten Vissers wrote: 
> > > 
> > > Manoj, Yuri, 
> > > 
> > > I received a message that my definition of waveband is too 
> > restricted. 
> > > 
> > > A waveband should be an optical multiplex, administered 
> as a single 
> > > bundle, not necessary contiguous in frequency slot. 
> > > 
> > >         E.g. there may be good technical reasons to consider a 
> > >         'waveband' created at an OADM formed by taking every 2nd 
> > >         wavelength in a 50GHz-spaced transmission band. 
> > > 
> > > In first instance the above definition may not be 
> > considered this as a 
> > > "band"; it 
> > > looks more like a "gapped-band" :-). Nevertheless, due to 
> technical 
> > > reasons we should consider a waveband as just another name for a 
> > > particular group of wavelengths, which may best be viewed 
> > as a group of 
> > > identified/listed wavelengths. 
> > > 
> > > Regards, 
> > > 
> > > Maarten 
> > > 
> > > Maarten Vissers wrote: 
> > > > 
> > > > Manoj, Yuri, 
> > > > 
> > > > In my current understanding, a waveband is a group of OCh 
> > (optical 
> > > > channel) signals located in a contiguous set of tributary (i.e. 
> > > > frequency) slots. 
> > > > 
> > > > A waveband is therefore related to partitioning, rather 
> > than a layering.
> > 
> > > > A waveband shouldn't have an LSP encoding type itself, 
> > but instead be 
> > > > part of the OCh layer network. E.g. a specific RGT 
> > (requested groupting 
> > > > type) of "contiguous waveband" can be defined for this 
> > purpose with the 
> > > > RNC (requested number of components) indicating the size of the 
> > > > waveband. 
> > > > 
> > > > The above is simply a first shot; in general the issue 
> > can be more 
> > > > complex due to the fact that the frequency slot for a 
> > 2G5, a 10G and a 
> > > > 40G signal may have differnet bandwidths: e.g. 2G5 freq. 
> > slot width e.g.
> > 
> > > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. 
> > slot width e.g. 
> > > > 100 GHz. For the case of (future?) mixed rate WDM signals 
> > with bit rate 
> > > > optimized freq. slot widths, a waveband might need a 
> > start-of-waveband 
> > > > and end-of-waveband (SOW-EOW) indication, instead of RNC. 
> > > > 
> > > > Regards, 
> > > > 
> > > > Maarten 
> > > > 
> > > > Yuri Landry wrote: 
> > > > > 
> > > > > Mano, 
> > > > > 
> > > > > >            Can someone tell me the message 
> structure of Label 
> > Request and 
> > > > > >Label Mapping in GMPLS ? 
> > > > > >I am confused about the presence of LightPath Id in 
> > O-UNI messages 
> > and LSP 
> > > > > >Id in GMPLS messages ? Is there one-to-one mapping 
> > between these Ids 
> > or Is 
> > > > > >it like that both lightPath Id and LSP Id will be 
> > carried in GMPLS 
> > messages 
> > > > > >? LSP Id is not present in O-UNI messages. Can one 
> > LightPath Id be 
> > mapped 
> > > > > >to 
> > > > > >multiple LSP Ids or vice versa ? 
> > > > > 
> > > > > I think you mean Connection ID and LSP ID. A connection 
> > ID is an ID 
> > for 
> > > > > network connection, which may consist many LSPs. For 
> > example, the 
> > virtual 
> > > > > concatenation case. 
> > > > > 
> > > > > A LSP may tunnel through multiple pre-established 
> connections. 
> > > > > 
> > > > > >Also, for waveband switching, the genralized label has 
> > the format 
> > > > > >(wavebandId - start label - end label). 
> > > > > >When the label request message is received on incoming 
> > interface, how
> > 
> > to 
> > > > > >identify that the waveband label is requested ? 
> > > > > >Is it the LSP encoding type or some other parameter in 
> > label request 
> > > > > >message 
> > > > > >? If it is the Lambda encoding type then how to 
> > identify that whether
> > 
> > a 
> > > > > >lambda or waveband label is requested ? 
> > > > > > 
> > > > > >Also, it is mentioned that wavebandId (32 bits) is 
> > selected by the 
> > sender 
> > > > > >and reused in all the subsequent messages. What all 
> subsequent 
> > > > > >messages is it mentioning to ? 
> > > > > > 
> > > > > >Can wavebandId be present in Label Withdraw/Release 
> messages ? 
> > > > > > 
> > > > > >I am not able to workout the message structures for GMPLS. 
> > > > > > 
> > > > > 
> > > > > To me waveband label defined in GMPLS drafts is a joke. 
> > The reason to 
> > have 
> > > > > the waveband label is that someone claimed that the 
> > waveband's order 
> > might 
> > > > > flip when going through a switch. My suggestion is 
> > don't take it 
> > seriously. 
> > > > > 
> > > > > >I am not sure how these drafts are at last call. 
> > Atleast it should 
> > mention 
> > > > > >the message structures of various messages. 
> > > > > > 
> > > > > 
> > > > > Agree. 
> > > > > 
> > > > > Regards, 
> > > > > 
> > > > > Yuri 
> > > > > 
> > _________________________________________________________________ 
> > > > > Get your FREE download of MSN Explorer at 
> > http://explorer.msn.com 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > John Drake wrote: 
> > > 
> > > Yuri, 
> > > 
> > > I've attached a private note I sent to Dimitri regarding waveband 
> > switching. 
> > > It was originally put in at the suggestion of NorTel.  For 
> > both waveband 
> > > switching and fiber switching, you are dealing with a 
> > situation in which 
> > you 
> > > are using a standardized control plane to establish a 
> > multi-hop LSP with 
> > > proprietary encoding of data.  As I mentioned, this would 
> > be accomplished 
> > > using link coloring. 
> > > 
> > > Personally, I have no problem removing either waveband 
> > switching or fiber 
> > > switching, but we know have to accomodate them wrt the 
> > control plane, and 
> > I 
> > > seriously doubt that there will ever be a completely 
> > non-proprietary of 
> > > encoding the data for these types of LSPs. 
> > > 
> > > Note that I am using 'proprietary' in the exclusive sense. 
> > > 
> > > Thanks, 
> > > 
> > > John 
> > > -----Original Message----- 
> > > From: John Drake 
> > > Sent: Wednesday, March 28, 2001 11:15 AM 
> > > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger 
> > > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked] 
> > > Subject: RE: Waveband Switching (was Re: GMPLS signaling) 
> > > 
> > > Dimitri. 
> > > 
> > > It's probably better to think of waveband switching as a 
> > special form of 
> > > fiber switching; i.e., it has nothing to do with the 
> > SONET/SDH stuff at 
> > all. 
> > > Suppose the trunk side of a DWDM system is attached to a 
> > PXC.  In the 
> > fiber 
> > > switching case, the fiber between the DWDM system and a 
> > port on the PXC 
> > > contains the entire set of lambdas, while in the waveband 
> > switching case 
> > > there is a set of fibers between the DWDM system and a set 
> > of ports on the
> > 
> > > PXC, each of which contains a separate waveband. 
> > > 
> > > In either case, the encoding of the signal on the fibers is 
> > completely 
> > > proprietary, and it's the job of routing to ensure that a 
> > correct path 
> > > through the network is obtained, such that the proprietary 
> > encoding is 
> > > maintained end-end.  This would probably be done through 
> > link coloring, so
> > 
> > > that you only route across links that support NorTel 
> > waveband switching or
> > 
> > > Tellabs waveband switching. 
> > > 
> > > So I think the signalling stuff is fine. 
> > > 
> > > Thanks, 
> > > 
> > > John 
> > > 
> > > -----Original Message----- 
> > > From: Yuri Landry [mailto:[email-masked]] 
> > > Sent: Friday, May 25, 2001 7:02 AM 
> > > To: [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked] 
> > > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > > concatena tion 
> > > 
> > > Hello All, 
> > > 
> > > So far, our discussions are focusing on the SONET/SDH 
> > draft. I'd like to 
> > > re-direct your attention to other drafts. Rob's suggestion 
> > should apply to
> > 
> > > other drafts too. 
> > > 
> > > One example, is the waveband switching and waveband label a 
> > standard or 
> > > proprietary? Can author explain to me what exactly they 
> > means? How do they
> > 
> > > work? Any other standard reference? There are questions 
> > about it but no 
> > > answer yet. 
> > > 
> > > Regards, 
> > > 
> > > Yuri. 
> > > 
> > > >From: "Lazer, Monica A, NNAD" <[email-masked]> 
> > > >To: "'Rob Coltun'" <[email-masked]>, [email-masked], 
> > > >[email-masked], q11/15 <[email-masked]>, 
> >   "t1x1.5" 
> > > ><[email-masked]> 
> > > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > concatena 
> > > >tion 
> > > >Date: Thu, 24 May 2001 18:11:36 -0400 
> > > > 
> > > > 
> > > >Rob, You proposal makes a lot of sense. Having the 
> > signaling standard 
> > > >support proprietary transport may jeopardize 
> > interoperability. The issue 
> > is 
> > > >not about GMPLS supporting non-standard rates, the issue 
> > is about putting
> > 
> > > >in 
> > > >formal and very specific support for a proprietary 
> > transport solution in 
> > a 
> > > >standard document for signaling without taking the 
> > transport portion to a
> > 
> > > >standards body. Having formal signaling support for a 
> proprietary 
> > > >concatenation may cause interoperability issues when other 
> > vendors have a
> > 
> > > >different solution to the concatenation and while the 
> > signaling would 
> > > >indicate the concatenation, the actual transport may not 
> > work.   On the 
> > > >other hand we recognize that there may be a need for some 
> > interim support
> > 
> > > >for proprietary solutions. 
> > > > 
> > > > 
> > > >Eric, 
> > > >Below I have some additional specific comments for the 
> > document GMPLS 
> > > >Extensions for SONET and SDH Control 
> > > > 
> > > > 
> > > >CCT field (3 bits) 
> > > >Since arbitrary contiguous concatenation is not a standard 
> > concatenation,
> > 
> > > >it 
> > > >falls within the vendor proprietary set of solutions. 
> > > > 
> > > >So the CCT bits may be used as follows: 
> > > >000    No contiguous concatenation requested 
> > > >001    Standard contiguous concatenation 
> > > >others Vendor specific contiguous concatenation 
> > > > 
> > > >Alternatively, a better solution is to use only 2 bits for 
> > this field and
> > 
> > > >use one bit to show whether contiguous concatenation is 
> > requested and the
> > 
> > > >second bit to show whether it is standard or non-standard 
> > contiguous 
> > > >concatenation. 
> > > > 
> > > > 
> > > >NCC field (16 bits) 
> > > >This information is not sufficient. 
> > > >NCC needs better description than a zero or non-zero number. 
> > > > 
> > > >SDH and SONET Labels 
> > > > 
> > > >Text in this section (Section 3, paragraphs 5 and 6) 
> > indicates that the 
> > > >GMPLS proposal limits virtual concatenation to remain 
> > within a single 
> > > >(component) link. If I understand this correctly, it means 
> > that GMPLS 
> > will 
> > > >not allow inverse multiplexing (virtual concatenation) in 
> > the transport 
> > > >plane if it requires different component links. This is 
> > too limiting. 
> > > > 
> > > >Annex 1 (sent out by Eric Mannie on 5/22) 
> > > >Defines another type of concatenation - Flexible arbitrary 
> > contiguous 
> > > >concatenation without describing precisely how it affects 
> > the OH bits. 
> > This 
> > > >means that it will be impossible to have this type of 
> > concatenation in a 
> > > >multi vendor environment based only on the GMPLS 
> signaling. If the 
> > > >transport 
> > > >plane is proprietary, having the option in the signaling 
> > message will not
> > 
> > > >fix the interoperability problem between two different 
> > vendors supporting
> > 
> > > >their proprietary versions of arbitrary concatenation. 
> > > > 
> > > >Annex 2 (sent out by Eric Mannie on 5/22) 
> > > >Arbitrary contiguous concatenation needs definition work for 
> > > >interoperability. 
> > > >Flexible arbitrary contiguous concatenation may be 
> > available today to 
> > > >support contiguous signals, but it is not defined in the current 
> > standards. 
> > > >Clear agreements on OH usage are needed between supporting 
> > vendors. 
> > > >Maintenance and tracking of the signal needs to be well 
> > understood. 
> > > > 
> > > > 
> > > > 
> > > >Monica A. Lazer 
> > > >Advanced Transport Technology and Architecture Planning 
> > > > 
> > > >908 234 8462 
> > > >[email-masked] 
> > > > 
> > > > 
> > > >-----Original Message----- 
> > > >From: Rob Coltun [mailto:[email-masked]] 
> > > >Sent: Thursday, May 24, 2001 7:24 PM 
> > > >To: [email-masked]; [email-masked]; 
> > q11/15; t1x1.5 
> > > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > > >concatenation 
> > > > 
> > > >All, 
> > > >     despite the heated arguments I think the discussion 
> > is important to 
> > > >have. 
> > > > 
> > > >I suggest that instead of  tagging non/pre-standard items 
> > in the current 
> > > >drafts 
> > > >that they be put into a separate Informational document  - 
> > this is the 
> > > >cleanest thing to do. 
> > > >We (the IETF) do have a tradition of publishing company 
> > proprietary 
> > > >protocols 
> > > >but not as standard track documents. 
> > > > 
> > > >thanks, 
> > > >---rob 
> > > > 
> > > > 
> > > > 
> > > >_______________________________________________ 
> > > >IP-Optical mailing list 
> > > >[email-masked] 
> > > >http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> > > > 
> > > 
> > > _________________________________________________________________ 
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com 
> > > 
> > > _______________________________________________ 
> > > IP-Optical mailing list 
> > > [email-masked] 
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> > 
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
> 

Delivery-date: Mon, 28 May 2001 18:44:07 -0700
From: "Hirokazu Ishimatsu" <[email-masked]>
To: "George Swallow" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: GMPLS Last Calls
Date: Tue, 29 May 2001 10:45:47 +0900

Hi,

>From a carrier's perspective, my concerns about GMPLS signaling drafts
are as follows:

(1) Decoupling of the control plane from the data plane should be clearly
     stated.
(2) Exclusion of NSAP
(3) Requirements from both security and OSS (Operating Support System)
     has not been discussed fully yet.

Best regards,
Hirokazu Ishimatsu
Japan Telecom

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of George Swallow
> Sent: Tuesday, May 15, 2001 2:52 AM
> To: [email-masked]; [email-masked]
> Subject: GMPLS Last Calls
> 
> 
> This message initiates a last call on four GMPLS drafts.  The last
> call is being issued jointly in the MPLS and CCAMP workgroups.
> 
> The drafts are:
> 
>     1.  Generalized MPLS - Signaling Functional Description
> 
>            <draft-ietf-mpls-generalized-signaling-04.txt>
> 
> 
>     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> 
>            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> 
> 
>     3.  Generalized MPLS Signaling - CR-LDP Extensions
> 
>            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> 
> 
>     4.  GMPLS Extensions for SONET and SDH Control
> 
>            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> 
> 
> The last call closes May 29, 12 pm GMT.
> 
> 
> -  V2KG (Vijay, Vijay, Kireeti, & George)
> 
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
> 
> 
> 
> 

Delivery-date: Mon, 28 May 2001 17:38:03 -0700
From: Heiles Juergen <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, "'Saha, Sayandeb'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 29 May 2001 02:36:37 +0200

Eric,

that was one point I commented onthe draft version of the Sonet/SDH document. Requesting section/line overhead transparency but limiting the paylaod to a STS-48-c-SPE doesn't make much sense to me. Transparency at the line/section layer but not at the path layer. Ok you could code it, but not everything you can combine is usefull and we better avoid to define such examples.

Regards

Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Wednesday, May 23, 2001 10:08 PM
> To:	'Saha, Sayandeb'
> Cc:	[email-masked]'; [email-masked]'
> Subject:	RE: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> Dear Sayan,
> 
> Thanks for the comments. However note that when requesting transparency for
> an STS-48 signal for instance, the signal type to use is STS-48. You cant'
> concatenate STS-1's since concatenation of STS-1 is not defined, but
> concatenation of STS-1 SPE's is. If you ask the concatenation of 48 x STS-1
> SPE's you are not speaking about the frame with its overhead, so you cannot
> request transparency. So we took the decision to use well defined signal
> types when requesting transparency (e.g. STS-48). And we took the convention
> to indicate in NCC the number of SPE's in that signal that must be
> concatenated. It took us some time to find a way to code each possible
> signal in a non ambiguous way. So I the original examples are correct.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Saha, Sayandeb [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 9:10 PM
> To: Mannie, Eric
> Cc: [email-masked]'; [email-masked]'
> Subject: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt 
> 
> 
> Hi ALL,
> I noticed the following in section 4 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt .
> 
>  The example number 16 is ...
> 
> 16. An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-48
>    Elementary Signal.
> 
> It should be 
> 
>    An STS-48c signal with LOH DCC and E2 transparency is formed
>    by the application of CCT with Type 1, NCC with value 48, NVC with
>    value 0, MT with value 1 and T with flag 5 and 10 to an STS-1 SPE
>    Elementary Signal.
> 
> The example number 17 is ...
> 
> 17. An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-768 Elementary Signal.
> 
> It should be 
> 
>    An STS-768c signal with K1/K2 and LOH DCC transparency is
>    formed by the application of CCT with Type 1, NCC with value 768,
>    NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
>    STS-1 SPE Elementary Signal.
> 
> Regards
> -Sayan
> 
> 
> 
> 

Delivery-date: Mon, 28 May 2001 17:38:00 -0700
From: Heiles Juergen <[email-masked]>
To: "Kullberg, Alan" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 29 May 2001 02:36:35 +0200

Alan,

hierachical LSP setup in Sonet/SDH and other transport planes is an issue currently not addressed by GMPLS. The Sonet/SDH naming tree (TDM-LSR link lable) for example doesn't fit with independent higher and lower order VC setup. For example the route of a VC-4 may change (use different STM-N ports at the equipment) while the endpoints are still the same. The VC-12 transported via these VC-4 don't have to care about the STM-N port only about the VC-4 endpoints. The current definition requires the port and full multiplex structure. AS not much thoughts are spent on the issue the current definition might not work with future extensions that support hierachical structures.

Regards

Juergen 

> -----Original Message-----
> From:	Kullberg, Alan [SMTP:[email-masked]]
> Sent:	Thursday, May 24, 2001 5:44 PM
> To:	'Mannie, Eric'; 'Kireeti Kompella'
> Cc:	[email-masked]'; [email-masked]'
> Subject:	last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> The following paragraph is from section 3 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt.
> 
>   When hierarchical SDH/SONET LSPs are used, an LSP with a given
>    bandwidth can be used to tunnel lower order LSPs.  The higher
>    order SDH/SONET LSP behaves as a virtual link with a given
>    bandwidth (e.g. VC-3), it may also be used as a Forwarding
>    Adjacency. A lower order SDH/SONET LSP can be established through
>    that higher order LSP. Since a label is local to a (virtual) link,
>    the highest part of that label is non-significant and is set to
>    zero.
> 
> The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
> defined for TDM Switch Capable.  In order to support the hierarchy in the
> above paragraph, TDM Switch Capable would need to be split into multiple
> values, one for each level of the SDH/SONET multiplexing structure.
> 
> What do you think?
> 
> Alan
> 

Delivery-date: Mon, 28 May 2001 17:37:26 -0700
From: Heiles Juergen <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>, Heiles Juergen <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Tue, 29 May 2001 02:36:06 +0200

Dimitri,

the SONET/SDH document says further on about AUG-N
"In addition any contiguous concatenation relationships between the
     VC-3s or VC-4s in the AUG-N are preserved and are allowed to
     change over the life of an AUG-N. It is this flexibility in the
     concatenation relationships between the component virtual
     containers that differentiates this signal from a set of VC-3s or
     VC-4s. In addition whether the AUG-N is structured with AU-3s or
     AU-4s does not need to be specified and is allowed to change over
     time."
So you can change between VC-4, VC-4, VC-4-4c, VC-4-16c, ... and even from all VC-4 to VC-3 over time. So it is a kind of transparency for the signal type. The text is even confusing as VC-3 contiguous concatenation is not defined.
If it would be only VC-3 or VC-4 what would be the difference to a multiplier which also allows to setup several VC-3/4.

By the way I didn't miss TUG. As I said I wasn't concerned about the proprietary definitions until the ongoing discussion.

Regards

Juergen 

> -----Original Message-----
> From:	Dimitri Papadimitriou [SMTP:[email-masked]]
> Sent:	Wednesday, May 23, 2001 5:04 PM
> To:	Heiles Juergen
> Cc:	[email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:	Re: Proposed text for the concatenation
> 
> Hello Juergen,
> 
> Only two short remarks here on the AUG/STS-Group:
> - First, on relation with transparency, it is clearly indicated
> into the document:
> "Note as well that transparency is only applicable when using     
> the following Signal Types (ST's): STM-1, STM-4, STM-16, STM-64,
> STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-768. At
> least one transparency type must be specified when requesting 
> such a signal type. NOT WITH AUG/STS-G"
> - Second it is clearly indicated into the document that:
> "Administrative Unit Group-N's (AUG-N's) are either a homogeneous
> collection of AU-3s or AU-4s. When used as a signal type this
> means that all the VC-3s or VC-4s in the AU-3s or AU-4s that 
> comprise the AUG-N are switched together as one UNIQUE signal..." 
> 
> So, by taking care of cautiously defining the terms used in the 
> document, we were convinced (by one of your itu-t colleagues) that 
> introducing such kind of signal into the current document can 
> increase it's utility (since TUG were already introduced at that 
> time in the document it was a question of consistency as well
> so i am surprised on the fact you missed the TUG since they are
> referenced in the document since March 2001 so TUG were introduced
> prior to the last published version) since today he provides such 
> kind of services - at that time the argument was "what can i do
> with gmpls if it doesn't cover any service covered today by our
> product !" - NB: now there is an informal 'agreement' with the 
> referenced person to introduce the related material in order to 
> propose itu-t specification alignment. 
> 
> Kind regards,
> Dimitri.
> 
> Heiles Juergen wrote:
> > 
> > The concatenation waves are going high here on the mailing list.
> > I attended the Paris editing session and didn't complain about the proprietary solutions.
> > However the ongoing discussion showed me several points:
> > - When we start to introduce one proprietary solution we open the document for any proprietary solution, where will we stop (I want B3 transparency and I over connection setup for containers (without POH)? Do we really want to define the signaling support for single, two, three vendor solutions. I would leave this to the vendors. They implemented a proprietary transport plane solution so they can also define their proprietary control plane solution. If we have a broader interest in the feature we should look at the application and consider if it should be standardized both for the transport plane and the control plane.> 
> > - Remember that we define the control in order to support the transport plane and not vice versa. A stand alone transport plane makes sense (and has been in use for years), a stand alone control plane doesn't. Interworking at the control plane doesn't help much if the transport plane doesn't interwork. So it should be a common standardization activity both in the control and in the transport plane.
> > - If we define something proprietary we need information about the feature, we cannot do it with guesses.> 
> > - We also have to be careful with proprietary features as we don't know what implications they have on the transport plane, they might exclude each other. That can happen as we focus only on the control plane and don't care about the implications at the transport plane. We can generate a real mess.
> > - I don't want to restrict new ideas and developments. Actually you cannot kill a good solution that fits network needs by blocking it from a standard. If someone builds it and shows its advantages operators will start to ask for it.
> > 
> > Now coming to Erics new proposed section:
> > In my view the proposal makes it even worse. Just say this is a standard feature and this is a proprietary feature. Don't start to explain how we can come form a proprietary  feature to interworking or a standard. And don't start to explain how the feature could be implemented. It will bring you into more trouble. This is a control plane document, nothing more.
> > 
> > Arbitrary contiguous concatenation:
> > What are the relaxed limitations. Either say nothing or define it in detail, but the later is not the task of this document.
> > 
> > Transparency:
> > RS and MS transparency is a standard feature, while transparency of individual overhead bytes is not. You have to distinguish between the two.
> > Transparency of individual bytes is an critical issue. You violate the layers and can screw up your whole management. In addition it is not real transparency what is needed, it is functional transparency. For example for B2. Or for the DCC bytes you might allow byte slips. But what implications has this on the DCN? It is easy to define a feature for the control plane and don't care about the transport plane implications.
> > Although you are a strong supporter of transparency, you were very fast in dropping the already included B2 transparency. Because it is not a straight forward solution? Requires some awkward processing? And some people don't understand how it works? That might be also true for other features (flexible arbitrary concatenation). So why include one and not the other?
> > 
> > Flexible arbitrary contiguous concatenation:
> > You started to describe a implementation. You have a certain solution in your mind. I think about a completely different approach. We both don't know it exactly, we just guess. Is this a good base to achieve interoperability.
> > One problem I see has to do with the AUG7STS Group signal type, another proprietary feature. The AUG/STS group signal type provides some transparency concerning the underlying VC-3/4/4-Xc structure. However as pointer processing for the individual VCs is still required in case of multiplexing the network elements have to detect the VC-N structure by themselves using the pointer information (valid pointer, concatenation indication). But this doesn't work with flexible arbitrary contiguous concatenation, at least with the solution I have in mind. Additional information on the VCs that belong together is needed in-band (SOH?) if automatic detection should be supported. If it is not supported it cannot be part of a AUG/STS group signal type while all other types of concatenation can be. If it is supported you might not need a label set. A label for the first time slot is enough. The network element detects which other belong to the group. So from the currently available inform!
!
!
>  at!
> >  io!
> > !
> > !
> > n it is difficult to tell if the control plane support is correct.
> > One other question. The Sonet/SDH GMPLS document says that virtual concatenation can be used with any contiguous concatenation. Although with flexible arbitrary contiguous concatenation as both require a label set?> 
> > 
> > Coming back to the AUG/STS group and TUG. I missed it in your new proposed section. It is a proprietary feature.
> > Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783. It should be noted that AUG/TUG are not and were never intended to be networking entities. They were introduced as internal signal structures in order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and RS are the networking entities.
> > A AUG/STS group or TUG provides some transparency concerning the underlying VC-N structure. IF you multiplex the signal you still have to do pointer processing for the individual VCs. As a AUG/STS group or TUG has no overhead of its own, any supervision has to be performed on the individual VCs. So what will it buy us ?(ok, ok better not to ask the question, some one supports it and has its good reasons to do so as it is the case for any of the above features)
> > 
> > Regards
> > 
> >         Juergen
> > 
> > > -----Original Message-----
> > > From: Mannie, Eric [SMTP:[email-masked]]
> > > Sent: Tuesday, May 22, 2001 9:22 PM
> > > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > > Subject:      RE: Proposed text for the concatenation
> > >
> > > Hello Man Wing, Bala and All,
> > >
> > > >I think Eric's proposed text gives a very good coverage on all cases
> > >
> > > Thanks :-)
> > >
> > > >and all we need is indicating which field is ... optional
> > >
> > > Indeed everything is already optional in the draft except the signal type of
> > > course:
> > >
> > >   - CCT: set to zero to say no contiguous concatenation requested (default
> > > value)
> > >   - NCC: set to zero when CCT is set to zero (default value)
> > >   - NVC: set to zero to say no virtual concatenation (default value).
> > >   - Multiplier: set to one if one instance (default value).
> > >   - transparency: set to zero to say don't care (default value).
> > >
> > > So there is no issue there, I will add a specific paragraph to re-enforce
> > > it.
> > >
> > > In addition, when a downstream node receives an "incoming request" he can
> > > decide to accept it or to refuse it depending of what is requested,
> > > depending of the CAC process, depending of the customer profile, depending
> > > of the capabilities that it supports, etc.
> > >
> > > The draft doesn't indicate what must be implemented of course.
> > >
> > > >and all we need is indicating which field is standard....
> > >
> > > Ok, I agree. Let's indicate in the draft the features that are not
> > > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > > concatenation, and transparency. Is there another one ? All the signal types
> > > have an equivalent definition in the standards.
> > >
> > > --- proposed new section:
> > >
> > > X. Relationship with SDH and SONET standards
> > >
> > > Some of the features described in this specification are not defined neither
> > > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
> > > these features are useful and implemented in many equipment's. All these
> > > features are optional but can be controlled using this specification.>
> > >
> > > These features are: arbitrary contiguous concatenation, flexible arbitrary
> > > contiguous concatenation and transparency. They have been > described in the
> > > relevant sections of this specification.
> > >
> > > Arbitrary contiguous concatenation does not need any additional standard to
> > > interoperate. It simply relaxes some limitations specified in the
> > > corresponding AINSI and ITU-T standards.
> > >
> > > Transparency does not need any standard at the UNI since it is only
> > > implemented in the data plane at the NNI. This can be requested using the
> > > signaling at the UNI, independently of its implementation at the NNI.> 
> > > Interoperability between multiple manufacturers at the NNI can be achieved
> > > in > different ways: through the use of a standard, an implementation
> > > agreement made by a forum, or an implementation agreement between two
> > > manufacturers (e.g. at the request of an operator).
> > >
> > > Flexible arbitrary contiguous concatenation just need a very simple and
> > > obvious agreement to interoperate between multiple manufacturers. Again this
> > > can be achieved in different ways: through the use of a standard, an
> > > implementation agreement made by a forum, or an implementation agreement
> > > between two manufacturers (e.g. at the request of an operator). A simple
> > > agreement could for instance simply indicate where is copied the original
> > > path overhead when "inverse multiplexing" locally a contiguously
> > > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at all
> > > about this paragraph, ideas are welcome, please help !
> > >
> > > ---------- End of text
> > >
> > > Agreed ? Comments ?
> > >
> > > Comments from our ITU-T folks are welcome (really :-)
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Fong, Man Wing [mailto:[email-masked]]
> > > Sent: Tuesday, May 22, 2001 5:15 PM
> > > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: Proposed text for the concatenation
> > >
> > >
> > > Very good point, Greg. If I remember correctly, the initial email initiated
> > > such a great discussion was someone asked about whether it was worth
> > > investing development effort on arbitrary concatenation. The bottom line is
> > > if there is an appearing business case for the feature, then you will
> > > support it. As some of you (vendors) already indicated that your systems
> > > support AC because there are operators using and asking for this feature.
> > > There might be a lot of vendors and users supporting this or might be just a
> > > few, but the fact is there are someone supporting it. When defining new
> > > protocols, I agree that we should consider and cover all cases, as long as
> > > any non-standard fields are optional.
> > > I think Eric's proposed text gives a very good coverage on all cases and all
> > > we need is indicating which field is non-standard and optional.
> > >
> > > Man Wing
> > >
> > > << File: Card for Dimitri Papadimitriou >> 

Delivery-date: Mon, 28 May 2001 17:37:23 -0700
From: Heiles Juergen <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls 
Date: Tue, 29 May 2001 02:36:28 +0200

I am sending this email again as comments on the GMPLS last call, as I havent received any response up to now on my comments.

Juergen

> -----Original Message-----
> From:	Heiles Juergen [SMTP:[email-masked]]
> Sent:	Monday, May 07, 2001 5:08 PM
> To:	[email-masked]; [email-masked]
> Subject:	Comments on G-PID
> 
> I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt.
> 
> Juergen
> 
> 
> 
> The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID intorduciton text
> "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload."
> 
> Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required.
> 
> Now to the detailed comments:
> The follwoing G-PIDs have to be removed as they are not defined:
>             8     Bit synchronous mapping of E3
>             9     Byte synchronous mapping of E3
>            12     Byte synchronous mapping of DS2/T2
> 
> As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore:
>            19     Same as 12 but in a VC-12
>            20     Same as 13 but in a VC-12
>            21     Same as 14 but in a VC-12
> 
> SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals):
> The whole set of SONET/SDH G-PIDs:
>                 Asynchronous mapping of E4 PDH framed
>                 Asynchronous mapping of E4 SDH framed
>                 Asynchronous mapping of E4 transparent
>                 Asynchronous mapping of DS3 M23
>                 Asynchronous mapping of DS3 C-Bit Parity
>                 Asynchronous mapping of DS3 transparent
>                 Asynchronous mapping of E3 PDH framed 
>                 Asynchronous mapping of E3 SDH framed 
>                 Asynchronous mapping of E3 transparent 
>                 Asynchronous mapping of DS2/T2
>                 Bit synchronous mapping of DS2/T2
>                 Asynchronous mapping of E1 framed
>                 Asynchronous mapping of E1 transparent
>                 Byte synchronous mapping of E1 framed
>                 Byte synchronous mapping of 31 * 64kbit/s
>                 Asynchronous mapping of DS1/T1 SF
>                 Asynchronous mapping of DS1/T1 ESF
>                 Asynchronous mapping of DS1/T1 transparent
>                 Bit synchronous mapping of DS1/T1 SF
>                 Bit synchronous mapping of DS1/T1 ESF
>                 Bit synchronous mapping of DS1/T1 transparent
>                 Byte synchronous mapping of DS1/T1 SF
>                 Byte synchronous mapping of DS1/T1 ESF
>                 VTG/TUG  
>                 STS Group/AUG
>                 POS - No Scrambling, 16 bit CRC
>                 POS - No Scrambling, 32 bit CRC> 
>                 POS - Scrambling, 16 bit CRC
>                 POS - Scrambling, 32 bit CRC
>                 ATM mapping
>                 FDDI mapping
>                 DQDB mapping
>                 GFP mapping
>                 LAPS IP (X.85)
>                 LAPS Ethernet (X.86)
>                 SDL, set-reset scrambler
>                 SDL, self-synchronizing scrambler
>                 O.181 test signal
> 
> Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be payload of an PDH LSP, only of a SONET/SDH and this is already defined. As I assume that no one will setup PDH LSPs the ANSI-PDH technology should be removed completley. The mapping into SONET/SDH is covered under SONET/SDH technology.
> 
> 
> The G-PIDs
> 
>            33     Ethernet                               Lambda, Fiber specific
>            34     SDH                                    Lambda, Fiber    "
>            35     SONET                                  Lambda, Fiber    "
>            36     Digital Wrapper                        Lambda, Fiber    "
>            37     Lambda                                 Fiber            "
> are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown?
> "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID.
>                 
> 

Delivery-date: Mon, 28 May 2001 17:37:20 -0700
From: Heiles Juergen <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>, "Brungard, Deborah A" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Eric Mannie <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding  type
Date: Tue, 29 May 2001 02:36:33 +0200

Dimitri,

removal of the Sonet/SDH version was the out come of the Paris Sonet/SDH editing session. But it didn't make it into the main document.
My proposal was also to use the same signal type values for identical Sonet/SDH signals as it would make interworking easier. This was rejected with the argument of the proxy function that is needed in any case.

Regards

Juergen

> -----Original Message-----
> From:	Dimitri Papadimitriou [SMTP:[email-masked]]
> Sent:	Saturday, May 26, 2001 12:11 PM
> To:	Brungard, Deborah A
> Cc:	'John Drake'; 'Yuri Landry'; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Eric Mannie
> Subject:	Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type
> 
> Hi all,
> 
> Back to question on the LSP EncType concerning SDH/Sonet, when 
> proposed it was to enable specific inter-working between capabilities
> provided in v2000 and not in v1996 of SDH (for instance the in-band 
> FEC P1/Q1 and REI M0/M1) this distinction was proposed mainly for 
> on-demand Transparency service usage (introduced in the SDH/Sonet 
> GMPLS document). I guess you agree with me that v2000 include a lot 
> of differences compared to the v1996.
> 
> Now since the SDH/Sonet extensions draft does not make this distinction 
> anymore in response to lighter Transparency services, I suggest to keep
> only two LSPEncType codepoints one for SDH and one for Sonet making the
> assumption that versions are backward compatible as it should be the 
> case. Do you agree with the proposed change ? I propose this otherwise
> changes into the SDH/Sonet draft won't be minor anymore.
> 
> Your question on inter-working between Sonet and SDH is valid, the 
> proposal up to now is to use a "proxy" function making appearing the
> connection for the SDH side as an SDH LSP and as an Sonet connection
> for the other side by enabling the corresponding "modification" at the 
> entity performing the interworking function. Since this is not
> completely
> defined into the document i propose to indicate as well that more
> details will be provided in next releases or even in a specific
> document concerning this issue.
> 
> What do you think about ?
> 
> Regards.
> - Dimitri.
> 
> "Brungard, Deborah A" wrote:
> > 
> > All,
> > 
> > (I've changed the subject field to signal a "switch" of topics - and kept
> > q11 and t1x15 lists as the mail is related to their subject areas)
> > 
> > I also had some questions/comments on the LSP encoding types- section 3.1.1-
> > 
> > can someone explain why different values are used for different versions of
> > T1.105 and G.707? The later versions contain updates to include OC-768 and
> > new functions e.g. FEC, J0 support of 16-byte in addition to previous 1-byte
> > version, etc. One can not assume equipment supports all functions described
> > in any of the versions; one can only assume if the function is supported, it
> > is supported as defined. Example, equipment "supporting" T1.105 '95 may not
> > support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> > "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> > "supporting" details/references can be addressed in the technology specific
> > documents.
> > 
> > Similar comment for PDH - E1 services are supported in the U.S. and 45M are
> > supported in Europe. One code can be used: PDH.
> > 
> > For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> > digital wrapper - G709 defines a hierarchy: optical and electrical. Reading
> > the attached mail, on waveband switching and assigning Lambda as an LSP
> > type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> > Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> > functionality for OTN signals - it is different from today's SONET/metro WDM
> > equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in the> 
> > OTN technology specific document.
> > 
> > Probably should include LSP ranges for future items (and proprietary?).
> > 
> > Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc. SONET),
> > OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> > 
> > The G-PID has discrete values for DS1, DS3 whereas only one value for all
> > STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> > others supported, and no SDH VC-4. The G-PID seems to be redundant info with
> > the technology specific parameters - is there a reason to support this in
> > the generalized label request?
> > 
> > Regards,
> > Deborah Brungard
> > AT&T
> > 
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 10:25 AM
> > To: 'Yuri Landry'; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena tion
> > 
> > Yuri,
> > 
> > I've attached a private note I sent to Dimitri regarding waveband switching.
> > It was originally put in at the suggestion of NorTel.  For both waveband
> > switching and fiber switching, you are dealing with a situation in which you
> > are using a standardized control plane to establish a multi-hop LSP with
> > proprietary encoding of data.  As I mentioned, this would be accomplished
> > using link coloring.
> > 
> > Personally, I have no problem removing either waveband switching or fiber
> > switching, but we know have to accomodate them wrt the control plane, and I
> > seriously doubt that there will ever be a completely non-proprietary of
> > encoding the data for these types of LSPs.
> > 
> > Note that I am using 'proprietary' in the exclusive sense.
> > 
> > Thanks,
> > 
> > John
> > -----Original Message-----
> > From: John Drake
> > Sent: Wednesday, March 28, 2001 11:15 AM
> > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> > Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> > 
> > Dimitri.
> > 
> > It's probably better to think of waveband switching as a special form of
> > fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> > Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> > switching case, the fiber between the DWDM system and a port on the PXC
> > contains the entire set of lambdas, while in the waveband switching case
> > there is a set of fibers between the DWDM system and a set of ports on the
> > PXC, each of which contains a separate waveband.
> > 
> > In either case, the encoding of the signal on the fibers is completely
> > proprietary, and it's the job of routing to ensure that a correct path
> > through the network is obtained, such that the proprietary encoding is
> > maintained end-end.  This would probably be done through link coloring, so
> > that you only route across links that support NorTel waveband switching or
> > Tellabs waveband switching.
> > 
> > So I think the signalling stuff is fine.
> > 
> > Thanks,
> > 
> > John
> > 
> > -----Original Message-----
> > From: Yuri Landry [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 7:02 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena tion
> > 
> > Hello All,
> > 
> > So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> > re-direct your attention to other drafts. Rob's suggestion should apply to
> > other drafts too.
> > 
> > One example, is the waveband switching and waveband label a standard or
> > proprietary? Can author explain to me what exactly they means? How do they
> > work? Any other standard reference? There are questions about it but no
> > answer yet.
> > 
> > Regards,
> > 
> > Yuri.
> > 
> > >From: "Lazer, Monica A, NNAD" <[email-masked]>> 
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> > ><[email-masked]>
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> > >tion
> > >Date: Thu, 24 May 2001 18:11:36 -0400
> > >
> > >
> > >Rob, You proposal makes a lot of sense. Having the signaling standard
> > >support proprietary transport may jeopardize interoperability. The issue is
> > >not about GMPLS supporting non-standard rates, the issue is about putting
> > >in
> > >formal and very specific support for a proprietary transport solution in a
> > >standard document for signaling without taking the transport portion to a
> > >standards body. Having formal signaling support for a proprietary
> > >concatenation may cause interoperability issues when other vendors have a
> > >different solution to the concatenation and while the signaling would
> > >indicate the concatenation, the actual transport may not work.   On the
> > >other hand we recognize that there may be a need for some interim support
> > >for proprietary solutions.
> > >
> > >
> > >Eric,
> > >Below I have some additional specific comments for the document GMPLS
> > >Extensions for SONET and SDH Control
> > >
> > >
> > >CCT field (3 bits)
> > >Since arbitrary contiguous concatenation is not a standard concatenation,
> > >it
> > >falls within the vendor proprietary set of solutions.
> > >
> > >So the CCT bits may be used as follows:
> > >000    No contiguous concatenation requested
> > >001    Standard contiguous concatenation
> > >others Vendor specific contiguous concatenation
> > >
> > >Alternatively, a better solution is to use only 2 bits for this field and
> > >use one bit to show whether contiguous concatenation is requested and the
> > >second bit to show whether it is standard or non-standard contiguous
> > >concatenation.
> > >
> > >
> > >NCC field (16 bits)
> > >This information is not sufficient.
> > >NCC needs better description than a zero or non-zero number.
> > >
> > >SDH and SONET Labels
> > >
> > >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> > >GMPLS proposal limits virtual concatenation to remain within a single
> > >(component) link. If I understand this correctly, it means that GMPLS will
> > >not allow inverse multiplexing (virtual concatenation) in the transport
> > >plane if it requires different component links. This is too limiting.
> > >
> > >Annex 1 (sent out by Eric Mannie on 5/22)
> > >Defines another type of concatenation - Flexible arbitrary contiguous
> > >concatenation without describing precisely how it affects the OH bits. This
> > >means that it will be impossible to have this type of concatenation in a
> > >multi vendor environment based only on the GMPLS signaling. If the
> > >transport
> > >plane is proprietary, having the option in the signaling message will not
> > >fix the interoperability problem between two different vendors supporting
> > >their proprietary versions of arbitrary concatenation.
> > >
> > >Annex 2 (sent out by Eric Mannie on 5/22)
> > >Arbitrary contiguous concatenation needs definition work for
> > >interoperability.
> > >Flexible arbitrary contiguous concatenation may be available today to
> > >support contiguous signals, but it is not defined in the current standards.
> > >Clear agreements on OH usage are needed between supporting vendors.
> > >Maintenance and tracking of the signal needs to be well understood.
> > >
> > >
> > >
> > >Monica A. Lazer
> > >Advanced Transport Technology and Architecture Planning
> > >
> > >908 234 8462
> > >[email-masked]
> > >
> > >
> > >-----Original Message-----
> > >From: Rob Coltun [mailto:[email-masked]]
> > >Sent: Thursday, May 24, 2001 7:24 PM
> > >To: [email-masked]; [email-masked]; q11/15; t1x1.5> 
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > >concatenation
> > >
> > >All,
> > >     despite the heated arguments I think the discussion is important to
> > >have.
> > >
> > >I suggest that instead of  tagging non/pre-standard items in the current
> > >drafts
> > >that they be put into a separate Informational document  - this is the
> > >cleanest thing to do.
> > >We (the IETF) do have a tradition of publishing company proprietary
> > >protocols
> > >but not as standard track documents.
> > >
> > >thanks,
> > >---rob
> > >
> > >
> > >
> > >_______________________________________________
> > >IP-Optical mailing list
> > >[email-masked]
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> > 
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > 
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical << File: Card for Dimitri Papadimitriou >> 

Delivery-date: Mon, 28 May 2001 17:37:20 -0700
From: Heiles Juergen <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Proposed text for the concatena tion
Date: Tue, 29 May 2001 02:36:23 +0200

Eric and all,

let me again stress my view.
My major concern is to get usefull standards, RFCs, interworking agreements or what ever you call it, that don't confuse people. If it is done in the IETF, ITU, OIF, ... is an secondary issue. All have their pros and cons. As soon as several bodies get involved it is getting more difficult to synchronize the activities. With MPLS the IETF had both the transport and control plane in its hands. With GMPLS it is different. GMPLS defines the control plane signaling for already existing transport planes defined by other bodies. Defining a control plane needs in my view solid knowledge of the underlying transport plane. One of our (the Sonet/SDH guys) faults might be that we got involved in the discussion to late.
I am following the GMPLS development for some time now and did sent some comments on the email list over the last months. As I didn't get response back and the comments seemed to be ignored I was thinking about stoping my activities on the list. It changed at the Paris editing session when my proposal for virtual concatenation was included. Thats why my name came on the author list. But that doesn't mean that I am sure that the whole document is correct or tht I fully agree with it as I hadn't time to go through all the details togehter with the other GMPLS IDs. That might also be the case for other people on the authors list. As I said before I accepted the proprietary extensions at the Paris session as it seemed to me that this is the way it works at the IETF (what does rough consensus mean?).
I brought up the issue of flexible arbitrary contiguous concatenation and that triggered me. We try to define control plane support for a proprietary transport plane features that we don't know much about. How are we sure that the control plane support is correct. How are we sure that it can be combined with other features. As Greg told me in a privat mail (see below) flexible arbitrary concatenation cannot be supported by the STS group/AUG signal type as explizit configuration (via management or signaling) of the time slots is required. However the Sonet/SDH document says 
"STS Group-N is a collection of STS-1 SPE signals whose contiguous concatenation relationship within the group need not be defined and is permitted to change during the life of the STS-Group-N."
So that is not correct if we introduce flexible arbitrary contiguous concatenation.
That is only one point, we may missed others as we don't have all the information.
If the IETF accepts proprietary features, please make sure that you have the necessary information. Otherwise you create a mess. Furthermore explizitly state what is standard and what is not standard. Most readers don't have the background knowledge of all the discussions we have.

Now how to deal with the proprietary features in the document:
It seems a common understanding now that we have at least to identify the proprietary features (either move them in an informativ annex or a separate document). It seems we don't have consensus to remove them at all.
We also have to state, that the combination of these proprietary features with other reasonable proprietary or standard features is not always checked and cannot be guaranteed. Note that it is also not possible to combine all standard features, but that is described in the related standards.

Regards

Juergen

Hi Juergen, see comment below.  

Greg B.

-----Original Message-----
> (1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE
equipment
> and has nice consequences for avoiding re-grooming.
	[Juergen Heiles]  How will you tell the framer the starting time
slot and the remaining timeslots? Via TMN cnfiguration or GMPLS signaling?
Not in-band using some SOH? If you also want to support the STS Group, AUG
or partially transparent signal type defined in GMPLS you need the in-band
information.

*** This is what GMPLS or some kind of signaling protocol is good for. But
of course I can set it up via management too. A set of time slot numbers vs.
a set of numbers! What's the big deal...  Now in-band I can run GMPLS over a
DCC channel so I don't really differentiate between this and GMPLS (or any
other signaling protocol based method).
The STS Group concept/transparency:  Yes, you're right I wouldn't support
the "arbitrary concatenation" over this.  Since, its a "transparent" service
and the concatenation must be automatically detected, i.e., without
signaling.  

Delivery-date: Mon, 28 May 2001 12:36:08 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: "'Ash, Gerald R (Jerry)'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>, Bala Rajagopalan <[email-masked]>
Cc: John Drake <[email-masked]>
Subject: RE: GMPLS Last Calls
Date: Mon, 28 May 2001 12:59:27 -0700

Dimitri, Bala,

I agree with your philosopy. Especally the part that points out that there are 
no
semantics associated with an LSP setup via GMPLS signaling, as currently
defined. Therefore, any type of LSP (working, protect, shared, etc. ) can be
established with GMPLS signaling.

The issue of restoration signaling and how to associate LSPs with working or
protection routes is something that can be (and in fact has been; at least in 
the
MPLS, IPO, and TE WGs) worked on in parallel.

In my view, the issue being raised by Chuck, Jerry, Eve, and others wrt 
restoration is
whether the current
signaling specs. should specify restoration signaling as well, and whether it
would be possible to completely isolate restoration signaling from GMPLS-SIG
in such a way that later developments of restoration signaling do not affect
GMPLS-SIG. You've said that you feel strongly that these can be decoupled.

I feel that it might be worth spending some CPU cycles to make sure that
this is the case (or is largely the case), since it saves considerable 
retrofitting
in the future. When we began work on the GMPLS SIG specs. over a year ago,
restoration was only just beginning to surface in the IETF, and it is only in 
the
last 6 months or so that there has be greater focus on it. So it makes sense
to take a little time to examine GMPLS-SIG in the light of this.

As for Jerry's point, I think all he is saying is that over the last couple of 
IETFs,
there have been formal calls by the ADs, Acting ADs, and different WG advisors
to formally obtain SP input on several items (such as restoration, TE best 
practices,
etc.), but this does not seem to have been the case for GMPLS signaling specs.
(Of course, as Eric rightly pointed out, this does not prevent any SP or their
representatives from providing such input.)

Finally, and others can correct me if I am wrong, isn't there  a little bit of
contradiction in the IETF stance with respect to SP input, given that 
(technically) we
all come to the IETF, not as representatives of our companies, but rather
as individual contributors.

If so, I am a little confused about what it means
to ask for SP input? Are we asking for individual contributors from the
SP community, and hoping that they will bring in (by osmosis) the overall 
philosophy
of their company, or are we asking for companies to specifically send
their representatives to provide inputs on certain topics that have been
deemed to require SP input?

ADs, Chairs, any comments or clarifications?

Thanks,

-Vishal

On Monday, May 28, 2001 6:17 AM, Dimitri Papadimitriou 
[SMTP:[email-masked]] wrote:
> Eric,
>
> Don't be so pessimistic...
>
> I think (and as also proposed by Bala) that today LSP
> "provisioning" which is specified within the GMPLS-SIG
> can be associated with working, protection, shared-
> protection LSP etc. Meaning there is not "semantic"
> associated with the LSP established through GMPLS so
> they can be used for any purpose.
>
> "Restoration signalling" which can be implemented in
> many ways is today under discussion. Bala thinks about
> a dedicated lighweight protocol but other solution are
> feasible using current signalling protocol extensions
> or not. The good thing is that an open discussion has
> been today engaged.
>
> I don't see any problem with respect to GMPLS-SIG
> document over there. I strongly believe that the
> restoration issues can be proceeded indepedently
> from the current GMPLS drafts today on last call.
>
> - Dimitri.
>
> "Mannie, Eric" wrote:
> >
> > Hello Jerry
> >
> > >correct, as I mentioned, SPs have been formally asked for their
> > >*requirements*, but not on the GMPLS extensions
> >
> > Sorry ! It is an OPEN process since the beginning, everybody can contribute
> > and write a draft. There is no formal process where requirements from
> > operators are asked for. I am not aware of any IETF rule about that !
> >
> > You were welcome to work with us since 1.5 years but you never came to us.
> > You cannot blame us that you never worked on it (we are not responsible for
> > that)! This is true for the thousands of internet drafts being written at
> > the IETF.
> >
> > It is the responsibility of each company individually to decide if they
> > want
> > to contribute or not ! It is not the job of others companies to go to each
> > possible operator/manufacturer and to lobby to have them involved.
> >
> > Regards,
> >
> > Eric << File: dimitri.papadimitriou.vcf >> 

Delivery-date: Mon, 28 May 2001 11:57:43 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Rob Coltun' <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Mon, 28 May 2001 20:55:24 +0200

Hello Monica,

>Arbitrary contiguous concatenation needs definition work for
>interoperability.

Which one ? I am asking the same questions since two weeks and nobody
answered (or did I miss it ?). What needs to be standardized ? Strange that
nobody wants to answer ! Repeating constantly the same thing is cool, but
somebody should proof it, otherwise we could definitively conclude that this
feature works without any additional standard !

>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.

Could you be more precise, what do we have to change in the SDH/SONET
framing to be able to interoperate ? I still had no clear answer. To help
you: G.783 defines a converter between a contiguous concatenated signal and
a virtually concatenated signal. If we apply it locally back-to-back, i.e.
in from contiguous to virtual in one node and then virtual to contiguous in
the next node, isn't it what we call flexible concatenation ? And in that
case this is already standardized (too rich for what we need, but it doesn't
hurt). Opinion ?

I would really like to have a technical discussion :-)

Thanks,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 7:24 PM
To: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

All,
    despite the heated arguments I think the discussion is important to
have.

I suggest that instead of  tagging non/pre-standard items in the current
drafts
that they be put into a separate Informational document  - this is the
cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary
protocols
but not as standard track documents.

thanks,
---rob

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Mon, 28 May 2001 11:12:30 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], q16/15 <[email-masked]>
Subject: RE: Dead of GMPLS ?
Date: Mon, 28 May 2001 20:09:32 +0200

Hello Bala,

>given the
>speed and zeal with which all sorts of features
>were being proposed as candidates for GMPLS control.

Whaoum, that's scary for people that don't know GMPLS. They could think that
we wanted to include quickly all sorts of features with zeal and without
thinking. Hopefully this was not case, as you know it, and we decided to
keep most of them for further study.

We started more than one year ago, and for SDH/SONET we mainly wanted to
control SDH/SONET transparency and arbitrary concatenation as added-value on
the top of existing standards. Now we are also speaking about flexible
concatenation as another optimization.

>I think the best way to move forward is to
>get some consensus on the set of well-defined
>features/capabilities that
>people agree have *current relevance*.

Right, good to remind our objectives to non co-authors. Hopefully we talked
about these features during more than a year and we reached a consensus each
time we modified the text. So I guess that at least these people thought
that it was relevant.

>It doesn't seem sensible to stop progress
>on the most general aspects of gmpls for the
>sake of supporting features whose 
>near-to-intermediate term
>significance is dubious.

I guess that you are not speaking about SDH/SONET transparency and
concatenation since you took an active part in their definition (I remember
this evening session at the last IETF, was it in your hotel room by the way
? :-).

Rgds,

Eric

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Monday, May 28, 2001 6:56 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; q16/15
Subject: RE: Dead of GMPLS ?

Eric:

I understand your frustration, but the current
state of affairs was waiting to happen given the
speed and zeal with which all sorts of features
were being proposed as candidates for GMPLS control.
I think the best way to move forward is to
get some consensus on the set of well-defined
features/capabilities that
people agree have *current relevance*. Other features,
drop them/move to different drafts/what not.
It doesn't seem sensible to stop progress
on the most general aspects of gmpls for the
sake of supporting features whose 
near-to-intermediate term
significance is dubious.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 11:37 AM
> To: 'Guo-Qiang Wang'
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject: RE: Dead of GMPLS ?
> 
> 
> Hello Guo-Qiang,
> 
> >  If one non-SONET/SDH-standard feature could decide the death or the
> liveness 
> of GMPLS, it is the reason I strongly suggest you guys remove 
> this feature 
> to a separate document to keep GMPLS alive.  Up to now, all 
> the arguments we
> have 
> seen are focusing on non-SONET/SDH-standard issue, not on 
> lambda switching
> and fiber switching. 
> 
> No, please read the included e-mails and the e-mails that I 
> was referred to,
> they are talking about waveband switching, etc..
> 
> We are now speaking about removing waveband switching, about 
> where to put
> protection/restoration, and about scanning all the GMPLS 
> drafts to see what
> should be removed (see the three e-mails from Maarten).
> 
> I am discussing the general principle of moving all 
> non-standard related
> features to separate documents. If you want to do it for 
> technology A, to
> stay consistent you have to do it also for technology B, C, etc.
> 
> Of course you have to remove lambda switching since this is 
> proprietary
> (what are the parameters to control, to signal, etc... we 
> don't know yet) -
> It is too early in this draft to speak about that before 
> knowing how exactly
> the transmission plane will look like. There is no value of having a
> standardized control plane to control proprietary networks (as I
> understood).
> 
> My list of features to remove contains at least:
> 
> - SDH/SONET transparency.
> - SDH/SONET arbitrary concatenation, flexible concatenation.
> - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> - All kinds of end-to-end protection/restoration for any 
> layer, except the
> IP layer.
> - The Waveband switching object and its concept.
> - The concept of LSC and FSC layers, i.e. concept of lambda and fiber
> switching.
> - The label set object (only used for lambda issues).
> - LSP encoding type, bandwidth encoding and GPID have to be simplified
> accordingly.
> - MPLS extensions to control G.709 (since multiplexing, etc is not yet
> defined).
> - etc...
> 
> Something else to add to this list ?
> 
> Rgds,
> 
> Eric
> 
> 
> 
> -----Original Message-----
> From: Guo-Qiang Wang [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 4:24 PM
> To: Mannie, Eric; 'Maarten Vissers'
> Cc: 'Yuri Landry'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject: RE: Dead of GMPLS ?
> 
> 
> Hi, 
>   If one non-SONET/SDH-standard feature could decide the death or the
> liveness 
> of GMPLS, it is the reason I strongly suggest you guys remove 
> this feature 
> to a separate document to keep GMPLS alive. Up to now, all 
> the arguments we
> have 
> seen are focusing on non-SONET/SDH-standard issue, not on 
> lambda switching
> and fiber switching. 
>   Regards,  
> G.Q Wang 
> Technical Manager 
> Emerging Network Technology 
> Nortel Networks 
> Tel: (613)765-4195 (ESN 395-4195) 
> Fax: (613)768-1140 
> [email-masked] 
> -----Original Message----- 
> From:   Mannie, Eric [SMTP:[email-masked]] 
> Sent:   Monday, May 28, 2001 9:08 AM 
> To:     'Maarten Vissers' 
> Cc:     'Yuri Landry'; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject:        Dead of GMPLS ? 
> Hello Maarten, 
> E-mail 1: 
> >Let's review the series of GMPLS 
>                   ^^^^^^ 
> >draft documents to identify the non/pre-standard items and then move 
> >those items into separate Informational documents. 
> ^                          ^^^^^^^^^^^^^^^^^^^^^^^ 
> E-mail 2: 
> > Yuri started the discussion on wavebands some days ago. 
> Wavebands are 
> > yet undefined in the transport plane. 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> E-mail 3: 
> >Triggered by Yuri's email, I would like to offer another 
> area for closer 
> >look: protection switching. The standardised SDH protection 
> switching 
> >schemes are specified in G.841 with further support in G.783. 
> > 
> >When reading the protection switching text some time ago in 
> the GMPLs 
> >draft I noticed several extensions to be described beyond those in 
> >G.841. 
> > 
> >My request is to review the latest text against G.841/G.783, 
> identify 
> >the extensions and (as now proposed by several of us) move those 
> >extensions into a separate Informational document. 
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> The transmission plane for optical networks is not standardized: DWDM 
> systems are proprietary and don't interoperate. 
> So I guess that we have to remove the concept of optical 
> switching (lambda 
> switching, fiber switching, waveband switching) from GMPLS if 
> we want to 
> follow your model of thinking. We also have to remove any end-to-end 
> protection/restoration and all non standardized SDH/SONET 
> behaviors (even if
> 
> they don't change the standards) as you said. 
> Everything will become informational, except may be a very small root 
> specification (that will not be allowed to speak about any optical 
> switching). 
> Since the IETF will not have any standard (track) RFC, ITU-T 
> will have to 
> claim that there is no existing standard and do one... 
> What is the benefit of moving all the interesting signaling 
> features to 
> informational RFC's ? If we don't have signaling standards 
> why should we 
> continue to work on GMPLS ? Why should we spend so much energy of 
> informational documents that have no standard value ? That 
> will be an easy 
> marketing message "GMPLS: don't pay attention to it, it is only 
> informational, you need a standard". 
> Either GMPLS is dead, or we accept that GMPLS ALLOWS TO 
> CONTROL STANDARDIZED
> 
> AND NON STANDARDIZED DATA/TRANSMISSION PLANES. 
> Regards, 
> Eric 
> -----Original Message----- 
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Monday, May 28, 2001 11:03 AM 
> To: John Drake 
> Cc: 'Yuri Landry'; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; q16/15 
> Subject: [IP-Optical] GMPLS: waveband switching 
> 
> 
> John, 
> Yuri started the discussion on wavebands some days ago. Wavebands are 
> yet undefined in the transport plane. Looking into it a few 
> days ago, I 
> tried to provide a definition of waveband and got immediately 
> corrected 
> by an optical expert, resulting in an adapted definition of waveband 
> (see email below). 
> At this point in time, a waveband seems to be a group of 
> Optical Channel 
> (OCh) signals. It represents a partition, not a new layer network. As 
> such a waveband should be represented as a "group of OCh 
> signals" within 
> the OCh layer network. 
> Regards, 
> Maarten 
> 
> 
> 
> Maarten Vissers wrote: 
> > 
> > Manoj, Yuri, 
> > 
> > I received a message that my definition of waveband is too 
> restricted. 
> > 
> > A waveband should be an optical multiplex, administered as a single 
> > bundle, not necessary contiguous in frequency slot. 
> > 
> >         E.g. there may be good technical reasons to consider a 
> >         'waveband' created at an OADM formed by taking every 2nd 
> >         wavelength in a 50GHz-spaced transmission band. 
> > 
> > In first instance the above definition may not be 
> considered this as a 
> > "band"; it 
> > looks more like a "gapped-band" :-). Nevertheless, due to technical 
> > reasons we should consider a waveband as just another name for a 
> > particular group of wavelengths, which may best be viewed 
> as a group of 
> > identified/listed wavelengths. 
> > 
> > Regards, 
> > 
> > Maarten 
> > 
> > Maarten Vissers wrote: 
> > > 
> > > Manoj, Yuri, 
> > > 
> > > In my current understanding, a waveband is a group of OCh 
> (optical 
> > > channel) signals located in a contiguous set of tributary (i.e. 
> > > frequency) slots. 
> > > 
> > > A waveband is therefore related to partitioning, rather 
> than a layering.
> 
> > > A waveband shouldn't have an LSP encoding type itself, 
> but instead be 
> > > part of the OCh layer network. E.g. a specific RGT 
> (requested groupting 
> > > type) of "contiguous waveband" can be defined for this 
> purpose with the 
> > > RNC (requested number of components) indicating the size of the 
> > > waveband. 
> > > 
> > > The above is simply a first shot; in general the issue 
> can be more 
> > > complex due to the fact that the frequency slot for a 
> 2G5, a 10G and a 
> > > 40G signal may have differnet bandwidths: e.g. 2G5 freq. 
> slot width e.g.
> 
> > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. 
> slot width e.g. 
> > > 100 GHz. For the case of (future?) mixed rate WDM signals 
> with bit rate 
> > > optimized freq. slot widths, a waveband might need a 
> start-of-waveband 
> > > and end-of-waveband (SOW-EOW) indication, instead of RNC. 
> > > 
> > > Regards, 
> > > 
> > > Maarten 
> > > 
> > > Yuri Landry wrote: 
> > > > 
> > > > Mano, 
> > > > 
> > > > >            Can someone tell me the message structure of Label 
> Request and 
> > > > >Label Mapping in GMPLS ? 
> > > > >I am confused about the presence of LightPath Id in 
> O-UNI messages 
> and LSP 
> > > > >Id in GMPLS messages ? Is there one-to-one mapping 
> between these Ids 
> or Is 
> > > > >it like that both lightPath Id and LSP Id will be 
> carried in GMPLS 
> messages 
> > > > >? LSP Id is not present in O-UNI messages. Can one 
> LightPath Id be 
> mapped 
> > > > >to 
> > > > >multiple LSP Ids or vice versa ? 
> > > > 
> > > > I think you mean Connection ID and LSP ID. A connection 
> ID is an ID 
> for 
> > > > network connection, which may consist many LSPs. For 
> example, the 
> virtual 
> > > > concatenation case. 
> > > > 
> > > > A LSP may tunnel through multiple pre-established connections. 
> > > > 
> > > > >Also, for waveband switching, the genralized label has 
> the format 
> > > > >(wavebandId - start label - end label). 
> > > > >When the label request message is received on incoming 
> interface, how
> 
> to 
> > > > >identify that the waveband label is requested ? 
> > > > >Is it the LSP encoding type or some other parameter in 
> label request 
> > > > >message 
> > > > >? If it is the Lambda encoding type then how to 
> identify that whether
> 
> a 
> > > > >lambda or waveband label is requested ? 
> > > > > 
> > > > >Also, it is mentioned that wavebandId (32 bits) is 
> selected by the 
> sender 
> > > > >and reused in all the subsequent messages. What all subsequent 
> > > > >messages is it mentioning to ? 
> > > > > 
> > > > >Can wavebandId be present in Label Withdraw/Release messages ? 
> > > > > 
> > > > >I am not able to workout the message structures for GMPLS. 
> > > > > 
> > > > 
> > > > To me waveband label defined in GMPLS drafts is a joke. 
> The reason to 
> have 
> > > > the waveband label is that someone claimed that the 
> waveband's order 
> might 
> > > > flip when going through a switch. My suggestion is 
> don't take it 
> seriously. 
> > > > 
> > > > >I am not sure how these drafts are at last call. 
> Atleast it should 
> mention 
> > > > >the message structures of various messages. 
> > > > > 
> > > > 
> > > > Agree. 
> > > > 
> > > > Regards, 
> > > > 
> > > > Yuri 
> > > > 
> _________________________________________________________________ 
> > > > Get your FREE download of MSN Explorer at 
> http://explorer.msn.com 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> John Drake wrote: 
> > 
> > Yuri, 
> > 
> > I've attached a private note I sent to Dimitri regarding waveband 
> switching. 
> > It was originally put in at the suggestion of NorTel.  For 
> both waveband 
> > switching and fiber switching, you are dealing with a 
> situation in which 
> you 
> > are using a standardized control plane to establish a 
> multi-hop LSP with 
> > proprietary encoding of data.  As I mentioned, this would 
> be accomplished 
> > using link coloring. 
> > 
> > Personally, I have no problem removing either waveband 
> switching or fiber 
> > switching, but we know have to accomodate them wrt the 
> control plane, and 
> I 
> > seriously doubt that there will ever be a completely 
> non-proprietary of 
> > encoding the data for these types of LSPs. 
> > 
> > Note that I am using 'proprietary' in the exclusive sense. 
> > 
> > Thanks, 
> > 
> > John 
> > -----Original Message----- 
> > From: John Drake 
> > Sent: Wednesday, March 28, 2001 11:15 AM 
> > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger 
> > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked] 
> > Subject: RE: Waveband Switching (was Re: GMPLS signaling) 
> > 
> > Dimitri. 
> > 
> > It's probably better to think of waveband switching as a 
> special form of 
> > fiber switching; i.e., it has nothing to do with the 
> SONET/SDH stuff at 
> all. 
> > Suppose the trunk side of a DWDM system is attached to a 
> PXC.  In the 
> fiber 
> > switching case, the fiber between the DWDM system and a 
> port on the PXC 
> > contains the entire set of lambdas, while in the waveband 
> switching case 
> > there is a set of fibers between the DWDM system and a set 
> of ports on the
> 
> > PXC, each of which contains a separate waveband. 
> > 
> > In either case, the encoding of the signal on the fibers is 
> completely 
> > proprietary, and it's the job of routing to ensure that a 
> correct path 
> > through the network is obtained, such that the proprietary 
> encoding is 
> > maintained end-end.  This would probably be done through 
> link coloring, so
> 
> > that you only route across links that support NorTel 
> waveband switching or
> 
> > Tellabs waveband switching. 
> > 
> > So I think the signalling stuff is fine. 
> > 
> > Thanks, 
> > 
> > John 
> > 
> > -----Original Message----- 
> > From: Yuri Landry [mailto:[email-masked]] 
> > Sent: Friday, May 25, 2001 7:02 AM 
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked] 
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > concatena tion 
> > 
> > Hello All, 
> > 
> > So far, our discussions are focusing on the SONET/SDH 
> draft. I'd like to 
> > re-direct your attention to other drafts. Rob's suggestion 
> should apply to
> 
> > other drafts too. 
> > 
> > One example, is the waveband switching and waveband label a 
> standard or 
> > proprietary? Can author explain to me what exactly they 
> means? How do they
> 
> > work? Any other standard reference? There are questions 
> about it but no 
> > answer yet. 
> > 
> > Regards, 
> > 
> > Yuri. 
> > 
> > >From: "Lazer, Monica A, NNAD" <[email-masked]> 
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked], 
> > >[email-masked], q11/15 <[email-masked]>, 
>   "t1x1.5" 
> > ><[email-masked]> 
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> concatena 
> > >tion 
> > >Date: Thu, 24 May 2001 18:11:36 -0400 
> > > 
> > > 
> > >Rob, You proposal makes a lot of sense. Having the 
> signaling standard 
> > >support proprietary transport may jeopardize 
> interoperability. The issue 
> is 
> > >not about GMPLS supporting non-standard rates, the issue 
> is about putting
> 
> > >in 
> > >formal and very specific support for a proprietary 
> transport solution in 
> a 
> > >standard document for signaling without taking the 
> transport portion to a
> 
> > >standards body. Having formal signaling support for a proprietary 
> > >concatenation may cause interoperability issues when other 
> vendors have a
> 
> > >different solution to the concatenation and while the 
> signaling would 
> > >indicate the concatenation, the actual transport may not 
> work.   On the 
> > >other hand we recognize that there may be a need for some 
> interim support
> 
> > >for proprietary solutions. 
> > > 
> > > 
> > >Eric, 
> > >Below I have some additional specific comments for the 
> document GMPLS 
> > >Extensions for SONET and SDH Control 
> > > 
> > > 
> > >CCT field (3 bits) 
> > >Since arbitrary contiguous concatenation is not a standard 
> concatenation,
> 
> > >it 
> > >falls within the vendor proprietary set of solutions. 
> > > 
> > >So the CCT bits may be used as follows: 
> > >000    No contiguous concatenation requested 
> > >001    Standard contiguous concatenation 
> > >others Vendor specific contiguous concatenation 
> > > 
> > >Alternatively, a better solution is to use only 2 bits for 
> this field and
> 
> > >use one bit to show whether contiguous concatenation is 
> requested and the
> 
> > >second bit to show whether it is standard or non-standard 
> contiguous 
> > >concatenation. 
> > > 
> > > 
> > >NCC field (16 bits) 
> > >This information is not sufficient. 
> > >NCC needs better description than a zero or non-zero number. 
> > > 
> > >SDH and SONET Labels 
> > > 
> > >Text in this section (Section 3, paragraphs 5 and 6) 
> indicates that the 
> > >GMPLS proposal limits virtual concatenation to remain 
> within a single 
> > >(component) link. If I understand this correctly, it means 
> that GMPLS 
> will 
> > >not allow inverse multiplexing (virtual concatenation) in 
> the transport 
> > >plane if it requires different component links. This is 
> too limiting. 
> > > 
> > >Annex 1 (sent out by Eric Mannie on 5/22) 
> > >Defines another type of concatenation - Flexible arbitrary 
> contiguous 
> > >concatenation without describing precisely how it affects 
> the OH bits. 
> This 
> > >means that it will be impossible to have this type of 
> concatenation in a 
> > >multi vendor environment based only on the GMPLS signaling. If the 
> > >transport 
> > >plane is proprietary, having the option in the signaling 
> message will not
> 
> > >fix the interoperability problem between two different 
> vendors supporting
> 
> > >their proprietary versions of arbitrary concatenation. 
> > > 
> > >Annex 2 (sent out by Eric Mannie on 5/22) 
> > >Arbitrary contiguous concatenation needs definition work for 
> > >interoperability. 
> > >Flexible arbitrary contiguous concatenation may be 
> available today to 
> > >support contiguous signals, but it is not defined in the current 
> standards. 
> > >Clear agreements on OH usage are needed between supporting 
> vendors. 
> > >Maintenance and tracking of the signal needs to be well 
> understood. 
> > > 
> > > 
> > > 
> > >Monica A. Lazer 
> > >Advanced Transport Technology and Architecture Planning 
> > > 
> > >908 234 8462 
> > >[email-masked] 
> > > 
> > > 
> > >-----Original Message----- 
> > >From: Rob Coltun [mailto:[email-masked]] 
> > >Sent: Thursday, May 24, 2001 7:24 PM 
> > >To: [email-masked]; [email-masked]; 
> q11/15; t1x1.5 
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > >concatenation 
> > > 
> > >All, 
> > >     despite the heated arguments I think the discussion 
> is important to 
> > >have. 
> > > 
> > >I suggest that instead of  tagging non/pre-standard items 
> in the current 
> > >drafts 
> > >that they be put into a separate Informational document  - 
> this is the 
> > >cleanest thing to do. 
> > >We (the IETF) do have a tradition of publishing company 
> proprietary 
> > >protocols 
> > >but not as standard track documents. 
> > > 
> > >thanks, 
> > >---rob 
> > > 
> > > 
> > > 
> > >_______________________________________________ 
> > >IP-Optical mailing list 
> > >[email-masked] 
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> > > 
> > 
> > _________________________________________________________________ 
> > Get your FREE download of MSN Explorer at http://explorer.msn.com 
> > 
> > _______________________________________________ 
> > IP-Optical mailing list 
> > [email-masked] 
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> 

Delivery-date: Mon, 28 May 2001 09:54:29 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>
Subject: RE: Dead of GMPLS ?
Date: Mon, 28 May 2001 12:55:35 -0400

Eric:

I understand your frustration, but the current
state of affairs was waiting to happen given the
speed and zeal with which all sorts of features
were being proposed as candidates for GMPLS control.
I think the best way to move forward is to
get some consensus on the set of well-defined
features/capabilities that
people agree have *current relevance*. Other features,
drop them/move to different drafts/what not.
It doesn't seem sensible to stop progress
on the most general aspects of gmpls for the
sake of supporting features whose 
near-to-intermediate term
significance is dubious.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 11:37 AM
> To: 'Guo-Qiang Wang'
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject: RE: Dead of GMPLS ?
> 
> 
> Hello Guo-Qiang,
> 
> >  If one non-SONET/SDH-standard feature could decide the death or the
> liveness 
> of GMPLS, it is the reason I strongly suggest you guys remove 
> this feature 
> to a separate document to keep GMPLS alive.  Up to now, all 
> the arguments we
> have 
> seen are focusing on non-SONET/SDH-standard issue, not on 
> lambda switching
> and fiber switching. 
> 
> No, please read the included e-mails and the e-mails that I 
> was referred to,
> they are talking about waveband switching, etc..
> 
> We are now speaking about removing waveband switching, about 
> where to put
> protection/restoration, and about scanning all the GMPLS 
> drafts to see what
> should be removed (see the three e-mails from Maarten).
> 
> I am discussing the general principle of moving all 
> non-standard related
> features to separate documents. If you want to do it for 
> technology A, to
> stay consistent you have to do it also for technology B, C, etc.
> 
> Of course you have to remove lambda switching since this is 
> proprietary
> (what are the parameters to control, to signal, etc... we 
> don't know yet) -
> It is too early in this draft to speak about that before 
> knowing how exactly
> the transmission plane will look like. There is no value of having a
> standardized control plane to control proprietary networks (as I
> understood).
> 
> My list of features to remove contains at least:
> 
> - SDH/SONET transparency.
> - SDH/SONET arbitrary concatenation, flexible concatenation.
> - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> - All kinds of end-to-end protection/restoration for any 
> layer, except the
> IP layer.
> - The Waveband switching object and its concept.
> - The concept of LSC and FSC layers, i.e. concept of lambda and fiber
> switching.
> - The label set object (only used for lambda issues).
> - LSP encoding type, bandwidth encoding and GPID have to be simplified
> accordingly.
> - MPLS extensions to control G.709 (since multiplexing, etc is not yet
> defined).
> - etc...
> 
> Something else to add to this list ?
> 
> Rgds,
> 
> Eric
> 
> 
> 
> -----Original Message-----
> From: Guo-Qiang Wang [mailto:[email-masked]]
> Sent: Monday, May 28, 2001 4:24 PM
> To: Mannie, Eric; 'Maarten Vissers'
> Cc: 'Yuri Landry'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject: RE: Dead of GMPLS ?
> 
> 
> Hi, 
>   If one non-SONET/SDH-standard feature could decide the death or the
> liveness 
> of GMPLS, it is the reason I strongly suggest you guys remove 
> this feature 
> to a separate document to keep GMPLS alive. Up to now, all 
> the arguments we
> have 
> seen are focusing on non-SONET/SDH-standard issue, not on 
> lambda switching
> and fiber switching. 
>   Regards,  
> G.Q Wang 
> Technical Manager 
> Emerging Network Technology 
> Nortel Networks 
> Tel: (613)765-4195 (ESN 395-4195) 
> Fax: (613)768-1140 
> [email-masked] 
> -----Original Message----- 
> From:   Mannie, Eric [SMTP:[email-masked]] 
> Sent:   Monday, May 28, 2001 9:08 AM 
> To:     'Maarten Vissers' 
> Cc:     'Yuri Landry'; [email-masked]; 
> [email-masked];
> [email-masked]; [email-masked]; q16/15; John Drake
> Subject:        Dead of GMPLS ? 
> Hello Maarten, 
> E-mail 1: 
> >Let's review the series of GMPLS 
>                   ^^^^^^ 
> >draft documents to identify the non/pre-standard items and then move 
> >those items into separate Informational documents. 
> ^                          ^^^^^^^^^^^^^^^^^^^^^^^ 
> E-mail 2: 
> > Yuri started the discussion on wavebands some days ago. 
> Wavebands are 
> > yet undefined in the transport plane. 
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> E-mail 3: 
> >Triggered by Yuri's email, I would like to offer another 
> area for closer 
> >look: protection switching. The standardised SDH protection 
> switching 
> >schemes are specified in G.841 with further support in G.783. 
> > 
> >When reading the protection switching text some time ago in 
> the GMPLs 
> >draft I noticed several extensions to be described beyond those in 
> >G.841. 
> > 
> >My request is to review the latest text against G.841/G.783, 
> identify 
> >the extensions and (as now proposed by several of us) move those 
> >extensions into a separate Informational document. 
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> The transmission plane for optical networks is not standardized: DWDM 
> systems are proprietary and don't interoperate. 
> So I guess that we have to remove the concept of optical 
> switching (lambda 
> switching, fiber switching, waveband switching) from GMPLS if 
> we want to 
> follow your model of thinking. We also have to remove any end-to-end 
> protection/restoration and all non standardized SDH/SONET 
> behaviors (even if
> 
> they don't change the standards) as you said. 
> Everything will become informational, except may be a very small root 
> specification (that will not be allowed to speak about any optical 
> switching). 
> Since the IETF will not have any standard (track) RFC, ITU-T 
> will have to 
> claim that there is no existing standard and do one... 
> What is the benefit of moving all the interesting signaling 
> features to 
> informational RFC's ? If we don't have signaling standards 
> why should we 
> continue to work on GMPLS ? Why should we spend so much energy of 
> informational documents that have no standard value ? That 
> will be an easy 
> marketing message "GMPLS: don't pay attention to it, it is only 
> informational, you need a standard". 
> Either GMPLS is dead, or we accept that GMPLS ALLOWS TO 
> CONTROL STANDARDIZED
> 
> AND NON STANDARDIZED DATA/TRANSMISSION PLANES. 
> Regards, 
> Eric 
> -----Original Message----- 
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Monday, May 28, 2001 11:03 AM 
> To: John Drake 
> Cc: 'Yuri Landry'; [email-masked]; 
> [email-masked]; 
> [email-masked]; [email-masked]; q16/15 
> Subject: [IP-Optical] GMPLS: waveband switching 
> 
> 
> John, 
> Yuri started the discussion on wavebands some days ago. Wavebands are 
> yet undefined in the transport plane. Looking into it a few 
> days ago, I 
> tried to provide a definition of waveband and got immediately 
> corrected 
> by an optical expert, resulting in an adapted definition of waveband 
> (see email below). 
> At this point in time, a waveband seems to be a group of 
> Optical Channel 
> (OCh) signals. It represents a partition, not a new layer network. As 
> such a waveband should be represented as a "group of OCh 
> signals" within 
> the OCh layer network. 
> Regards, 
> Maarten 
> 
> 
> 
> Maarten Vissers wrote: 
> > 
> > Manoj, Yuri, 
> > 
> > I received a message that my definition of waveband is too 
> restricted. 
> > 
> > A waveband should be an optical multiplex, administered as a single 
> > bundle, not necessary contiguous in frequency slot. 
> > 
> >         E.g. there may be good technical reasons to consider a 
> >         'waveband' created at an OADM formed by taking every 2nd 
> >         wavelength in a 50GHz-spaced transmission band. 
> > 
> > In first instance the above definition may not be 
> considered this as a 
> > "band"; it 
> > looks more like a "gapped-band" :-). Nevertheless, due to technical 
> > reasons we should consider a waveband as just another name for a 
> > particular group of wavelengths, which may best be viewed 
> as a group of 
> > identified/listed wavelengths. 
> > 
> > Regards, 
> > 
> > Maarten 
> > 
> > Maarten Vissers wrote: 
> > > 
> > > Manoj, Yuri, 
> > > 
> > > In my current understanding, a waveband is a group of OCh 
> (optical 
> > > channel) signals located in a contiguous set of tributary (i.e. 
> > > frequency) slots. 
> > > 
> > > A waveband is therefore related to partitioning, rather 
> than a layering.
> 
> > > A waveband shouldn't have an LSP encoding type itself, 
> but instead be 
> > > part of the OCh layer network. E.g. a specific RGT 
> (requested groupting 
> > > type) of "contiguous waveband" can be defined for this 
> purpose with the 
> > > RNC (requested number of components) indicating the size of the 
> > > waveband. 
> > > 
> > > The above is simply a first shot; in general the issue 
> can be more 
> > > complex due to the fact that the frequency slot for a 
> 2G5, a 10G and a 
> > > 40G signal may have differnet bandwidths: e.g. 2G5 freq. 
> slot width e.g.
> 
> > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. 
> slot width e.g. 
> > > 100 GHz. For the case of (future?) mixed rate WDM signals 
> with bit rate 
> > > optimized freq. slot widths, a waveband might need a 
> start-of-waveband 
> > > and end-of-waveband (SOW-EOW) indication, instead of RNC. 
> > > 
> > > Regards, 
> > > 
> > > Maarten 
> > > 
> > > Yuri Landry wrote: 
> > > > 
> > > > Mano, 
> > > > 
> > > > >            Can someone tell me the message structure of Label 
> Request and 
> > > > >Label Mapping in GMPLS ? 
> > > > >I am confused about the presence of LightPath Id in 
> O-UNI messages 
> and LSP 
> > > > >Id in GMPLS messages ? Is there one-to-one mapping 
> between these Ids 
> or Is 
> > > > >it like that both lightPath Id and LSP Id will be 
> carried in GMPLS 
> messages 
> > > > >? LSP Id is not present in O-UNI messages. Can one 
> LightPath Id be 
> mapped 
> > > > >to 
> > > > >multiple LSP Ids or vice versa ? 
> > > > 
> > > > I think you mean Connection ID and LSP ID. A connection 
> ID is an ID 
> for 
> > > > network connection, which may consist many LSPs. For 
> example, the 
> virtual 
> > > > concatenation case. 
> > > > 
> > > > A LSP may tunnel through multiple pre-established connections. 
> > > > 
> > > > >Also, for waveband switching, the genralized label has 
> the format 
> > > > >(wavebandId - start label - end label). 
> > > > >When the label request message is received on incoming 
> interface, how
> 
> to 
> > > > >identify that the waveband label is requested ? 
> > > > >Is it the LSP encoding type or some other parameter in 
> label request 
> > > > >message 
> > > > >? If it is the Lambda encoding type then how to 
> identify that whether
> 
> a 
> > > > >lambda or waveband label is requested ? 
> > > > > 
> > > > >Also, it is mentioned that wavebandId (32 bits) is 
> selected by the 
> sender 
> > > > >and reused in all the subsequent messages. What all subsequent 
> > > > >messages is it mentioning to ? 
> > > > > 
> > > > >Can wavebandId be present in Label Withdraw/Release messages ? 
> > > > > 
> > > > >I am not able to workout the message structures for GMPLS. 
> > > > > 
> > > > 
> > > > To me waveband label defined in GMPLS drafts is a joke. 
> The reason to 
> have 
> > > > the waveband label is that someone claimed that the 
> waveband's order 
> might 
> > > > flip when going through a switch. My suggestion is 
> don't take it 
> seriously. 
> > > > 
> > > > >I am not sure how these drafts are at last call. 
> Atleast it should 
> mention 
> > > > >the message structures of various messages. 
> > > > > 
> > > > 
> > > > Agree. 
> > > > 
> > > > Regards, 
> > > > 
> > > > Yuri 
> > > > 
> _________________________________________________________________ 
> > > > Get your FREE download of MSN Explorer at 
> http://explorer.msn.com 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> John Drake wrote: 
> > 
> > Yuri, 
> > 
> > I've attached a private note I sent to Dimitri regarding waveband 
> switching. 
> > It was originally put in at the suggestion of NorTel.  For 
> both waveband 
> > switching and fiber switching, you are dealing with a 
> situation in which 
> you 
> > are using a standardized control plane to establish a 
> multi-hop LSP with 
> > proprietary encoding of data.  As I mentioned, this would 
> be accomplished 
> > using link coloring. 
> > 
> > Personally, I have no problem removing either waveband 
> switching or fiber 
> > switching, but we know have to accomodate them wrt the 
> control plane, and 
> I 
> > seriously doubt that there will ever be a completely 
> non-proprietary of 
> > encoding the data for these types of LSPs. 
> > 
> > Note that I am using 'proprietary' in the exclusive sense. 
> > 
> > Thanks, 
> > 
> > John 
> > -----Original Message----- 
> > From: John Drake 
> > Sent: Wednesday, March 28, 2001 11:15 AM 
> > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger 
> > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked] 
> > Subject: RE: Waveband Switching (was Re: GMPLS signaling) 
> > 
> > Dimitri. 
> > 
> > It's probably better to think of waveband switching as a 
> special form of 
> > fiber switching; i.e., it has nothing to do with the 
> SONET/SDH stuff at 
> all. 
> > Suppose the trunk side of a DWDM system is attached to a 
> PXC.  In the 
> fiber 
> > switching case, the fiber between the DWDM system and a 
> port on the PXC 
> > contains the entire set of lambdas, while in the waveband 
> switching case 
> > there is a set of fibers between the DWDM system and a set 
> of ports on the
> 
> > PXC, each of which contains a separate waveband. 
> > 
> > In either case, the encoding of the signal on the fibers is 
> completely 
> > proprietary, and it's the job of routing to ensure that a 
> correct path 
> > through the network is obtained, such that the proprietary 
> encoding is 
> > maintained end-end.  This would probably be done through 
> link coloring, so
> 
> > that you only route across links that support NorTel 
> waveband switching or
> 
> > Tellabs waveband switching. 
> > 
> > So I think the signalling stuff is fine. 
> > 
> > Thanks, 
> > 
> > John 
> > 
> > -----Original Message----- 
> > From: Yuri Landry [mailto:[email-masked]] 
> > Sent: Friday, May 25, 2001 7:02 AM 
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked] 
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > concatena tion 
> > 
> > Hello All, 
> > 
> > So far, our discussions are focusing on the SONET/SDH 
> draft. I'd like to 
> > re-direct your attention to other drafts. Rob's suggestion 
> should apply to
> 
> > other drafts too. 
> > 
> > One example, is the waveband switching and waveband label a 
> standard or 
> > proprietary? Can author explain to me what exactly they 
> means? How do they
> 
> > work? Any other standard reference? There are questions 
> about it but no 
> > answer yet. 
> > 
> > Regards, 
> > 
> > Yuri. 
> > 
> > >From: "Lazer, Monica A, NNAD" <[email-masked]> 
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked], 
> > >[email-masked], q11/15 <[email-masked]>, 
>   "t1x1.5" 
> > ><[email-masked]> 
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> concatena 
> > >tion 
> > >Date: Thu, 24 May 2001 18:11:36 -0400 
> > > 
> > > 
> > >Rob, You proposal makes a lot of sense. Having the 
> signaling standard 
> > >support proprietary transport may jeopardize 
> interoperability. The issue 
> is 
> > >not about GMPLS supporting non-standard rates, the issue 
> is about putting
> 
> > >in 
> > >formal and very specific support for a proprietary 
> transport solution in 
> a 
> > >standard document for signaling without taking the 
> transport portion to a
> 
> > >standards body. Having formal signaling support for a proprietary 
> > >concatenation may cause interoperability issues when other 
> vendors have a
> 
> > >different solution to the concatenation and while the 
> signaling would 
> > >indicate the concatenation, the actual transport may not 
> work.   On the 
> > >other hand we recognize that there may be a need for some 
> interim support
> 
> > >for proprietary solutions. 
> > > 
> > > 
> > >Eric, 
> > >Below I have some additional specific comments for the 
> document GMPLS 
> > >Extensions for SONET and SDH Control 
> > > 
> > > 
> > >CCT field (3 bits) 
> > >Since arbitrary contiguous concatenation is not a standard 
> concatenation,
> 
> > >it 
> > >falls within the vendor proprietary set of solutions. 
> > > 
> > >So the CCT bits may be used as follows: 
> > >000    No contiguous concatenation requested 
> > >001    Standard contiguous concatenation 
> > >others Vendor specific contiguous concatenation 
> > > 
> > >Alternatively, a better solution is to use only 2 bits for 
> this field and
> 
> > >use one bit to show whether contiguous concatenation is 
> requested and the
> 
> > >second bit to show whether it is standard or non-standard 
> contiguous 
> > >concatenation. 
> > > 
> > > 
> > >NCC field (16 bits) 
> > >This information is not sufficient. 
> > >NCC needs better description than a zero or non-zero number. 
> > > 
> > >SDH and SONET Labels 
> > > 
> > >Text in this section (Section 3, paragraphs 5 and 6) 
> indicates that the 
> > >GMPLS proposal limits virtual concatenation to remain 
> within a single 
> > >(component) link. If I understand this correctly, it means 
> that GMPLS 
> will 
> > >not allow inverse multiplexing (virtual concatenation) in 
> the transport 
> > >plane if it requires different component links. This is 
> too limiting. 
> > > 
> > >Annex 1 (sent out by Eric Mannie on 5/22) 
> > >Defines another type of concatenation - Flexible arbitrary 
> contiguous 
> > >concatenation without describing precisely how it affects 
> the OH bits. 
> This 
> > >means that it will be impossible to have this type of 
> concatenation in a 
> > >multi vendor environment based only on the GMPLS signaling. If the 
> > >transport 
> > >plane is proprietary, having the option in the signaling 
> message will not
> 
> > >fix the interoperability problem between two different 
> vendors supporting
> 
> > >their proprietary versions of arbitrary concatenation. 
> > > 
> > >Annex 2 (sent out by Eric Mannie on 5/22) 
> > >Arbitrary contiguous concatenation needs definition work for 
> > >interoperability. 
> > >Flexible arbitrary contiguous concatenation may be 
> available today to 
> > >support contiguous signals, but it is not defined in the current 
> standards. 
> > >Clear agreements on OH usage are needed between supporting 
> vendors. 
> > >Maintenance and tracking of the signal needs to be well 
> understood. 
> > > 
> > > 
> > > 
> > >Monica A. Lazer 
> > >Advanced Transport Technology and Architecture Planning 
> > > 
> > >908 234 8462 
> > >[email-masked] 
> > > 
> > > 
> > >-----Original Message----- 
> > >From: Rob Coltun [mailto:[email-masked]] 
> > >Sent: Thursday, May 24, 2001 7:24 PM 
> > >To: [email-masked]; [email-masked]; 
> q11/15; t1x1.5 
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > >concatenation 
> > > 
> > >All, 
> > >     despite the heated arguments I think the discussion 
> is important to 
> > >have. 
> > > 
> > >I suggest that instead of  tagging non/pre-standard items 
> in the current 
> > >drafts 
> > >that they be put into a separate Informational document  - 
> this is the 
> > >cleanest thing to do. 
> > >We (the IETF) do have a tradition of publishing company 
> proprietary 
> > >protocols 
> > >but not as standard track documents. 
> > > 
> > >thanks, 
> > >---rob 
> > > 
> > > 
> > > 
> > >_______________________________________________ 
> > >IP-Optical mailing list 
> > >[email-masked] 
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> > > 
> > 
> > _________________________________________________________________ 
> > Get your FREE download of MSN Explorer at http://explorer.msn.com 
> > 
> > _______________________________________________ 
> > IP-Optical mailing list 
> > [email-masked] 
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> 

Delivery-date: Mon, 28 May 2001 08:38:54 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Guo-Qiang Wang' <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked],  [email-masked], q16/15 <[email-masked]>, John Drake <[email-masked]>
Subject: RE: Dead of GMPLS ?
Date: Mon, 28 May 2001 17:36:55 +0200

Hello Guo-Qiang,

>  If one non-SONET/SDH-standard feature could decide the death or the
liveness 
of GMPLS, it is the reason I strongly suggest you guys remove this feature 
to a separate document to keep GMPLS alive.  Up to now, all the arguments we
have 
seen are focusing on non-SONET/SDH-standard issue, not on lambda switching
and fiber switching. 

No, please read the included e-mails and the e-mails that I was referred to,
they are talking about waveband switching, etc..

We are now speaking about removing waveband switching, about where to put
protection/restoration, and about scanning all the GMPLS drafts to see what
should be removed (see the three e-mails from Maarten).

I am discussing the general principle of moving all non-standard related
features to separate documents. If you want to do it for technology A, to
stay consistent you have to do it also for technology B, C, etc.

Of course you have to remove lambda switching since this is proprietary
(what are the parameters to control, to signal, etc... we don't know yet) -
It is too early in this draft to speak about that before knowing how exactly
the transmission plane will look like. There is no value of having a
standardized control plane to control proprietary networks (as I
understood).

My list of features to remove contains at least:

- SDH/SONET transparency.
- SDH/SONET arbitrary concatenation, flexible concatenation.
- AUG-X, TUG, STS Groups signal types and LSP capabilities.
- All kinds of end-to-end protection/restoration for any layer, except the
IP layer.
- The Waveband switching object and its concept.
- The concept of LSC and FSC layers, i.e. concept of lambda and fiber
switching.
- The label set object (only used for lambda issues).
- LSP encoding type, bandwidth encoding and GPID have to be simplified
accordingly.
- MPLS extensions to control G.709 (since multiplexing, etc is not yet
defined).
- etc...

Something else to add to this list ?

Rgds,

Eric

-----Original Message-----
From: Guo-Qiang Wang [mailto:[email-masked]]
Sent: Monday, May 28, 2001 4:24 PM
To: Mannie, Eric; 'Maarten Vissers'
Cc: 'Yuri Landry'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; q16/15; John Drake
Subject: RE: Dead of GMPLS ?

Hi, 
  If one non-SONET/SDH-standard feature could decide the death or the
liveness 
of GMPLS, it is the reason I strongly suggest you guys remove this feature 
to a separate document to keep GMPLS alive. Up to now, all the arguments we
have 
seen are focusing on non-SONET/SDH-standard issue, not on lambda switching
and fiber switching. 
  Regards,  
G.Q Wang 
Technical Manager 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 
-----Original Message----- 
From:   Mannie, Eric [SMTP:[email-masked]] 
Sent:   Monday, May 28, 2001 9:08 AM 
To:     'Maarten Vissers' 
Cc:     'Yuri Landry'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; q16/15; John Drake
Subject:        Dead of GMPLS ? 
Hello Maarten, 
E-mail 1: 
>Let's review the series of GMPLS 
                  ^^^^^^ 
>draft documents to identify the non/pre-standard items and then move 
>those items into separate Informational documents. 
^                          ^^^^^^^^^^^^^^^^^^^^^^^ 
E-mail 2: 
> Yuri started the discussion on wavebands some days ago. Wavebands are 
> yet undefined in the transport plane. 
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
E-mail 3: 
>Triggered by Yuri's email, I would like to offer another area for closer 
>look: protection switching. The standardised SDH protection switching 
>schemes are specified in G.841 with further support in G.783. 
> 
>When reading the protection switching text some time ago in the GMPLs 
>draft I noticed several extensions to be described beyond those in 
>G.841. 
> 
>My request is to review the latest text against G.841/G.783, identify 
>the extensions and (as now proposed by several of us) move those 
>extensions into a separate Informational document. 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
The transmission plane for optical networks is not standardized: DWDM 
systems are proprietary and don't interoperate. 
So I guess that we have to remove the concept of optical switching (lambda 
switching, fiber switching, waveband switching) from GMPLS if we want to 
follow your model of thinking. We also have to remove any end-to-end 
protection/restoration and all non standardized SDH/SONET behaviors (even if

they don't change the standards) as you said. 
Everything will become informational, except may be a very small root 
specification (that will not be allowed to speak about any optical 
switching). 
Since the IETF will not have any standard (track) RFC, ITU-T will have to 
claim that there is no existing standard and do one... 
What is the benefit of moving all the interesting signaling features to 
informational RFC's ? If we don't have signaling standards why should we 
continue to work on GMPLS ? Why should we spend so much energy of 
informational documents that have no standard value ? That will be an easy 
marketing message "GMPLS: don't pay attention to it, it is only 
informational, you need a standard". 
Either GMPLS is dead, or we accept that GMPLS ALLOWS TO CONTROL STANDARDIZED

AND NON STANDARDIZED DATA/TRANSMISSION PLANES. 
Regards, 
Eric 
-----Original Message----- 
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, May 28, 2001 11:03 AM 
To: John Drake 
Cc: 'Yuri Landry'; [email-masked]; [email-masked]; 
[email-masked]; [email-masked]; q16/15 
Subject: [IP-Optical] GMPLS: waveband switching 

John, 
Yuri started the discussion on wavebands some days ago. Wavebands are 
yet undefined in the transport plane. Looking into it a few days ago, I 
tried to provide a definition of waveband and got immediately corrected 
by an optical expert, resulting in an adapted definition of waveband 
(see email below). 
At this point in time, a waveband seems to be a group of Optical Channel 
(OCh) signals. It represents a partition, not a new layer network. As 
such a waveband should be represented as a "group of OCh signals" within 
the OCh layer network. 
Regards, 
Maarten 

Maarten Vissers wrote: 
> 
> Manoj, Yuri, 
> 
> I received a message that my definition of waveband is too restricted. 
> 
> A waveband should be an optical multiplex, administered as a single 
> bundle, not necessary contiguous in frequency slot. 
> 
>         E.g. there may be good technical reasons to consider a 
>         'waveband' created at an OADM formed by taking every 2nd 
>         wavelength in a 50GHz-spaced transmission band. 
> 
> In first instance the above definition may not be considered this as a 
> "band"; it 
> looks more like a "gapped-band" :-). Nevertheless, due to technical 
> reasons we should consider a waveband as just another name for a 
> particular group of wavelengths, which may best be viewed as a group of 
> identified/listed wavelengths. 
> 
> Regards, 
> 
> Maarten 
> 
> Maarten Vissers wrote: 
> > 
> > Manoj, Yuri, 
> > 
> > In my current understanding, a waveband is a group of OCh (optical 
> > channel) signals located in a contiguous set of tributary (i.e. 
> > frequency) slots. 
> > 
> > A waveband is therefore related to partitioning, rather than a layering.

> > A waveband shouldn't have an LSP encoding type itself, but instead be 
> > part of the OCh layer network. E.g. a specific RGT (requested groupting 
> > type) of "contiguous waveband" can be defined for this purpose with the 
> > RNC (requested number of components) indicating the size of the 
> > waveband. 
> > 
> > The above is simply a first shot; in general the issue can be more 
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a 
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.

> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g. 
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate 
> > optimized freq. slot widths, a waveband might need a start-of-waveband 
> > and end-of-waveband (SOW-EOW) indication, instead of RNC. 
> > 
> > Regards, 
> > 
> > Maarten 
> > 
> > Yuri Landry wrote: 
> > > 
> > > Mano, 
> > > 
> > > >            Can someone tell me the message structure of Label 
Request and 
> > > >Label Mapping in GMPLS ? 
> > > >I am confused about the presence of LightPath Id in O-UNI messages 
and LSP 
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids 
or Is 
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS 
messages 
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be 
mapped 
> > > >to 
> > > >multiple LSP Ids or vice versa ? 
> > > 
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID 
for 
> > > network connection, which may consist many LSPs. For example, the 
virtual 
> > > concatenation case. 
> > > 
> > > A LSP may tunnel through multiple pre-established connections. 
> > > 
> > > >Also, for waveband switching, the genralized label has the format 
> > > >(wavebandId - start label - end label). 
> > > >When the label request message is received on incoming interface, how

to 
> > > >identify that the waveband label is requested ? 
> > > >Is it the LSP encoding type or some other parameter in label request 
> > > >message 
> > > >? If it is the Lambda encoding type then how to identify that whether

a 
> > > >lambda or waveband label is requested ? 
> > > > 
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the 
sender 
> > > >and reused in all the subsequent messages. What all subsequent 
> > > >messages is it mentioning to ? 
> > > > 
> > > >Can wavebandId be present in Label Withdraw/Release messages ? 
> > > > 
> > > >I am not able to workout the message structures for GMPLS. 
> > > > 
> > > 
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to 
have 
> > > the waveband label is that someone claimed that the waveband's order 
might 
> > > flip when going through a switch. My suggestion is don't take it 
seriously. 
> > > 
> > > >I am not sure how these drafts are at last call. Atleast it should 
mention 
> > > >the message structures of various messages. 
> > > > 
> > > 
> > > Agree. 
> > > 
> > > Regards, 
> > > 
> > > Yuri 
> > > _________________________________________________________________ 
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com 

John Drake wrote: 
> 
> Yuri, 
> 
> I've attached a private note I sent to Dimitri regarding waveband 
switching. 
> It was originally put in at the suggestion of NorTel.  For both waveband 
> switching and fiber switching, you are dealing with a situation in which 
you 
> are using a standardized control plane to establish a multi-hop LSP with 
> proprietary encoding of data.  As I mentioned, this would be accomplished 
> using link coloring. 
> 
> Personally, I have no problem removing either waveband switching or fiber 
> switching, but we know have to accomodate them wrt the control plane, and 
I 
> seriously doubt that there will ever be a completely non-proprietary of 
> encoding the data for these types of LSPs. 
> 
> Note that I am using 'proprietary' in the exclusive sense. 
> 
> Thanks, 
> 
> John 
> -----Original Message----- 
> From: John Drake 
> Sent: Wednesday, March 28, 2001 11:15 AM 
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger 
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked] 
> Subject: RE: Waveband Switching (was Re: GMPLS signaling) 
> 
> Dimitri. 
> 
> It's probably better to think of waveband switching as a special form of 
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at 
all. 
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the 
fiber 
> switching case, the fiber between the DWDM system and a port on the PXC 
> contains the entire set of lambdas, while in the waveband switching case 
> there is a set of fibers between the DWDM system and a set of ports on the

> PXC, each of which contains a separate waveband. 
> 
> In either case, the encoding of the signal on the fibers is completely 
> proprietary, and it's the job of routing to ensure that a correct path 
> through the network is obtained, such that the proprietary encoding is 
> maintained end-end.  This would probably be done through link coloring, so

> that you only route across links that support NorTel waveband switching or

> Tellabs waveband switching. 
> 
> So I think the signalling stuff is fine. 
> 
> Thanks, 
> 
> John 
> 
> -----Original Message----- 
> From: Yuri Landry [mailto:[email-masked]] 
> Sent: Friday, May 25, 2001 7:02 AM 
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> concatena tion 
> 
> Hello All, 
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to 
> re-direct your attention to other drafts. Rob's suggestion should apply to

> other drafts too. 
> 
> One example, is the waveband switching and waveband label a standard or 
> proprietary? Can author explain to me what exactly they means? How do they

> work? Any other standard reference? There are questions about it but no 
> answer yet. 
> 
> Regards, 
> 
> Yuri. 
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]> 
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked], 
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5" 
> ><[email-masked]> 
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
concatena 
> >tion 
> >Date: Thu, 24 May 2001 18:11:36 -0400 
> > 
> > 
> >Rob, You proposal makes a lot of sense. Having the signaling standard 
> >support proprietary transport may jeopardize interoperability. The issue 
is 
> >not about GMPLS supporting non-standard rates, the issue is about putting

> >in 
> >formal and very specific support for a proprietary transport solution in 
a 
> >standard document for signaling without taking the transport portion to a

> >standards body. Having formal signaling support for a proprietary 
> >concatenation may cause interoperability issues when other vendors have a

> >different solution to the concatenation and while the signaling would 
> >indicate the concatenation, the actual transport may not work.   On the 
> >other hand we recognize that there may be a need for some interim support

> >for proprietary solutions. 
> > 
> > 
> >Eric, 
> >Below I have some additional specific comments for the document GMPLS 
> >Extensions for SONET and SDH Control 
> > 
> > 
> >CCT field (3 bits) 
> >Since arbitrary contiguous concatenation is not a standard concatenation,

> >it 
> >falls within the vendor proprietary set of solutions. 
> > 
> >So the CCT bits may be used as follows: 
> >000    No contiguous concatenation requested 
> >001    Standard contiguous concatenation 
> >others Vendor specific contiguous concatenation 
> > 
> >Alternatively, a better solution is to use only 2 bits for this field and

> >use one bit to show whether contiguous concatenation is requested and the

> >second bit to show whether it is standard or non-standard contiguous 
> >concatenation. 
> > 
> > 
> >NCC field (16 bits) 
> >This information is not sufficient. 
> >NCC needs better description than a zero or non-zero number. 
> > 
> >SDH and SONET Labels 
> > 
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the 
> >GMPLS proposal limits virtual concatenation to remain within a single 
> >(component) link. If I understand this correctly, it means that GMPLS 
will 
> >not allow inverse multiplexing (virtual concatenation) in the transport 
> >plane if it requires different component links. This is too limiting. 
> > 
> >Annex 1 (sent out by Eric Mannie on 5/22) 
> >Defines another type of concatenation - Flexible arbitrary contiguous 
> >concatenation without describing precisely how it affects the OH bits. 
This 
> >means that it will be impossible to have this type of concatenation in a 
> >multi vendor environment based only on the GMPLS signaling. If the 
> >transport 
> >plane is proprietary, having the option in the signaling message will not

> >fix the interoperability problem between two different vendors supporting

> >their proprietary versions of arbitrary concatenation. 
> > 
> >Annex 2 (sent out by Eric Mannie on 5/22) 
> >Arbitrary contiguous concatenation needs definition work for 
> >interoperability. 
> >Flexible arbitrary contiguous concatenation may be available today to 
> >support contiguous signals, but it is not defined in the current 
standards. 
> >Clear agreements on OH usage are needed between supporting vendors. 
> >Maintenance and tracking of the signal needs to be well understood. 
> > 
> > 
> > 
> >Monica A. Lazer 
> >Advanced Transport Technology and Architecture Planning 
> > 
> >908 234 8462 
> >[email-masked] 
> > 
> > 
> >-----Original Message----- 
> >From: Rob Coltun [mailto:[email-masked]] 
> >Sent: Thursday, May 24, 2001 7:24 PM 
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5 
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> >concatenation 
> > 
> >All, 
> >     despite the heated arguments I think the discussion is important to 
> >have. 
> > 
> >I suggest that instead of  tagging non/pre-standard items in the current 
> >drafts 
> >that they be put into a separate Informational document  - this is the 
> >cleanest thing to do. 
> >We (the IETF) do have a tradition of publishing company proprietary 
> >protocols 
> >but not as standard track documents. 
> > 
> >thanks, 
> >---rob 
> > 
> > 
> > 
> >_______________________________________________ 
> >IP-Optical mailing list 
> >[email-masked] 
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical 
> > 
> 
> _________________________________________________________________ 
> Get your FREE download of MSN Explorer at http://explorer.msn.com 
> 
> _______________________________________________ 
> IP-Optical mailing list 
> [email-masked] 
> http://lists.bell-labs.com/mailman/listinfo/ip-optical 

Delivery-date: Mon, 28 May 2001 08:03:16 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Ping Pan'" <[email-masked]>, Bala Rajagopalan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Mon, 28 May 2001 11:04:21 -0400

hi ping:

The precise problem addressed and the network
node capabilities are described in
our draft 

http://www.ietf.org/internet-drafts/draft-bala-restoration-signaling-00.txt

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Ping Pan [mailto:[email-masked]]
> Sent: Sunday, May 27, 2001 2:08 PM
> To: Bala Rajagopalan
> Cc: 'C. R. Kalmanek'; [email-masked]; [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> 
> Bala Rajagopalan wrote:
> > 
> > Hi,
> > 
> > There are two aspects to this problem:
> > 
> > Pre-establishment of protection paths: This
> > is something requiring signaling support during
> > provisioning. Don't see any problem in supporting
> > this under the current GMPLS framework.
> > 
> > Real-time restoration signaling: Our
> > view is that a dedicated lightweight protocol
> > is appropriate. (of course, there are other
> > views on this :-). )
> > 
> 
> Hi,
> 
> Many backbone links are SONET, which can redirect traffic to a backup
> channel within 50 msec. This is the requirement that we are 
> dealing here
> in MPLS. So in backbone, we have to rely on pre-established LSP' for
> restoration. I doubt there is any simple method for network nodes to
> detect link failure, setup a new session and adjust all sort 
> of stuff on
> *real-time*.  I could be wrong. Does anybody have the 
> measurement timing
> data on ATM crankback?
> 
> IMHO, the only reason for using real-time restoration signaling is to
> satisfy end-user applications, where based on the network 
> feedback, the
> user application can apply various adaptive mechanisms to renew
> sessions. I don't think this is the within the framework of MPLS.
> 
> 2 cents,
> 
> - Ping
> 
> > I don't see an obvious show-stopper here w.r.t
> > progressing the current drafts for last call.
> > 
> > Regards,
> > 
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> >
> 

Delivery-date: Mon, 28 May 2001 06:56:15 -0700
From: Randy Bush <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: Proposed text for the concatenation
Date: Mon, 28 May 2001 06:54:37 -0700

> Let's treat all GMPLS specifications associated with non-standard
> transport plane features as proprietary features

i extremely intentionally do not wish to stick my size nines into what
feature should be in which category, or into which features are good,
bad, etc.

but 'standard' is pretty clearly defined in ietf (rfcs 2026, 2800),
itu, ...  processes.  [ it has been observed that much of the internet
runs on documents which are not yet full standards according to 2026 ]

'non-standard' would seem to obviously be the set which does not meet
the above criteria.  non-standard features might be proprietary or
not, the issues are orthogonal.  non-standard features might be
implemented by one or more vendors or not, the issues are orthogonal.
the point is that no standard describes them.

'proprietary' means controlling intellectual property rights are held
by one entity/vendor/..., and that the vendor has blocking ipr which
they will not reasonably license to all.  that vendor may or may not
actually implement it.  sometimes proprietary feature licenses are
traded, so only a small vendor club implements them.  but this is
still rare.

randy

Delivery-date: Mon, 28 May 2001 06:17:56 -0700
Date: Mon, 28 May 2001 15:16:41 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Mannie, Eric" <[email-masked]>
CC: "'Ash, Gerald R (Jerry)'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>, Bala Rajagopalan <[email-masked]>, John Drake <[email-masked]>
Subject: Re: GMPLS Last Calls

This is a multi-part message in MIME format.
--------------4FD2C8306AEEA0289EDB6526
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

Don't be so pessimistic...

I think (and as also proposed by Bala) that today LSP 
"provisioning" which is specified within the GMPLS-SIG 
can be associated with working, protection, shared-
protection LSP etc. Meaning there is not "semantic" 
associated with the LSP established through GMPLS so 
they can be used for any purpose.

"Restoration signalling" which can be implemented in 
many ways is today under discussion. Bala thinks about
a dedicated lighweight protocol but other solution are
feasible using current signalling protocol extensions 
or not. The good thing is that an open discussion has
been today engaged.

I don't see any problem with respect to GMPLS-SIG 
document over there. I strongly believe that the 
restoration issues can be proceeded indepedently 
from the current GMPLS drafts today on last call.  

- Dimitri.

"Mannie, Eric" wrote:
> 
> Hello Jerry
> 
> >correct, as I mentioned, SPs have been formally asked for their
> >*requirements*, but not on the GMPLS extensions
> 
> Sorry ! It is an OPEN process since the beginning, everybody can contribute
> and write a draft. There is no formal process where requirements from
> operators are asked for. I am not aware of any IETF rule about that !
> 
> You were welcome to work with us since 1.5 years but you never came to us.
> You cannot blame us that you never worked on it (we are not responsible for
> that)! This is true for the thousands of internet drafts being written at
> the IETF.
> 
> It is the responsibility of each company individually to decide if they want
> to contribute or not ! It is not the job of others companies to go to each
> possible operator/manufacturer and to lobby to have them involved.
> 
> Regards,
> 
> Eric
--------------4FD2C8306AEEA0289EDB6526
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------4FD2C8306AEEA0289EDB6526--

Delivery-date: Mon, 28 May 2001 06:10:13 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: 'Yuri Landry' <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>, John Drake <[email-masked]>
Subject: Dead of GMPLS ?
Date: Mon, 28 May 2001 15:08:01 +0200

Hello Maarten,

E-mail 1:

>Let's review the series of GMPLS
                  ^^^^^^
>draft documents to identify the non/pre-standard items and then move
>those items into separate Informational documents.
^                          ^^^^^^^^^^^^^^^^^^^^^^^

E-mail 2:

> Yuri started the discussion on wavebands some days ago. Wavebands are
> yet undefined in the transport plane.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

E-mail 3:

>Triggered by Yuri's email, I would like to offer another area for closer
>look: protection switching. The standardised SDH protection switching
>schemes are specified in G.841 with further support in G.783.
>
>When reading the protection switching text some time ago in the GMPLs
>draft I noticed several extensions to be described beyond those in
>G.841.
>
>My request is to review the latest text against G.841/G.783, identify
>the extensions and (as now proposed by several of us) move those
>extensions into a separate Informational document.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The transmission plane for optical networks is not standardized: DWDM
systems are proprietary and don't interoperate.

So I guess that we have to remove the concept of optical switching (lambda
switching, fiber switching, waveband switching) from GMPLS if we want to
follow your model of thinking. We also have to remove any end-to-end
protection/restoration and all non standardized SDH/SONET behaviors (even if
they don't change the standards) as you said.

Everything will become informational, except may be a very small root
specification (that will not be allowed to speak about any optical
switching).

Since the IETF will not have any standard (track) RFC, ITU-T will have to
claim that there is no existing standard and do one...

What is the benefit of moving all the interesting signaling features to
informational RFC's ? If we don't have signaling standards why should we
continue to work on GMPLS ? Why should we spend so much energy of
informational documents that have no standard value ? That will be an easy
marketing message "GMPLS: don't pay attention to it, it is only
informational, you need a standard".

Either GMPLS is dead, or we accept that GMPLS ALLOWS TO CONTROL STANDARDIZED
AND NON STANDARDIZED DATA/TRANSMISSION PLANES.

Regards,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, May 28, 2001 11:03 AM
To: John Drake
Cc: 'Yuri Landry'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; q16/15
Subject: [IP-Optical] GMPLS: waveband switching

John,

Yuri started the discussion on wavebands some days ago. Wavebands are
yet undefined in the transport plane. Looking into it a few days ago, I
tried to provide a definition of waveband and got immediately corrected
by an optical expert, resulting in an adapted definition of waveband
(see email below).

At this point in time, a waveband seems to be a group of Optical Channel
(OCh) signals. It represents a partition, not a new layer network. As
such a waveband should be represented as a "group of OCh signals" within
the OCh layer network.

Regards,

Maarten

Maarten Vissers wrote:
> 
> Manoj, Yuri,
> 
> I received a message that my definition of waveband is too restricted.
> 
> A waveband should be an optical multiplex, administered as a single
> bundle, not necessary contiguous in frequency slot.
> 
>         E.g. there may be good technical reasons to consider a
>         'waveband' created at an OADM formed by taking every 2nd
>         wavelength in a 50GHz-spaced transmission band.
> 
> In first instance the above definition may not be considered this as a
> "band"; it
> looks more like a "gapped-band" :-). Nevertheless, due to technical
> reasons we should consider a waveband as just another name for a
> particular group of wavelengths, which may best be viewed as a group of
> identified/listed wavelengths.
> 
> Regards,
> 
> Maarten
> 
> Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > In my current understanding, a waveband is a group of OCh (optical
> > channel) signals located in a contiguous set of tributary (i.e.
> > frequency) slots.
> >
> > A waveband is therefore related to partitioning, rather than a layering.
> > A waveband shouldn't have an LSP encoding type itself, but instead be
> > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > type) of "contiguous waveband" can be defined for this purpose with the
> > RNC (requested number of components) indicating the size of the
> > waveband.
> >
> > The above is simply a first shot; in general the issue can be more
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > optimized freq. slot widths, a waveband might need a start-of-waveband
> > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Mano,
> > >
> > > >            Can someone tell me the message structure of Label
Request and
> > > >Label Mapping in GMPLS ?
> > > >I am confused about the presence of LightPath Id in O-UNI messages
and LSP
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids
or Is
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS
messages
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be
mapped
> > > >to
> > > >multiple LSP Ids or vice versa ?
> > >
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID
for
> > > network connection, which may consist many LSPs. For example, the
virtual
> > > concatenation case.
> > >
> > > A LSP may tunnel through multiple pre-established connections.
> > >
> > > >Also, for waveband switching, the genralized label has the format
> > > >(wavebandId - start label - end label).
> > > >When the label request message is received on incoming interface, how
to
> > > >identify that the waveband label is requested ?
> > > >Is it the LSP encoding type or some other parameter in label request
> > > >message
> > > >? If it is the Lambda encoding type then how to identify that whether
a
> > > >lambda or waveband label is requested ?
> > > >
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the
sender
> > > >and reused in all the subsequent messages. What all subsequent
> > > >messages is it mentioning to ?
> > > >
> > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > >
> > > >I am not able to workout the message structures for GMPLS.
> > > >
> > >
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to
have
> > > the waveband label is that someone claimed that the waveband's order
might
> > > flip when going through a switch. My suggestion is don't take it
seriously.
> > >
> > > >I am not sure how these drafts are at last call. Atleast it should
mention
> > > >the message structures of various messages.
> > > >
> > >
> > > Agree.
> > >
> > > Regards,
> > >
> > > Yuri
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com

John Drake wrote:
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband
switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which
you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and
I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at
all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the
fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 7:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue
is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in
a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS
will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits.
This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current
standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Mon, 28 May 2001 04:46:50 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Mon, 28 May 2001 13:43:25 +0200

Hello Chuck,

We are working per step, this is GMPLS step one (first capability set). It
is like the IN approach of ITU-T (capability set one, then capability set
two defined on the top of the first one, etc).

End-to-end protecion/restoration is not part of this first capability set.

Rgds,

Eric

-----Original Message-----
From: C. R. Kalmanek [mailto:[email-masked]]
Sent: Friday, May 25, 2001 7:08 PM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
[email-masked]
Subject: Re: GMPLS Last Calls

I fully agree: there are a whole spectrum of options that we
need to sort through, and clear requirements are needed to
guide that process.  Our concern is with the last call.  It
doesn't make sense to progress drafts to RFC that are likely 
in hindsight to be viewed as having serious deficiencies in
meeting restoration requirements.

chuck

John Drake wrote:
> 
> The point is that in GMPLS, as in regular MPLS, restoration consists of
> rerouting from the endpoints upon
> notification of failure.  There are a whole spectrum of path and span
> protection possibilites beyond this
> that people (including us) have proposed, but in the absence of firm
> requirements, it's hard to know which
> to pursue.  I'm not sure 'shared mesh restoration' completely covers it.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 9:54 AM
> To: John Drake
> Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> John,
> 
> While there currently are no restoration requirements from the
> TE (or other) group, what Percy is saying is that shared mesh
> restoration WILL be a requirement from those groups.  Since the
> current GMPLS drafts don't meet this requirement, they are
> unlikely to meet key SP needs.
> 
> I don't understand a process that starts the requirements
> development after last call for the signaling specifications.
> 
> chuck
> 
> John Drake wrote:
> >
> > Percy,
> >
> > There has been work on protocols for path restoration in mesh networks
by
> a
> > number of
> > people.  However, at the last IETF Kireeti and Vijay clearly indicated
> that
> > this work,
> > while interesting, wouldn't be allowed to progress in advance of a
> > restoration requirements
> > draft from the TE group.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 11:55 AM
> > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> > There is a significant issue related to the absence of restoration in
the
> > signaling draft
> >
>
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > involving protection information for link protection. While link
> protection
> > schemes may be desirable for fast recovery related to high priority
LSP's,
> > more cost-effective shared mesh restoration schemes would be preferred
for
> > the majority of traffic from a Service Provider's perspective. This
> > observation is supported by the fact that many vendors are currently
> > developing proprietary schemes for shared mesh restoration. Hence, in
> > addition to the protection information, GMPLS signaling needs to reflect
a
> > minimum set of information/attributes required for shared mesh
restoration
> > without jeopardizing vendor proprietary solutions.
> >
> > The need for multiple types of restoration capabilities is well
documented
> > in the OIF/UNI I-D
> >
>
http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> > xt as follows:
> >
> > " Multiple types of facilities available for restoration are needed
> >    within the network. The following options should be considered for
> >    allocation of facilities to support restoration of failed
> >    connections:
> >    - Dedicated restoration capacity
> >    - Shared restoration capacity. This allows the network to ensure
> >      high quality service for customers, while still managing its
> >      physical resources efficiently.
> >    - Un-restorable
> >    - Pre-emptable"
> >
> > The OIF/UNI I-D supports a range of different restoration schemes
through
> > the use of service level as a connection attribute. This attribute is
> > defined as follows:
> >
> > " an integer attribute that indicates a class of service. A carrier may
> > specify a range of different classes of service (e.g. gold, silver,
> bronze)
> > with predefined characteristics (e.g. restoration plans). The
pre-defined
> > service types correspond to different types of network restoration (e.g.
> no
> > restoration, 1+1 protection), connection set-up and hold priorities,
> > reversion strategies for the connection after failures have been
repaired,
> > and retention strategies."
> >
> > It is therefore important that GMPLS be extended to be able to support
> such
> > restoration schemes.
> >
> > Percy S. Tarapore
> > AT&T Labs
> >
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry)
> > Sent: Thursday, May 24, 2001 2:20 PM
> > To: [email-masked]; [email-masked]
> > Cc: Ash, Gerald R (Jerry)
> > Subject: RE: GMPLS Last Calls
> >
> > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > draft:
> >
> > "Eve - Had hoped that CCAMP formation and expression of requirements
would
> > enable us to do more with architecture than reverse architect proposed
> > solution. Think we should also look at carrier requirements and look for
> > discrepancies with architecture.
> > Curtis - requirements of carriers not being addressed?
> > Eve - happy to discuss on mailing list in absence of time"
> >
> > There are still no documented service provider (SP) requirements driving
> the
> > proposed GMPLS protocol extensions.  This is inconsistent with the
current
> > initiatives to provide SP requirements prior to protocol extensions
being
> > accepted, such as for protection/restoration, network hierarchy, MPLS
OAM,
> > MPLS/DiffServ TE, multi-area TE, etc.
> >
> > Here is a sample of SP requirements that are not being addressed (other
> > requirements from our perspective are forthcoming):
> >
> > 1. Restoration requirements, particularly in support of mesh
restoration,
> > need to be supported by GMPLS.  For example, Section 7 of the
Generalized
> > Signaling I-D
> >
>
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt)
> > primarily discusses link protection, restoration capabilities are
largely
> > missing and need to be included.
> >
> > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > should be clearly identified in the text and referenced in the GMPLS
I-Ds,
> > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> [Reference
> > G.707] is supported by the Generalized Label Request."
> >
> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited
to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
> >
> > Jerry Ash
> > AT&T Labs
> >
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: Monday, May 14, 2001 1:52 PM
> > To: [email-masked]; [email-masked]
> > Subject: GMPLS Last Calls
> >
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> >
> > The drafts are:
> >
> >     1.  Generalized MPLS - Signaling Functional Description
> >
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> >
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> >
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> >
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> >
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> >
> >     4.  GMPLS Extensions for SONET and SDH Control
> >
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> >
> > The last call closes May 29, 12 pm GMT.
> >
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824

Delivery-date: Mon, 28 May 2001 04:39:07 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'John Drake' <[email-masked]>, 'Yuri Landry' <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked],  'Rob Coltun' <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Mon, 28 May 2001 13:36:52 +0200

Hello John,

That's a good comment. If we don't accept to have a standardized control
plane for transmission planes that could not be standardized we should
better stop working on GMPLS !

Let's remove fiber switching, let's remove wavelength switching (since all
DWDM systems are proprietary), let's remove waveband switching, let's remove
any SDH/SONET added-value, etc.

If we have to remove the SDH/SONET added-value in a separate document we
have to remove all the optical features as well, otherwise the SDH/SONET
issue doesn't make sense !

>From the operational point of view there is a huge value of having a
standardized control plane in all cases.

Kind regards,

Eric

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Friday, May 25, 2001 4:25 PM
To: 'Yuri Landry'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

Yuri,

I've attached a private note I sent to Dimitri regarding waveband switching.
It was originally put in at the suggestion of NorTel.  For both waveband
switching and fiber switching, you are dealing with a situation in which you
are using a standardized control plane to establish a multi-hop LSP with
proprietary encoding of data.  As I mentioned, this would be accomplished
using link coloring.

Personally, I have no problem removing either waveband switching or fiber
switching, but we know have to accomodate them wrt the control plane, and I
seriously doubt that there will ever be a completely non-proprietary of
encoding the data for these types of LSPs.

Note that I am using 'proprietary' in the exclusive sense.

Thanks,

John
-----Original Message-----
From: John Drake 
Sent: Wednesday, March 28, 2001 11:15 AM
To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
Subject: RE: Waveband Switching (was Re: GMPLS signaling)

Dimitri.

It's probably better to think of waveband switching as a special form of
fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
switching case, the fiber between the DWDM system and a port on the PXC
contains the entire set of lambdas, while in the waveband switching case
there is a set of fibers between the DWDM system and a set of ports on the
PXC, each of which contains a separate waveband.

In either case, the encoding of the signal on the fibers is completely
proprietary, and it's the job of routing to ensure that a correct path
through the network is obtained, such that the proprietary encoding is
maintained end-end.  This would probably be done through link coloring, so
that you only route across links that support NorTel waveband switching or
Tellabs waveband switching.

So I think the signalling stuff is fine.

Thanks,

John 

-----Original Message-----
From: Yuri Landry [mailto:[email-masked]]
Sent: Friday, May 25, 2001 7:02 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

Hello All,

So far, our discussions are focusing on the SONET/SDH draft. I'd like to 
re-direct your attention to other drafts. Rob's suggestion should apply to 
other drafts too.

One example, is the waveband switching and waveband label a standard or 
proprietary? Can author explain to me what exactly they means? How do they 
work? Any other standard reference? There are questions about it but no 
answer yet.

Regards,

Yuri.

>From: "Lazer, Monica A, NNAD" <[email-masked]>
>To: "'Rob Coltun'" <[email-masked]>, [email-masked],   
>[email-masked], q11/15 <[email-masked]>,   "t1x1.5"  
><[email-masked]>
>Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena 
>tion
>Date: Thu, 24 May 2001 18:11:36 -0400
>
>
>Rob, You proposal makes a lot of sense. Having the signaling standard
>support proprietary transport may jeopardize interoperability. The issue is
>not about GMPLS supporting non-standard rates, the issue is about putting 
>in
>formal and very specific support for a proprietary transport solution in a
>standard document for signaling without taking the transport portion to a
>standards body. Having formal signaling support for a proprietary
>concatenation may cause interoperability issues when other vendors have a
>different solution to the concatenation and while the signaling would
>indicate the concatenation, the actual transport may not work.   On the
>other hand we recognize that there may be a need for some interim support
>for proprietary solutions.
>
>
>Eric,
>Below I have some additional specific comments for the document GMPLS
>Extensions for SONET and SDH Control
>
>
>CCT field (3 bits)
>Since arbitrary contiguous concatenation is not a standard concatenation, 
>it
>falls within the vendor proprietary set of solutions.
>
>So the CCT bits may be used as follows:
>000	No contiguous concatenation requested
>001	Standard contiguous concatenation
>others	Vendor specific contiguous concatenation
>
>Alternatively, a better solution is to use only 2 bits for this field and
>use one bit to show whether contiguous concatenation is requested and the
>second bit to show whether it is standard or non-standard contiguous
>concatenation.
>
>
>NCC field (16 bits)
>This information is not sufficient.
>NCC needs better description than a zero or non-zero number.
>
>SDH and SONET Labels
>
>Text in this section (Section 3, paragraphs 5 and 6) indicates that the
>GMPLS proposal limits virtual concatenation to remain within a single
>(component) link. If I understand this correctly, it means that GMPLS will
>not allow inverse multiplexing (virtual concatenation) in the transport
>plane if it requires different component links. This is too limiting.
>
>Annex 1 (sent out by Eric Mannie on 5/22)
>Defines another type of concatenation - Flexible arbitrary contiguous
>concatenation without describing precisely how it affects the OH bits. This
>means that it will be impossible to have this type of concatenation in a
>multi vendor environment based only on the GMPLS signaling. If the 
>transport
>plane is proprietary, having the option in the signaling message will not
>fix the interoperability problem between two different vendors supporting
>their proprietary versions of arbitrary concatenation.
>
>Annex 2 (sent out by Eric Mannie on 5/22)
>Arbitrary contiguous concatenation needs definition work for
>interoperability.
>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.
>
>
>
>Monica A. Lazer
>Advanced Transport Technology and Architecture Planning
>
>908 234 8462
>[email-masked]
>
>
>-----Original Message-----
>From: Rob Coltun [mailto:[email-masked]]
>Sent: Thursday, May 24, 2001 7:24 PM
>To: [email-masked]; [email-masked]; q11/15; t1x1.5
>Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
>concatenation
>
>All,
>     despite the heated arguments I think the discussion is important to
>have.
>
>I suggest that instead of  tagging non/pre-standard items in the current
>drafts
>that they be put into a separate Informational document  - this is the
>cleanest thing to do.
>We (the IETF) do have a tradition of publishing company proprietary
>protocols
>but not as standard track documents.
>
>thanks,
>---rob
>
>
>
>_______________________________________________
>IP-Optical mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Mon, 28 May 2001 04:28:02 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Ash, Gerald R (Jerry)'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: RE: GMPLS Last Calls 
Date: Mon, 28 May 2001 13:24:29 +0200

Hello Jerry

>correct, as I mentioned, SPs have been formally asked for their
>*requirements*, but not on the GMPLS extensions

Sorry ! It is an OPEN process since the beginning, everybody can contribute
and write a draft. There is no formal process where requirements from
operators are asked for. I am not aware of any IETF rule about that !

You were welcome to work with us since 1.5 years but you never came to us.
You cannot blame us that you never worked on it (we are not responsible for
that)! This is true for the thousands of internet drafts being written at
the IETF.

It is the responsibility of each company individually to decide if they want
to contribute or not ! It is not the job of others companies to go to each
possible operator/manufacturer and to lobby to have them involved.

Regards,

Eric 

Delivery-date: Mon, 28 May 2001 04:17:03 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Rob Coltun' <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Mon, 28 May 2001 13:14:36 +0200

Hello Monica,

>Having the signaling standard
>support proprietary transport may jeopardize interoperability.

What interoperability issue are you talking about ? It is nice to repeat it
constantly but I would like to see a technical justification. About
arbitrary concatenation, what is needed for interoperability ?

I am not going to continue talking without technical arguments.

Do you think that the IETF can define a protection/restoration protocol
applicable to SDH/SONET ? Or is that proprietary as well ?

Could you give us the exact list of features in GMPLS (in all the signaling)
that have to be removed ?

Kind regards,

Eric

The issue is
not about GMPLS supporting non-standard rates, the issue is about putting in
formal and very specific support for a proprietary transport solution in a
standard document for signaling without taking the transport portion to a
standards body. Having formal signaling support for a proprietary
concatenation may cause interoperability issues when other vendors have a
different solution to the concatenation and while the signaling would
indicate the concatenation, the actual transport may not work.   On the
other hand we recognize that there may be a need for some interim support
for proprietary solutions.

Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control

CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.

NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 7:24 PM
To: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

All,
    despite the heated arguments I think the discussion is important to
have.

I suggest that instead of  tagging non/pre-standard items in the current
drafts
that they be put into a separate Informational document  - this is the
cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary
protocols
but not as standard track documents.

thanks,
---rob

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Mon, 28 May 2001 04:07:09 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Rob Coltun' <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Mon, 28 May 2001 13:05:53 +0200

Hello Rob,

> Is it really that big an issue to just keep them in a separate RFC?

Even if there is absolutely no standard required from ITU-T ? Nothing is
needed for arbitrary concatenation, AUG-X, TUG, etc. We are just describing
a way to use SDH/SONET. There was no technical discussion about that.

Do you mean that any feature that is not defined by ITU-T should not be
published in the standard track ? For instance the concept of waveband
switching ? The signal types ? The link protection ? The protection and
restoration ?

What is the added-value of GMPLS if we cannot take some freedom with the
existing standards ? Our added-value is to match the new developments of the
industry, with the added-value that was added and not only the published
standards from ITU-T.

We already agreed on the following approach:

- all mechanisms are optional (zero means I don't care).
- we indicate clearly what is not defined in ITU-T/T1X1 standards.

Can we simply use this approach ?

Kind regards,

Eric

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Saturday, May 26, 2001 1:20 AM
To: John Drake
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are
extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined
elsewhere
- whereas some of the functions aren't really new, and in cases might be
de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case)
the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Mon, 28 May 2001 03:25:48 -0700
Cc: [email-masked]
Date: Mon, 28 May 2001 12:25:08 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Rob Coltun <[email-masked]>
Original-CC: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------3DA2C9E97EFAAC4A46F1CD32
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Rob,

I would like to support your proposal. Let's review the series of GMPLS
draft documents to identify the non/pre-standard items and then move
those items into separate Informational documents.

Regards,

Maarten

Rob Coltun wrote:
> 
> All,
>     despite the heated arguments I think the discussion is important to have.
> 
> I suggest that instead of  tagging non/pre-standard items in the current drafts
> that they be put into a separate Informational document  - this is the cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary protocols
> but not as standard track documents.
> 
> thanks,
> ---rob
--------------3DA2C9E97EFAAC4A46F1CD32
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3DA2C9E97EFAAC4A46F1CD32--

Delivery-date: Mon, 28 May 2001 02:58:54 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Mon, 28 May 2001 11:57:57 +0200

Dear Jerry and Percy,

I understand you concerns very well. Of course the restoration is of
paramount importance and all GMPLS co-authors are convinced about that. We
didn't forgot it, indeed we specifically decided to not include it at this
stage.

The process is first (if possible) to define an MPLS based restoration and
then to generalize it for GMPLS. This is still this idea of re-engineering
that we are doing since the beginning.

Another point is that this is very touchy and requires a lot of additional
thinking. Also if you consider the amount of religious debate that we
already have for SDH/SONET transparency and concatenation, I let you guess
what it will be for restoration (the IETF defining protection/restoration
protocols applicable to SDH/SONET.... we will have a lot of fun on mailing
lists :-)

The GMPLS specification in WG last call today is the first version. We
didn't want to include and cover everything. Additional work is still
needed. In some cases it should first fit the MPLS concepts and then go to
GMPLS.

Kind regards,

Eric

-----Original Message-----
From: Tarapore, Percy S [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 8:55 PM
To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

There is a significant issue related to the absence of restoration in the
signaling draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt). Very specifically, Section 7 of this draft deals with the case
involving protection information for link protection. While link protection
schemes may be desirable for fast recovery related to high priority LSP's,
more cost-effective shared mesh restoration schemes would be preferred for
the majority of traffic from a Service Provider's perspective. This
observation is supported by the fact that many vendors are currently
developing proprietary schemes for shared mesh restoration. Hence, in
addition to the protection information, GMPLS signaling needs to reflect a
minimum set of information/attributes required for shared mesh restoration
without jeopardizing vendor proprietary solutions.

The need for multiple types of restoration capabilities is well documented
in the OIF/UNI I-D
http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
xt as follows:

" Multiple types of facilities available for restoration are needed
   within the network. The following options should be considered for
   allocation of facilities to support restoration of failed
   connections:
   - Dedicated restoration capacity
   - Shared restoration capacity. This allows the network to ensure
     high quality service for customers, while still managing its
     physical resources efficiently.
   - Un-restorable
   - Pre-emptable"

The OIF/UNI I-D supports a range of different restoration schemes through
the use of service level as a connection attribute. This attribute is
defined as follows:

" an integer attribute that indicates a class of service. A carrier may
specify a range of different classes of service (e.g. gold, silver, bronze)
with predefined characteristics (e.g. restoration plans). The pre-defined
service types correspond to different types of network restoration (e.g. no
restoration, 1+1 protection), connection set-up and hold priorities,
reversion strategies for the connection after failures have been repaired,
and retention strategies."

It is therefore important that GMPLS be extended to be able to support such
restoration schemes.

Percy S. Tarapore
AT&T Labs

-----Original Message-----
From: Ash, Gerald R (Jerry) 
Sent: Thursday, May 24, 2001 2:20 PM
To: [email-masked]; [email-masked]
Cc: Ash, Gerald R (Jerry)
Subject: RE: GMPLS Last Calls

Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
draft:

"Eve - Had hoped that CCAMP formation and expression of requirements would
enable us to do more with architecture than reverse architect proposed
solution. Think we should also look at carrier requirements and look for
discrepancies with architecture. 
Curtis - requirements of carriers not being addressed?
Eve - happy to discuss on mailing list in absence of time"

There are still no documented service provider (SP) requirements driving the
proposed GMPLS protocol extensions.  This is inconsistent with the current
initiatives to provide SP requirements prior to protocol extensions being
accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
MPLS/DiffServ TE, multi-area TE, etc.  

Here is a sample of SP requirements that are not being addressed (other
requirements from our perspective are forthcoming):

1. Restoration requirements, particularly in support of mesh restoration,
need to be supported by GMPLS.  For example, Section 7 of the Generalized
Signaling I-D
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt) 
primarily discusses link protection, restoration capabilities are largely
missing and need to be included.

2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
should be clearly identified in the text and referenced in the GMPLS I-Ds,
e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707 [Reference
G.707] is supported by the Generalized Label Request."

As per Eve's comment at IETF-50, SPs are encouraged to post their
requirements to the list.  It would also help if more SPs were invited to
co-author the GMPLS drafts, to help ensure that SP requirements are more
adequately reflected and addressed.

Jerry Ash
AT&T Labs

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Monday, May 14, 2001 1:52 PM
To: [email-masked]; [email-masked]
Subject: GMPLS Last Calls

This message initiates a last call on four GMPLS drafts.  The last
call is being issued jointly in the MPLS and CCAMP workgroups.

The drafts are:

    1.  Generalized MPLS - Signaling Functional Description

           <draft-ietf-mpls-generalized-signaling-04.txt>

    2.  Generalized MPLS Signaling - RSVP-TE Extensions

           <draft-ietf-mpls-generalized-rsvp-te-03.txt>

    3.  Generalized MPLS Signaling - CR-LDP Extensions

           <draft-ietf-mpls-generalized-cr-ldp-03.txt>

    4.  GMPLS Extensions for SONET and SDH Control

           <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>

The last call closes May 29, 12 pm GMT.

-  V2KG (Vijay, Vijay, Kireeti, & George)

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Mon, 28 May 2001 02:49:36 -0700
Cc: "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>
Date: Mon, 28 May 2001 11:02:39 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
Original-CC: "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>
Subject: GMPLS: waveband switching

This is a multi-part message in MIME format.
--------------271EB9C15E5B400A1D52C206
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John,

Yuri started the discussion on wavebands some days ago. Wavebands are
yet undefined in the transport plane. Looking into it a few days ago, I
tried to provide a definition of waveband and got immediately corrected
by an optical expert, resulting in an adapted definition of waveband
(see email below).

At this point in time, a waveband seems to be a group of Optical Channel
(OCh) signals. It represents a partition, not a new layer network. As
such a waveband should be represented as a "group of OCh signals" within
the OCh layer network.

Regards,

Maarten

Maarten Vissers wrote:
> 
> Manoj, Yuri,
> 
> I received a message that my definition of waveband is too restricted.
> 
> A waveband should be an optical multiplex, administered as a single
> bundle, not necessary contiguous in frequency slot.
> 
>         E.g. there may be good technical reasons to consider a
>         'waveband' created at an OADM formed by taking every 2nd
>         wavelength in a 50GHz-spaced transmission band.
> 
> In first instance the above definition may not be considered this as a
> "band"; it
> looks more like a "gapped-band" :-). Nevertheless, due to technical
> reasons we should consider a waveband as just another name for a
> particular group of wavelengths, which may best be viewed as a group of
> identified/listed wavelengths.
> 
> Regards,
> 
> Maarten
> 
> Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > In my current understanding, a waveband is a group of OCh (optical
> > channel) signals located in a contiguous set of tributary (i.e.
> > frequency) slots.
> >
> > A waveband is therefore related to partitioning, rather than a layering.
> > A waveband shouldn't have an LSP encoding type itself, but instead be
> > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > type) of "contiguous waveband" can be defined for this purpose with the
> > RNC (requested number of components) indicating the size of the
> > waveband.
> >
> > The above is simply a first shot; in general the issue can be more
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > optimized freq. slot widths, a waveband might need a start-of-waveband
> > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Mano,
> > >
> > > >            Can someone tell me the message structure of Label Request and
> > > >Label Mapping in GMPLS ?
> > > >I am confused about the presence of LightPath Id in O-UNI messages and LSP
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS messages
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped
> > > >to
> > > >multiple LSP Ids or vice versa ?
> > >
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID for
> > > network connection, which may consist many LSPs. For example, the virtual
> > > concatenation case.
> > >
> > > A LSP may tunnel through multiple pre-established connections.
> > >
> > > >Also, for waveband switching, the genralized label has the format
> > > >(wavebandId - start label - end label).
> > > >When the label request message is received on incoming interface, how to
> > > >identify that the waveband label is requested ?
> > > >Is it the LSP encoding type or some other parameter in label request
> > > >message
> > > >? If it is the Lambda encoding type then how to identify that whether a
> > > >lambda or waveband label is requested ?
> > > >
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the sender
> > > >and reused in all the subsequent messages. What all subsequent
> > > >messages is it mentioning to ?
> > > >
> > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > >
> > > >I am not able to workout the message structures for GMPLS.
> > > >
> > >
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to have
> > > the waveband label is that someone claimed that the waveband's order might
> > > flip when going through a switch. My suggestion is don't take it seriously.
> > >
> > > >I am not sure how these drafts are at last call. Atleast it should mention
> > > >the message structures of various messages.
> > > >
> > >
> > > Agree.
> > >
> > > Regards,
> > >
> > > Yuri
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com

John Drake wrote:
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 7:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits. This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------271EB9C15E5B400A1D52C206
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------271EB9C15E5B400A1D52C206--

Delivery-date: Mon, 28 May 2001 02:36:19 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, John Drake <[email-masked]>
Cc: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Heiles Juergen' <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>,  'Bala Rajagopalan' <[email-masked]>, [email-masked],  [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
Date: Mon, 28 May 2001 11:32:02 +0200

Hello Zhi,

>Yes, The signalling can be compliant to GMPLS. But what would that mean
>for compliance of the transport network? 

We already gave a number of scenarios where there are no interoperability
issue within the transmission plane (or transport network as you said) with
the proposed features.

>As I mentioned a while back, interworking is needed in two levels,
>signalling interworking AND transport interworking. 

Yes, and so what ? Why do you ignore these scenarios ? See previous comment.

>As for "multiple standards bodies", yes there are more than one
>standards bodies working on this, but they all work TOGETHER and align
>with each other, and the folks working on this are experts in the area
>who's been in the industry for MANY years. ANSI document specifies
>SONET. So does Telcordia GRs. ITU Recommendation specifies SDH. So does
>ETSI specs. 

I never went to this expert versus non expert discussion because this is
inappropriate from my point of view. Personally I consider that people
implementing the new generation of fully non-blocking SDH/SONET switches are
very good experts of SDH/SONET, whatever are the standardization bodies
where they are active at some point in the time.

Regards,

Eric

John Drake wrote:
> 
> Monica,
> 
> When you say standards compliant, which standards bodies are you
> considering?  I.e., from one of Eric's
> notes I got the impression that there were actually multiple bodies that
had
> defined SONET/SDH features.
> Further, we could indicate that implementations of GMPLS signalling are
are
> GMPLS compliant - see 'self
> defining term' in the index of Knuth vol 1.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 1:42 PM
> To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
> Greg'; 'Bala Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> 
> From an operator's perspective, it is essential to clearly flag the
features
> that are standards compliant from those, which deviate from existing
> standards, even when they are improvements to the standards. The reason
for
> this is rooted in the need to have the ability to identify all the
relevant
> issues when inter-working network elements from multiple vendors in the
same
> networks, while taking advantage of new non-standard features.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 8:57 AM
> To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala
Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: [T1X1.5] RE: Proposed text for the concatenation
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the document
> for any proprietary solution, where will we stop (I want B3 transparency
and
> I over connection setup for containers (without POH)? Do we really want to
> define the signaling support for single, two, three vendor solutions. I
> would leave this to the vendors. They implemented a proprietary transport
> plane solution so they can also define their proprietary control plane
> solution. If we have a broader interest in the feature we should look at
the
> application and consider if it should be standardized both for the
transport
> plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and
has
> been in use for years), a stand alone control plane doesn't. Interworking
at
> the control plane doesn't help much if the transport plane doesn't
> interwork. So it should be a common standardization activity both in the
> control and in the transport plane.
> - If we define something proprietary we need information about the
feature,
> we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know
what
> implications they have on the transport plane, they might exclude each
> other. That can happen as we focus only on the control plane and don't
care
> about the implications at the transport plane. We can generate a real
mess.
> - I don't want to restrict new ideas and developments. Actually you cannot
> kill a good solution that fits network needs by blocking it from a
standard.
> If someone builds it and shows its advantages operators will start to ask
> for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we
can
> come form a proprietary  feature to interworking or a standard. And don't
> start to explain how the feature could be implemented. It will bring you
> into more trouble. This is a control plane document, nothing more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in
detail,
> but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not real
> transparency what is needed, it is functional transparency. For example
for
> B2. Or for the DCC bytes you might allow byte slips. But what implications
> has this on the DCN? It is easy to define a feature for the control plane
> and don't care about the transport plane implications.
> Although you are a strong supporter of transparency, you were very fast in
> dropping the already included B2 transparency. Because it is not a
straight
> forward solution? Requires some awkward processing? And some people don't
> understand how it works? That might be also true for other features
> (flexible arbitrary concatenation). So why include one and not the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't
know
> it exactly, we just guess. Is this a good base to achieve
interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it cannot
be
> part of a AUG/STS group signal type while all other types of concatenation
> can be. If it is supported you might not need a label set. A label for the
> first time slot is enough. The network element detects which other belong
to
> the group. So from the currently available informatio!
> !
> !
> n it is difficult to tell if the control plane support is correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although with
> flexible arbitrary contiguous concatenation as both require a label set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new proposed
> section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in
G.783.
> It should be noted that AUG/TUG are not and were never intended to be
> networking entities. They were introduced as internal signal structures in
> order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
> RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the
underlying
> VC-N structure. IF you multiplex the signal you still have to do pointer
> processing for the individual VCs. As a AUG/STS group or TUG has no
overhead
> of its own, any supervision has to be performed on the individual VCs. So
> what will it buy us ?(ok, ok better not to ask the question, some one
> supports it and has its good reasons to do so as it is the case for any of
> the above features)
> 
> Regards
> 
>         Juergen
> 
> > -----Original Message-----
> > From: Mannie, Eric [SMTP:[email-masked]]
> > Sent: Tuesday, May 22, 2001 9:22 PM
> > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject:      RE: Proposed text for the concatenation
> >
> > Hello Man Wing, Bala and All,
> >
> > >I think Eric's proposed text gives a very good coverage on all cases
> >
> > Thanks :-)
> >
> > >and all we need is indicating which field is ... optional
> >
> > Indeed everything is already optional in the draft except the signal
type
> of
> > course:
> >
> >   - CCT: set to zero to say no contiguous concatenation requested
(default
> > value)
> >   - NCC: set to zero when CCT is set to zero (default value)
> >   - NVC: set to zero to say no virtual concatenation (default value).
> >   - Multiplier: set to one if one instance (default value).
> >   - transparency: set to zero to say don't care (default value).
> >
> > So there is no issue there, I will add a specific paragraph to
re-enforce
> > it.
> >
> > In addition, when a downstream node receives an "incoming request" he
can
> > decide to accept it or to refuse it depending of what is requested,
> > depending of the CAC process, depending of the customer profile,
depending
> > of the capabilities that it supports, etc.
> >
> > The draft doesn't indicate what must be implemented of course.
> >
> > >and all we need is indicating which field is standard....
> >
> > Ok, I agree. Let's indicate in the draft the features that are not
> > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > concatenation, and transparency. Is there another one ? All the signal
> types
> > have an equivalent definition in the standards.
> >
> > --- proposed new section:
> >
> > X. Relationship with SDH and SONET standards
> >
> > Some of the features described in this specification are not defined
> neither
> > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
> However,
> > these features are useful and implemented in many equipment's. All these
> > features are optional but can be controlled using this specification.>
> >
> > These features are: arbitrary contiguous concatenation, flexible
arbitrary
> > contiguous concatenation and transparency. They have been > described in
> the
> > relevant sections of this specification.
> >
> > Arbitrary contiguous concatenation does not need any additional standard
> to
> > interoperate. It simply relaxes some limitations specified in the
> > corresponding AINSI and ITU-T standards.
> >
> > Transparency does not need any standard at the UNI since it is only
> > implemented in the data plane at the NNI. This can be requested using
the
> > signaling at the UNI, independently of its implementation at the NNI.
> > Interoperability between multiple manufacturers at the NNI can be
achieved
> > in different ways: through the use of a standard, an implementation
> > agreement made by a forum, or an implementation agreement between two
> > manufacturers (e.g. at the request of an operator).
> >
> > Flexible arbitrary contiguous concatenation just need a very simple and
> > obvious agreement to interoperate between multiple manufacturers. Again
> this
> > can be achieved in different ways: through the use of a standard, an
> > implementation agreement made by a forum, or an implementation agreement
> > between two manufacturers (e.g. at the request of an operator). A simple
> > agreement could for instance simply indicate where is copied the
original
> > path overhead when "inverse multiplexing" locally a contiguously
> > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
> all
> > about this paragraph, ideas are welcome, please help !
> >
> > ---------- End of text
> >
> > Agreed ? Comments ?
> >
> > Comments from our ITU-T folks are welcome (really :-)
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 5:15 PM
> > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Proposed text for the concatenation
> >
> >
> > Very good point, Greg. If I remember correctly, the initial email
> initiated
> > such a great discussion was someone asked about whether it was worth
> > investing development effort on arbitrary concatenation. The bottom line
> is
> > if there is an appearing business case for the feature, then you will
> > support it. As some of you (vendors) already indicated that your systems
> > support AC because there are operators using and asking for this
feature.
> > There might be a lot of vendors and users supporting this or might be
just
> a
> > few, but the fact is there are someone supporting it. When defining new
> > protocols, I agree that we should consider and cover all cases, as long
as
> > any non-standard fields are optional.
> > I think Eric's proposed text gives a very good coverage on all cases and
> all
> > we need is indicating which field is non-standard and optional.
> >
> > Man Wing
> >
> >

Delivery-date: Mon, 28 May 2001 02:33:44 -0700
Date: Mon, 28 May 2001 11:31:52 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Maarten Vissers <[email-masked]>
CC: John Drake <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], q16/15 <[email-masked]>
Subject: Re: [IP-Optical] GMPLS: waveband switching

This is a multi-part message in MIME format.
--------------A540776967F15135E713D7BC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Maarten,

I think the previous e-mail from John combined with the proposal 
made last week in order to join our efforts in order to improve
the document on G.709 solve the problem. 

Today the "waveband switching" (and i agree with you it is not a 
new networking layer) has been proposed in the last version of this
document. Please take a look on what has been proposed there and
tell me if it aligned with your expectations.

Regards,
Dimitri. 

Maarten Vissers wrote:
> 
> John,
> 
> Yuri started the discussion on wavebands some days ago. Wavebands are
> yet undefined in the transport plane. Looking into it a few days ago, I
> tried to provide a definition of waveband and got immediately corrected
> by an optical expert, resulting in an adapted definition of waveband
> (see email below).
> 
> At this point in time, a waveband seems to be a group of Optical Channel
> (OCh) signals. It represents a partition, not a new layer network. As
> such a waveband should be represented as a "group of OCh signals" within
> the OCh layer network.
> 
> Regards,
> 
> Maarten
> 
> Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > I received a message that my definition of waveband is too restricted.
> >
> > A waveband should be an optical multiplex, administered as a single
> > bundle, not necessary contiguous in frequency slot.
> >
> >         E.g. there may be good technical reasons to consider a
> >         'waveband' created at an OADM formed by taking every 2nd
> >         wavelength in a 50GHz-spaced transmission band.
> >
> > In first instance the above definition may not be considered this as a
> > "band"; it
> > looks more like a "gapped-band" :-). Nevertheless, due to technical
> > reasons we should consider a waveband as just another name for a
> > particular group of wavelengths, which may best be viewed as a group of
> > identified/listed wavelengths.
> >
> > Regards,
> >
> > Maarten
> >
> > Maarten Vissers wrote:
> > >
> > > Manoj, Yuri,
> > >
> > > In my current understanding, a waveband is a group of OCh (optical
> > > channel) signals located in a contiguous set of tributary (i.e.
> > > frequency) slots.
> > >
> > > A waveband is therefore related to partitioning, rather than a layering.
> > > A waveband shouldn't have an LSP encoding type itself, but instead be
> > > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > > type) of "contiguous waveband" can be defined for this purpose with the
> > > RNC (requested number of components) indicating the size of the
> > > waveband.
> > >
> > > The above is simply a first shot; in general the issue can be more
> > > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > > optimized freq. slot widths, a waveband might need a start-of-waveband
> > > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Yuri Landry wrote:
> > > >
> > > > Mano,
> > > >
> > > > >            Can someone tell me the message structure of Label Request and
> > > > >Label Mapping in GMPLS ?
> > > > >I am confused about the presence of LightPath Id in O-UNI messages and LSP
> > > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
> > > > >it like that both lightPath Id and LSP Id will be carried in GMPLS messages
> > > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped
> > > > >to
> > > > >multiple LSP Ids or vice versa ?
> > > >
> > > > I think you mean Connection ID and LSP ID. A connection ID is an ID for
> > > > network connection, which may consist many LSPs. For example, the virtual
> > > > concatenation case.
> > > >
> > > > A LSP may tunnel through multiple pre-established connections.
> > > >
> > > > >Also, for waveband switching, the genralized label has the format
> > > > >(wavebandId - start label - end label).
> > > > >When the label request message is received on incoming interface, how to
> > > > >identify that the waveband label is requested ?
> > > > >Is it the LSP encoding type or some other parameter in label request
> > > > >message
> > > > >? If it is the Lambda encoding type then how to identify that whether a
> > > > >lambda or waveband label is requested ?
> > > > >
> > > > >Also, it is mentioned that wavebandId (32 bits) is selected by the sender
> > > > >and reused in all the subsequent messages. What all subsequent
> > > > >messages is it mentioning to ?
> > > > >
> > > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > > >
> > > > >I am not able to workout the message structures for GMPLS.
> > > > >
> > > >
> > > > To me waveband label defined in GMPLS drafts is a joke. The reason to have
> > > > the waveband label is that someone claimed that the waveband's order might
> > > > flip when going through a switch. My suggestion is don't take it seriously.
> > > >
> > > > >I am not sure how these drafts are at last call. Atleast it should mention
> > > > >the message structures of various messages.
> > > > >
> > > >
> > > > Agree.
> > > >
> > > > Regards,
> > > >
> > > > Yuri
> > > > _________________________________________________________________
> > > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> John Drake wrote:
> >
> > Yuri,
> >
> > I've attached a private note I sent to Dimitri regarding waveband switching.
> > It was originally put in at the suggestion of NorTel.  For both waveband
> > switching and fiber switching, you are dealing with a situation in which you
> > are using a standardized control plane to establish a multi-hop LSP with
> > proprietary encoding of data.  As I mentioned, this would be accomplished
> > using link coloring.
> >
> > Personally, I have no problem removing either waveband switching or fiber
> > switching, but we know have to accomodate them wrt the control plane, and I
> > seriously doubt that there will ever be a completely non-proprietary of
> > encoding the data for these types of LSPs.
> >
> > Note that I am using 'proprietary' in the exclusive sense.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: John Drake
> > Sent: Wednesday, March 28, 2001 11:15 AM
> > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> > Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> >
> > Dimitri.
> >
> > It's probably better to think of waveband switching as a special form of
> > fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> > Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> > switching case, the fiber between the DWDM system and a port on the PXC
> > contains the entire set of lambdas, while in the waveband switching case
> > there is a set of fibers between the DWDM system and a set of ports on the
> > PXC, each of which contains a separate waveband.
> >
> > In either case, the encoding of the signal on the fibers is completely
> > proprietary, and it's the job of routing to ensure that a correct path
> > through the network is obtained, such that the proprietary encoding is
> > maintained end-end.  This would probably be done through link coloring, so
> > that you only route across links that support NorTel waveband switching or
> > Tellabs waveband switching.
> >
> > So I think the signalling stuff is fine.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Yuri Landry [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 7:02 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena tion
> >
> > Hello All,
> >
> > So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> > re-direct your attention to other drafts. Rob's suggestion should apply to
> > other drafts too.
> >
> > One example, is the waveband switching and waveband label a standard or
> > proprietary? Can author explain to me what exactly they means? How do they
> > work? Any other standard reference? There are questions about it but no
> > answer yet.
> >
> > Regards,
> >
> > Yuri.
> >
> > >From: "Lazer, Monica A, NNAD" <[email-masked]>
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> > ><[email-masked]>
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> > >tion
> > >Date: Thu, 24 May 2001 18:11:36 -0400
> > >
> > >
> > >Rob, You proposal makes a lot of sense. Having the signaling standard
> > >support proprietary transport may jeopardize interoperability. The issue is
> > >not about GMPLS supporting non-standard rates, the issue is about putting
> > >in
> > >formal and very specific support for a proprietary transport solution in a
> > >standard document for signaling without taking the transport portion to a
> > >standards body. Having formal signaling support for a proprietary
> > >concatenation may cause interoperability issues when other vendors have a
> > >different solution to the concatenation and while the signaling would
> > >indicate the concatenation, the actual transport may not work.   On the
> > >other hand we recognize that there may be a need for some interim support
> > >for proprietary solutions.
> > >
> > >
> > >Eric,
> > >Below I have some additional specific comments for the document GMPLS
> > >Extensions for SONET and SDH Control
> > >
> > >
> > >CCT field (3 bits)
> > >Since arbitrary contiguous concatenation is not a standard concatenation,
> > >it
> > >falls within the vendor proprietary set of solutions.
> > >
> > >So the CCT bits may be used as follows:
> > >000    No contiguous concatenation requested
> > >001    Standard contiguous concatenation
> > >others Vendor specific contiguous concatenation
> > >
> > >Alternatively, a better solution is to use only 2 bits for this field and
> > >use one bit to show whether contiguous concatenation is requested and the
> > >second bit to show whether it is standard or non-standard contiguous
> > >concatenation.
> > >
> > >
> > >NCC field (16 bits)
> > >This information is not sufficient.
> > >NCC needs better description than a zero or non-zero number.
> > >
> > >SDH and SONET Labels
> > >
> > >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> > >GMPLS proposal limits virtual concatenation to remain within a single
> > >(component) link. If I understand this correctly, it means that GMPLS will
> > >not allow inverse multiplexing (virtual concatenation) in the transport
> > >plane if it requires different component links. This is too limiting.
> > >
> > >Annex 1 (sent out by Eric Mannie on 5/22)
> > >Defines another type of concatenation - Flexible arbitrary contiguous
> > >concatenation without describing precisely how it affects the OH bits. This
> > >means that it will be impossible to have this type of concatenation in a
> > >multi vendor environment based only on the GMPLS signaling. If the
> > >transport
> > >plane is proprietary, having the option in the signaling message will not
> > >fix the interoperability problem between two different vendors supporting
> > >their proprietary versions of arbitrary concatenation.
> > >
> > >Annex 2 (sent out by Eric Mannie on 5/22)
> > >Arbitrary contiguous concatenation needs definition work for
> > >interoperability.
> > >Flexible arbitrary contiguous concatenation may be available today to
> > >support contiguous signals, but it is not defined in the current standards.
> > >Clear agreements on OH usage are needed between supporting vendors.
> > >Maintenance and tracking of the signal needs to be well understood.
> > >
> > >
> > >
> > >Monica A. Lazer
> > >Advanced Transport Technology and Architecture Planning
> > >
> > >908 234 8462
> > >[email-masked]
> > >
> > >
> > >-----Original Message-----
> > >From: Rob Coltun [mailto:[email-masked]]
> > >Sent: Thursday, May 24, 2001 7:24 PM
> > >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > >concatenation
> > >
> > >All,
> > >     despite the heated arguments I think the discussion is important to
> > >have.
> > >
> > >I suggest that instead of  tagging non/pre-standard items in the current
> > >drafts
> > >that they be put into a separate Informational document  - this is the
> > >cleanest thing to do.
> > >We (the IETF) do have a tradition of publishing company proprietary
> > >protocols
> > >but not as standard track documents.
> > >
> > >thanks,
> > >---rob
> > >
> > >
> > >
> > >_______________________________________________
> > >IP-Optical mailing list
> > >[email-masked]
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------A540776967F15135E713D7BC
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------A540776967F15135E713D7BC--

Delivery-date: Mon, 28 May 2001 02:26:09 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Mon, 28 May 2001 11:22:22 +0200

Hello Zhi,

Let's be adult as you said many times, we are speaking about TWO features
(not hundreds as you like to present it):

- transparency.
- concatenation.

You are afraid that implementation will not interoperate ? You should better
speak first about the two signaling protocols that we have in GMPLS. GMPLS
has options, like all control planes and nobody has to implement everything.
This is signaling not a transmission format.

>So, what is the metric for deciding? I'm sure there are many vendors who
>are reading this waiting to add their "unique" features to the document
>as well...

We said *many* times that we didn't want to include all features from all
manufacturers but just as small set of basic features that seems to be
interesting for the industry. The proof is that you don't have in the draft
these hundreds of famous features that are you are afraid by. What else
should I repeat ?

Let's be democratic as you said, my notion of democracy is not to remove
these two features from the draft because your don't implement them.

I understood from the many e-mails send by your company since three weeks
that you don't want to see any transparency and any new form of
concatenation in the draft. However this draft is not your product
description. It is not a product description, it is a signaling
specification with options.

You are trying to present this work as if it was made and decided by a small
set of people, that's not right and not fair. The fact is that you didn't
pay attention to it and came very late into the process trying to impose
your own ideas to the group. We had exactly the same kind of discussion
since more than two months with your colleagues one by one, I guess this is
part of your strategy.

We proposed, as requested by your colleagues, to make a distinction between
what is defined in SDH/SONET and what is not. I agreed that's a good idea to
clarify the draft. In addition, these two mechanisms are 100% optional. Now
of course you want more, you want to remove everything (that's what you call
democracy). Obviously, you don't want to reach a consensus, does it worth to
continue these discussions ?

Regards,

Eric

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 5:38 AM
To: Mannie, Eric
Cc: 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

I think your questions cannot be answered either way. Whether features
are needed for one or two vendors is up to each vendor to decide what
they want. 

As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people...

As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision. 

Let's be technical, let the experts in the right group decide, and we
should not jump the gun. Let's be adults and let's help make the telecom
industry and the standards process a respectable place...

"Mannie, Eric" wrote:

> I don't work for a vendor :-) Who told you that some features are needed
> only for one or two vendors ? How do you quantify the number of vendors
that
> are needed to have a standard ? We work on a consensus based and this
draft
> has 17 companies on it with 30 people. Usually it is much much less at the
> IETF, you only have a small number of co-authors. I already gave a summary
> of the process that we followed, all the meetings that we hold, all the
> conference call that we hold, all the e-mails that we exchanged, etc.
> 
> You described one model in your e-mail, that's a valid model but this is
not
> THE (only) model. There are plenty of other models that can be fulfilled
> with GMPLS.
> 
> Kind regards,
> 
> Eric
>

Delivery-date: Mon, 28 May 2001 02:05:27 -0700
Date: Mon, 28 May 2001 11:01:49 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Maarten Vissers <[email-masked]>
CC: Yuri Landry <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Protection switching in GMPLS ==> supporting G.841?

This is a multi-part message in MIME format.
--------------3B945B630F8E1A4539F6D1C9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Maarten,

To which part of the document do yo refer here ? I suppose it
is the section 7 of the GMPLS Signalling. G.841 is dedicated 
to "TYPES AND CHARACTERISTICS OF SDH NETWORK PROTECTION 
ARCHITECTURES" so it is a technology dependent document.

The main difference comes from the "objective" of these 
protection: in section 7 you describe the type of link 
selected in order to provide LSP link protection. G.841
covers as indicated in the scope of the document:

"Protection schemes are classified as:
- SDH trail protection (at the section or path layer);
- SDH subnetwork connection protection (with inherent monitoring, 
  non-intrusive monitoring, and sub-layer monitoring)."

So this this document described the protection schemes while
the scope of the GMPLS-SIG is only to determine the signalling
extensions in order to provision link-protected LSP. If you 
have some doubts we could probably review this section together.
What do you think about ?

- Dimitri.

Maarten Vissers wrote:
> 
> All,
> 
> Triggered by Yuri's email, I would like to offer another area for closer
> look: protection switching. The standardised SDH protection switching
> schemes are specified in G.841 with further support in G.783.
> 
> When reading the protection switching text some time ago in the GMPLs
> draft I noticed several extensions to be described beyond those in
> G.841.
> 
> My request is to review the latest text against G.841/G.783, identify
> the extensions and (as now proposed by several of us) move those
> extensions into a separate Informational document.
> 
> Regards,
> 
> Maarten
> 
> Yuri Landry wrote:
> >
> > Hello All,
> >
> > So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> > re-direct your attention to other drafts. Rob's suggestion should apply to
> > other drafts too.
> >
> > One example, is the waveband switching and waveband label a standard or
> > proprietary? Can author explain to me what exactly they means? How do they
> > work? Any other standard reference? There are questions about it but no
> > answer yet.
> >
> > Regards,
> >
> > Yuri.
> >
> > >From: "Lazer, Monica A, NNAD" <[email-masked]>
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> > ><[email-masked]>
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> > >tion
> > >Date: Thu, 24 May 2001 18:11:36 -0400
> > >
> > >
> > >Rob, You proposal makes a lot of sense. Having the signaling standard
> > >support proprietary transport may jeopardize interoperability. The issue is
> > >not about GMPLS supporting non-standard rates, the issue is about putting
> > >in
> > >formal and very specific support for a proprietary transport solution in a
> > >standard document for signaling without taking the transport portion to a
> > >standards body. Having formal signaling support for a proprietary
> > >concatenation may cause interoperability issues when other vendors have a
> > >different solution to the concatenation and while the signaling would
> > >indicate the concatenation, the actual transport may not work.   On the
> > >other hand we recognize that there may be a need for some interim support
> > >for proprietary solutions.
> > >
> > >
> > >Eric,
> > >Below I have some additional specific comments for the document GMPLS
> > >Extensions for SONET and SDH Control
> > >
> > >
> > >CCT field (3 bits)
> > >Since arbitrary contiguous concatenation is not a standard concatenation,
> > >it
> > >falls within the vendor proprietary set of solutions.
> > >
> > >So the CCT bits may be used as follows:
> > >000    No contiguous concatenation requested
> > >001    Standard contiguous concatenation
> > >others Vendor specific contiguous concatenation
> > >
> > >Alternatively, a better solution is to use only 2 bits for this field and
> > >use one bit to show whether contiguous concatenation is requested and the
> > >second bit to show whether it is standard or non-standard contiguous
> > >concatenation.
> > >
> > >
> > >NCC field (16 bits)
> > >This information is not sufficient.
> > >NCC needs better description than a zero or non-zero number.
> > >
> > >SDH and SONET Labels
> > >
> > >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> > >GMPLS proposal limits virtual concatenation to remain within a single
> > >(component) link. If I understand this correctly, it means that GMPLS will
> > >not allow inverse multiplexing (virtual concatenation) in the transport
> > >plane if it requires different component links. This is too limiting.
> > >
> > >Annex 1 (sent out by Eric Mannie on 5/22)
> > >Defines another type of concatenation - Flexible arbitrary contiguous
> > >concatenation without describing precisely how it affects the OH bits. This
> > >means that it will be impossible to have this type of concatenation in a
> > >multi vendor environment based only on the GMPLS signaling. If the
> > >transport
> > >plane is proprietary, having the option in the signaling message will not
> > >fix the interoperability problem between two different vendors supporting
> > >their proprietary versions of arbitrary concatenation.
> > >
> > >Annex 2 (sent out by Eric Mannie on 5/22)
> > >Arbitrary contiguous concatenation needs definition work for
> > >interoperability.
> > >Flexible arbitrary contiguous concatenation may be available today to
> > >support contiguous signals, but it is not defined in the current standards.
> > >Clear agreements on OH usage are needed between supporting vendors.
> > >Maintenance and tracking of the signal needs to be well understood.
> > >
> > >
> > >
> > >Monica A. Lazer
> > >Advanced Transport Technology and Architecture Planning
> > >
> > >908 234 8462
> > >[email-masked]
> > >
> > >
> > >-----Original Message-----
> > >From: Rob Coltun [mailto:[email-masked]]
> > >Sent: Thursday, May 24, 2001 7:24 PM
> > >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > >concatenation
> > >
> > >All,
> > >     despite the heated arguments I think the discussion is important to
> > >have.
> > >
> > >I suggest that instead of  tagging non/pre-standard items in the current
> > >drafts
> > >that they be put into a separate Informational document  - this is the
> > >cleanest thing to do.
> > >We (the IETF) do have a tradition of publishing company proprietary
> > >protocols
> > >but not as standard track documents.
> > >
> > >thanks,
> > >---rob
> > >
> > >
> > >
> > >_______________________________________________
> > >IP-Optical mailing list
> > >[email-masked]
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------3B945B630F8E1A4539F6D1C9
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------3B945B630F8E1A4539F6D1C9--

Delivery-date: Mon, 28 May 2001 01:47:37 -0700
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 28 May 2001 10:44:35 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Yuri Landry <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Protection switching in GMPLS ==> supporting G.841?

This is a multi-part message in MIME format.
--------------DA2741F034544E2BEF862527
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Triggered by Yuri's email, I would like to offer another area for closer
look: protection switching. The standardised SDH protection switching
schemes are specified in G.841 with further support in G.783.

When reading the protection switching text some time ago in the GMPLs
draft I noticed several extensions to be described beyond those in
G.841.

My request is to review the latest text against G.841/G.783, identify
the extensions and (as now proposed by several of us) move those
extensions into a separate Informational document.

Regards,

Maarten

Yuri Landry wrote:
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits. This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------DA2741F034544E2BEF862527
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DA2741F034544E2BEF862527--

Delivery-date: Mon, 28 May 2001 01:37:44 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Randolph, Marc'" <[email-masked]>, 'Guo-Qiang Wang' <[email-masked]>
Cc: [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Mon, 28 May 2001 10:34:04 +0200

Hello Marc,

I think that you are speaking about two different things, you want to
compare apples and oranges. You are using ITU-T standards as counter
examples.  It is better to compare signaling protocols between them. For
instance, you should compare GMPLS (with all its options) and an ITU-T
standard like H.323 (with all its options). You need a profile for H.323 as
you need a profile for GMPLS. There are *lots* of features in H.323 that you
are not obliged to implement. It is even worst there are sometimes two ways
of doing the same thing. I made three world-wide interop event (as
developer) of H.323 and trust we it was not easy to achieve a basic
interoperability (just to open a connection, talk and close it). If you
consider supplementary services it becomes a nightmare. H.323 was also done
re-using existing signaling.

Hopefully, GMPLS has much less options and is much less complex than H.323.

If you tried to do any MPLS based implementation you should know that there
are plenty of options. One of the biggest is the signaling protocol that you
want to use: RSVP-TE or CR-LDP. Before going to signaling details you must
consider the biggest issues.

>A solution to this problem may be to have an extension to the standard.
The
>base standard includes the non-optional stuff that everyone expects to
>implement.  If there are extra features that more than one or two vendors
>are going to implement, make that a new standard that is based on the
>baseline.

I don't thing this is applicable to MPLS and GMPLS. The basic idea is to be
as generic (and general) as possible. You cannot be generic and restrictive
at the same time, these are opposite objectives.

Kind regards,

Eric

-----Original Message-----
From: Randolph, Marc [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 11:29 PM
To: Mannie, Eric; 'Guo-Qiang Wang'
Cc: [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

> -----Original Message-----
> From: Mannie, Eric [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 1:17 PM
> To: 'Guo-Qiang Wang'
> Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
> Subject: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatenation
> 
> 
[...]
>
> - the fact that a feature is in the signaling does not mean 
> that it must be implemented.
> - you can claim to be compliant with the draft without 
> implementing some features.

Hello Eric,

I respectively disagree with these statements.

I don't presume to know all customers, but if I were a customer, I'd
strongly dislike having four vendors approach me saying they were compliant
with standard X when in fact, each one has left out a few (but different)
features that they somehow decided weren't important.

Then the customer is reduced to asking each vendor "Did you implement
feature Y and Z?  What about A and B?"

If the features are truely that minor that they can be excluded, do they
really belong in the main spec?

I actually think of it another way... what if there were a standard for what
personal information manager features were included in a new cell phone
(because that is what I've been personally investigating lately).  But when
I go to buy a phone, I discovered they left out the calendar/scheduler and
they only have contact info, because that is what they viewed as the
important part of the standard.  I submit they don't comply with the
standard.

A solution to this problem may be to have an extension to the standard.  The
base standard includes the non-optional stuff that everyone expects to
implement.  If there are extra features that more than one or two vendors
are going to implement, make that a new standard that is based on the
baseline.

For example, take the original G.723.  It describes (well, used to, before
they moved on) an ADPCM coder for 32 and 64 kbps.  The later G.726 was
introduced to add a 16 kbps coder.  Vendors not interested in G.726 would
still call themselves G.723 compliant.  No confusion for the customer.

Best regards,

   Marc

Delivery-date: Mon, 28 May 2001 01:14:29 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Kullberg, Alan'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Mon, 28 May 2001 10:12:57 +0200

Hello Alan,

>The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
>defined for TDM Switch Capable.  In order to support the hierarchy in the
>above paragraph, TDM Switch Capable would need to be split into multiple
>values, one for each level of the SDH/SONET multiplexing structure.

The text that you indicated don't restrict to only two levels, you could
open an LSP inside an LSP, inside an LSP, etc... The example was given with
two levels. The important point is that whatever is the LSP that you want to
open you have a higher part and a lower part. So we don't have to define
plenty of different labels, not only per layer (higher order versus lower
order) but also as a whole since we could want to directly indicate a VC-11
in the whole multiplex (in that case the full label is significant). Having
different labels makes it much more complex without adding any additional
functionality.

Kind regards,

Eric

-----Original Message-----
From: Kullberg, Alan [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 5:44 PM
To: Mannie, Eric; 'Kireeti Kompella'
Cc: [email-masked]'; [email-masked]'
Subject: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

The following paragraph is from section 3 of
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt.

  When hierarchical SDH/SONET LSPs are used, an LSP with a given
   bandwidth can be used to tunnel lower order LSPs.  The higher
   order SDH/SONET LSP behaves as a virtual link with a given
   bandwidth (e.g. VC-3), it may also be used as a Forwarding
   Adjacency. A lower order SDH/SONET LSP can be established through
   that higher order LSP. Since a label is local to a (virtual) link,
   the highest part of that label is non-significant and is set to
   zero.

The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
defined for TDM Switch Capable.  In order to support the hierarchy in the
above paragraph, TDM Switch Capable would need to be split into multiple
values, one for each level of the SDH/SONET multiplexing structure.

What do you think?

Alan

Delivery-date: Mon, 28 May 2001 00:49:18 -0700
Cc: "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Mon, 28 May 2001 09:47:52 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Heiles Juergen <[email-masked]>
Original-CC: "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------D57B62F7C5481B58580B647B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Let's treat all GMPLS specifications associated with non-standard
transport plane features as proprietary features, and either 
A) remove those from GMPLS, 
B) move those into an informal appendix of GMPLS or 
C) move those into a separate informal GMPLS extension document
addressing GMPLS constructs for non-standard (proprietary) transport
plane features.

In my opinion after all this debate, alternatives A or C seems best.

Regards,

Maarten

> 
> -------- Original Message --------
> Subject: RE: Proposed text for the concatenation
> Date: Wed, 23 May 2001 14:57:22 +0200
> From: Heiles Juergen <[email-masked]>
> To: "'Mannie, Eric'" <[email-masked]>,"'Fong, Man
> Wing'"<[email-masked]>,"'Bernstein, Greg'"
> <[email-masked]>,"'Bala Rajagopalan'" <[email-masked]>
> CC: [email-masked],
> [email-masked],"t1x1.5"<[email-masked]>, q11/15
> <[email-masked]>
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the
> document for any proprietary solution, where will we stop (I want B3
> transparency and I over connection setup for containers (without POH)?
> Do we really want to define the signaling support for single, two, three
> vendor solutions. I would leave this to the vendors. They implemented a
> proprietary transport plane solution so they can also define their
> proprietary control plane solution. If we have a broader interest in the
> feature we should look at the application and consider if it should be
> standardized both for the transport plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and
> has been in use for years), a stand alone control plane doesn't.
> Interworking at the control plane doesn't help much if the transport
> plane doesn't interwork. So it should be a common standardization
> activity both in the control and in the transport plane.
> - If we define something proprietary we need information about the
> feature, we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know
> what implications they have on the transport plane, they might exclude
> each other. That can happen as we focus only on the control plane and
> don't care about the implications at the transport plane. We can
> generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you
> cannot kill a good solution that fits network needs by blocking it from
> a standard. If someone builds it and shows its advantages operators will
> start to ask for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we
> can come form a proprietary  feature to interworking or a standard. And
> don't start to explain how the feature could be implemented. It will
> bring you into more trouble. This is a control plane document, nothing
> more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in
> detail, but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the
> two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not
> real transparency what is needed, it is functional transparency. For
> example for B2. Or for the DCC bytes you might allow byte slips. But
> what implications has this on the DCN? It is easy to define a feature
> for the control plane and don't care about the transport plane
> implications.
> Although you are a strong supporter of transparency, you were very fast
> in dropping the already included B2 transparency. Because it is not a
> straight forward solution? Requires some awkward processing? And some
> people don't understand how it works? That might be also true for other
> features (flexible arbitrary concatenation). So why include one and not
> the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't
> know it exactly, we just guess. Is this a good base to achieve
> interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it
> cannot be part of a AUG/STS group signal type while all other types of
> concatenation can be. If it is supported you might not need a label set.
> A label for the first time slot is enough. The network element detects
> which other belong to the group. So from the currently available
> information it is difficult to tell if the control plane support is correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although
> with flexible arbitrary contiguous concatenation as both require a label
> set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new
> proposed section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in
> G.783. It should be noted that AUG/TUG are not and were never intended
> to be networking entities. They were introduced as internal signal
> structures in order to better describe the SDH multiplex process.
> VC-11/12/2/3/4, MS and RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the
> underlying VC-N structure. IF you multiplex the signal you still have to
> do pointer processing for the individual VCs. As a AUG/STS group or TUG
> has no overhead of its own, any supervision has to be performed on the
> individual VCs. So what will it buy us ?(ok, ok better not to ask the
> question, some one supports it and has its good reasons to do so as it
> is the case for any of the above features)
> 
> Regards
> 
>         Juergen
--------------D57B62F7C5481B58580B647B
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D57B62F7C5481B58580B647B--

Delivery-date: Sun, 27 May 2001 11:10:58 -0700
Date: Sun, 27 May 2001 11:07:35 -0700
From: Ping Pan <[email-masked]>
Organization: Juniper Networks
To: Bala Rajagopalan <[email-masked]>
CC: "'C. R. Kalmanek'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

Bala Rajagopalan wrote:
> 
> Hi,
> 
> There are two aspects to this problem:
> 
> Pre-establishment of protection paths: This
> is something requiring signaling support during
> provisioning. Don't see any problem in supporting
> this under the current GMPLS framework.
> 
> Real-time restoration signaling: Our
> view is that a dedicated lightweight protocol
> is appropriate. (of course, there are other
> views on this :-). )
> 

Hi,

Many backbone links are SONET, which can redirect traffic to a backup
channel within 50 msec. This is the requirement that we are dealing here
in MPLS. So in backbone, we have to rely on pre-established LSP' for
restoration. I doubt there is any simple method for network nodes to
detect link failure, setup a new session and adjust all sort of stuff on
*real-time*.  I could be wrong. Does anybody have the measurement timing
data on ATM crankback?

IMHO, the only reason for using real-time restoration signaling is to
satisfy end-user applications, where based on the network feedback, the
user application can apply various adaptive mechanisms to renew
sessions. I don't think this is the within the framework of MPLS.

2 cents,

- Ping

> I don't see an obvious show-stopper here w.r.t
> progressing the current drafts for last call.
> 
> Regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked]
>

Delivery-date: Sun, 27 May 2001 10:45:06 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'C. R. Kalmanek'" <[email-masked]>, Bala Rajagopalan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Sun, 27 May 2001 13:40:21 -0400

Hi,

There are two aspects to this problem:

Pre-establishment of protection paths: This 
is something requiring signaling support during
provisioning. Don't see any problem in supporting
this under the current GMPLS framework.

Real-time restoration signaling: Our
view is that a dedicated lightweight protocol
is appropriate. (of course, there are other
views on this :-). ) 

I don't see an obvious show-stopper here w.r.t
progressing the current drafts for last call.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 8:18 PM
> To: Bala Rajagopalan
> Cc: [email-masked]; [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> 
> Bala,
> 
> Just getting back to email this evening...  
> 
> New objects will certainly be needed.  As for whether restoration
> can be handled purely as extensions to the current drafts remains 
> to be seen -- it would be nice.
> 
> chuck
> 
> Bala Rajagopalan wrote:
> > 
> > Chuck:
> > 
> > I believe that the restoration issue can be
> > dealt with indepedent of the current drafts
> > on last call. Do you see any obstacles to
> > adding new objects/semantics (if any) to support
> > restoration requirements as they arise?
> > 
> > BTW, there are some drafts floating around
> > on shared mesh.
> > 
> > regards,
> > 
> > Bala Rajagopalan
> > Tellium, Inc.
> > 2 Crescent Place
> > P.O. Box 901
> > Oceanport, NJ 07757-0901
> > Tel: (732) 923-4237
> > Fax: (732) 923-9804
> > Email: [email-masked]
> > 
> > > -----Original Message-----
> > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 1:08 PM
> > > To: John Drake
> > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); 
> [email-masked];
> > > [email-masked]
> > > Subject: Re: GMPLS Last Calls
> > >
> > >
> > > I fully agree: there are a whole spectrum of options that we
> > > need to sort through, and clear requirements are needed to
> > > guide that process.  Our concern is with the last call.  It
> > > doesn't make sense to progress drafts to RFC that are likely
> > > in hindsight to be viewed as having serious deficiencies in
> > > meeting restoration requirements.
> > >
> > > chuck
> > >
> > > John Drake wrote:
> > > >
> > > > The point is that in GMPLS, as in regular MPLS, restoration
> > > consists of
> > > > rerouting from the endpoints upon
> > > > notification of failure.  There are a whole spectrum of
> > > path and span
> > > > protection possibilites beyond this
> > > > that people (including us) have proposed, but in the 
> absence of firm
> > > > requirements, it's hard to know which
> > > > to pursue.  I'm not sure 'shared mesh restoration'
> > > completely covers it.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > > Sent: Friday, May 25, 2001 9:54 AM
> > > > To: John Drake
> > > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); 
> [email-masked];
> > > > [email-masked]
> > > > Subject: Re: GMPLS Last Calls
> > > >
> > > > John,
> > > >
> > > > While there currently are no restoration requirements from the
> > > > TE (or other) group, what Percy is saying is that shared mesh
> > > > restoration WILL be a requirement from those groups.  Since the
> > > > current GMPLS drafts don't meet this requirement, they are
> > > > unlikely to meet key SP needs.
> > > >
> > > > I don't understand a process that starts the requirements
> > > > development after last call for the signaling specifications.
> > > >
> > > > chuck
> > > >
> > > > John Drake wrote:
> > > > >
> > > > > Percy,
> > > > >
> > > > > There has been work on protocols for path restoration in
> > > mesh networks by
> > > > a
> > > > > number of
> > > > > people.  However, at the last IETF Kireeti and Vijay
> > > clearly indicated
> > > > that
> > > > > this work,
> > > > > while interesting, wouldn't be allowed to progress in 
> advance of a
> > > > > restoration requirements
> > > > > draft from the TE group.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > John
> > > > >
> > > > > -----Original Message-----
> > > > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > > > Sent: Thursday, May 24, 2001 11:55 AM
> > > > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > > > Subject: RE: GMPLS Last Calls
> > > > >
> > > > > There is a significant issue related to the absence of
> > > restoration in the
> > > > > signaling draft
> > > > >
> > > >
> > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > > ed-signaling-0
> > > > > 4.txt). Very specifically, Section 7 of this draft deals
> > > with the case
> > > > > involving protection information for link protection. 
> While link
> > > > protection
> > > > > schemes may be desirable for fast recovery related to
> > > high priority LSP's,
> > > > > more cost-effective shared mesh restoration schemes would
> > > be preferred for
> > > > > the majority of traffic from a Service Provider's
> > > perspective. This
> > > > > observation is supported by the fact that many vendors
> > > are currently
> > > > > developing proprietary schemes for shared mesh
> > > restoration. Hence, in
> > > > > addition to the protection information, GMPLS signaling
> > > needs to reflect a
> > > > > minimum set of information/attributes required for shared
> > > mesh restoration
> > > > > without jeopardizing vendor proprietary solutions.
> > > > >
> > > > > The need for multiple types of restoration capabilities
> > > is well documented
> > > > > in the OIF/UNI I-D
> > > > >
> > > >
> > > http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> > > ework-uni-00.t
> > > > > xt as follows:
> > > > >
> > > > > " Multiple types of facilities available for restoration
> > > are needed
> > > > >    within the network. The following options should be
> > > considered for
> > > > >    allocation of facilities to support restoration of failed
> > > > >    connections:
> > > > >    - Dedicated restoration capacity
> > > > >    - Shared restoration capacity. This allows the network
> > > to ensure
> > > > >      high quality service for customers, while still 
> managing its
> > > > >      physical resources efficiently.
> > > > >    - Un-restorable
> > > > >    - Pre-emptable"
> > > > >
> > > > > The OIF/UNI I-D supports a range of different restoration
> > > schemes through
> > > > > the use of service level as a connection attribute. This
> > > attribute is
> > > > > defined as follows:
> > > > >
> > > > > " an integer attribute that indicates a class of service.
> > > A carrier may
> > > > > specify a range of different classes of service (e.g.
> > > gold, silver,
> > > > bronze)
> > > > > with predefined characteristics (e.g. restoration plans).
> > > The pre-defined
> > > > > service types correspond to different types of network
> > > restoration (e.g.
> > > > no
> > > > > restoration, 1+1 protection), connection set-up and hold
> > > priorities,
> > > > > reversion strategies for the connection after failures
> > > have been repaired,
> > > > > and retention strategies."
> > > > >
> > > > > It is therefore important that GMPLS be extended to be
> > > able to support
> > > > such
> > > > > restoration schemes.
> > > > >
> > > > > Percy S. Tarapore
> > > > > AT&T Labs
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ash, Gerald R (Jerry)
> > > > > Sent: Thursday, May 24, 2001 2:20 PM
> > > > > To: [email-masked]; [email-masked]
> > > > > Cc: Ash, Gerald R (Jerry)
> > > > > Subject: RE: GMPLS Last Calls
> > > > >
> > > > > Quoting from the CCAMP/IETF-50 meeting minutes re the
> > > GMPLS Architecture
> > > > > draft:
> > > > >
> > > > > "Eve - Had hoped that CCAMP formation and expression of
> > > requirements would
> > > > > enable us to do more with architecture than reverse
> > > architect proposed
> > > > > solution. Think we should also look at carrier
> > > requirements and look for
> > > > > discrepancies with architecture.
> > > > > Curtis - requirements of carriers not being addressed?
> > > > > Eve - happy to discuss on mailing list in absence of time"
> > > > >
> > > > > There are still no documented service provider (SP)
> > > requirements driving
> > > > the
> > > > > proposed GMPLS protocol extensions.  This is inconsistent
> > > with the current
> > > > > initiatives to provide SP requirements prior to protocol
> > > extensions being
> > > > > accepted, such as for protection/restoration, network
> > > hierarchy, MPLS OAM,
> > > > > MPLS/DiffServ TE, multi-area TE, etc.
> > > > >
> > > > > Here is a sample of SP requirements that are not being
> > > addressed (other
> > > > > requirements from our perspective are forthcoming):
> > > > >
> > > > > 1. Restoration requirements, particularly in support of
> > > mesh restoration,
> > > > > need to be supported by GMPLS.  For example, Section 7 of
> > > the Generalized
> > > > > Signaling I-D
> > > > >
> > > >
> > > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > > ed-signaling-0
> > > > > 4.txt)
> > > > > primarily discusses link protection, restoration
> > > capabilities are largely
> > > > > missing and need to be included.
> > > > >
> > > > > 2. Standards explicitly supported by GMPLS, such as
> > > G.707, G.709, etc.,
> > > > > should be clearly identified in the text and referenced
> > > in the GMPLS I-Ds,
> > > > > e.g., in Section 3.1 of the Generalized Signaling 
> I-D, add "G.707
> > > > [Reference
> > > > > G.707] is supported by the Generalized Label Request."
> > > > >
> > > > > As per Eve's comment at IETF-50, SPs are encouraged 
> to post their
> > > > > requirements to the list.  It would also help if more SPs
> > > were invited to
> > > > > co-author the GMPLS drafts, to help ensure that SP
> > > requirements are more
> > > > > adequately reflected and addressed.
> > > > >
> > > > > Jerry Ash
> > > > > AT&T Labs
> > > > >
> > > > > -----Original Message-----
> > > > > From: George Swallow [mailto:[email-masked]]
> > > > > Sent: Monday, May 14, 2001 1:52 PM
> > > > > To: [email-masked]; [email-masked]
> > > > > Subject: GMPLS Last Calls
> > > > >
> > > > > This message initiates a last call on four GMPLS 
> drafts.  The last
> > > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > > >
> > > > > The drafts are:
> > > > >
> > > > >     1.  Generalized MPLS - Signaling Functional Description
> > > > >
> > > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > > >
> > > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > > >
> > > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > > >
> > > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > > >
> > > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > > >
> > > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > > >
> > > > > The last call closes May 29, 12 pm GMT.
> > > > >
> > > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > > >
> > > > >
> > > 
> ======================================================================
> > > > > George Swallow       Cisco Systems
> > > (978) 244-8143
> > > > >                      250 Apollo Drive
> > > > >                      Chelmsford, Ma 01824
> > >
> 

Delivery-date: Sat, 26 May 2001 03:13:09 -0700
Date: Sat, 26 May 2001 12:10:31 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Brungard, Deborah A" <[email-masked]>
CC: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], Eric Mannie <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type

This is a multi-part message in MIME format.
--------------B39B1377DED035A951C9186F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

Back to question on the LSP EncType concerning SDH/Sonet, when 
proposed it was to enable specific inter-working between capabilities
provided in v2000 and not in v1996 of SDH (for instance the in-band 
FEC P1/Q1 and REI M0/M1) this distinction was proposed mainly for 
on-demand Transparency service usage (introduced in the SDH/Sonet 
GMPLS document). I guess you agree with me that v2000 include a lot 
of differences compared to the v1996.

Now since the SDH/Sonet extensions draft does not make this distinction 
anymore in response to lighter Transparency services, I suggest to keep
only two LSPEncType codepoints one for SDH and one for Sonet making the
assumption that versions are backward compatible as it should be the 
case. Do you agree with the proposed change ? I propose this otherwise
changes into the SDH/Sonet draft won't be minor anymore.

Your question on inter-working between Sonet and SDH is valid, the 
proposal up to now is to use a "proxy" function making appearing the
connection for the SDH side as an SDH LSP and as an Sonet connection
for the other side by enabling the corresponding "modification" at the 
entity performing the interworking function. Since this is not
completely
defined into the document i propose to indicate as well that more
details will be provided in next releases or even in a specific
document concerning this issue.

What do you think about ?

Regards.
- Dimitri.

"Brungard, Deborah A" wrote:
> 
> All,
> 
> (I've changed the subject field to signal a "switch" of topics - and kept
> q11 and t1x15 lists as the mail is related to their subject areas)
> 
> I also had some questions/comments on the LSP encoding types- section 3.1.1-
> 
> can someone explain why different values are used for different versions of
> T1.105 and G.707? The later versions contain updates to include OC-768 and
> new functions e.g. FEC, J0 support of 16-byte in addition to previous 1-byte
> version, etc. One can not assume equipment supports all functions described
> in any of the versions; one can only assume if the function is supported, it
> is supported as defined. Example, equipment "supporting" T1.105 '95 may not
> support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> "supporting" details/references can be addressed in the technology specific
> documents.
> 
> Similar comment for PDH - E1 services are supported in the U.S. and 45M are
> supported in Europe. One code can be used: PDH.
> 
> For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> digital wrapper - G709 defines a hierarchy: optical and electrical. Reading
> the attached mail, on waveband switching and assigning Lambda as an LSP
> type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> functionality for OTN signals - it is different from today's SONET/metro WDM
> equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in the
> OTN technology specific document.
> 
> Probably should include LSP ranges for future items (and proprietary?).
> 
> Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc. SONET),
> OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> 
> The G-PID has discrete values for DS1, DS3 whereas only one value for all
> STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> others supported, and no SDH VC-4. The G-PID seems to be redundant info with
> the technology specific parameters - is there a reason to support this in
> the generalized label request?
> 
> Regards,
> Deborah Brungard
> AT&T
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 10:25 AM
> To: 'Yuri Landry'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 7:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits. This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------B39B1377DED035A951C9186F
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------B39B1377DED035A951C9186F--

Delivery-date: Fri, 25 May 2001 21:10:19 -0700
Date: Sat, 26 May 2001 00:02:19 -0400
From: Charles Kalmanek <[email-masked]>
To: Fong Liaw <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>, [email-masked], "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last call - RSVP problems

Fong,

This set of mechanisms based on RSVP Hello seems to protect against 
data plane disruption in the presence of either control channel or 
node (i.e. control plane) failure.  It also handles state resynchronization 
when the failed control plane comes back up using Srefresh.

If the control plane stays down for a very long time, there is the inverse
problem of how to clean up the dangling hard state in the other nodes 
along the path.  Either the users (via UNI) or the service provider (via a 
management system) may want to trigger deletion.

Do you plan to propose some text for the GMPLS drafts?  It would
be good to see if it holds up.  

Seems like this needs to be in GMPLS, not just OIF UNI since it
is relevant to the behavior of intermediate nodes  

chuck

Fong Liaw wrote:

(snip)
> >  >    If a control channel failure is detected, LSPs states
> >  >    are maintained as if a node continues to receive
> >  >    RSVP refresh message from the failed control channel.
> >  >    The recommended Hello timer will be in second range,
> >  >    instead of ms range specified in RSVP-TE draft.
> >  >
> >  >    If a control channel failed permanently, manual intervention
> >  >    may be required. This is to be studied.
> >  >
> >  > p.s The text is currently being drafted as we type.
>
> Note, In a node failure case, a node may lose all of
> its RSVP states. To cover this case, we recommend
> using the Srefresh procedure upon restoration of
> control channel. This will synchronize states on
> both sides.

Delivery-date: Fri, 25 May 2001 17:41:26 -0700
From: Dimitrios Pendarakis <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, Dimitrios Pendarakis <[email-masked]>, "'Fong Liaw'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>, [email-masked]
Cc: "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 20:42:29 -0400

Hi Jonathan,

What needs to be detected here is the inability to send and 
receive signaling messages to and from your RSVP peer. In this 
respect, using RSVP Hello is a more accurate mechanism for 
detecting failures since it is part of the RSVP protocol and 
independent of the link layer used to realize the control 
channel. As you point out, if you prefer redundant control 
channels for resiliency, and want to rely on LMP only, you have
to correlate all LMP detected failures in order to declare a 
control channel failure. With RSVP Hello you would rely on a 
single set of event(s) to detect the failure.
To go even further, what if all your control channels are working
fine, but your RSVP daemon has crashed, for whatever reason.
LMP hellos will keep going across but RSVP messages will not...

All this points to the (certainly non-trivial) problem of failure 
detection and correlation at different layers. I am not trying to
say that RSVP Hello is the perfect or only mechanism we should rely 
on, but it certainly has a place in addressing the problem.

Thanks,
Dimitris

PS. Hopefully we are not too far apart so we might not have
to keep the discussion going for too long :-)
In any case I believe it has some relevance here as well.

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 6:56 PM
> To: 'Dimitrios Pendarakis'; Jonathan Lang; 'Fong Liaw'; 'suresh
> Katukam'; [email-masked]
> Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> Subject: RE: Last call - RSVP problems
> 
> 
> Dimitris,
>   The RSVP Hello Extension is intended to detect node failures and not
> necessarily link (control channel) failures.  In particular, 
> the tunnel
> draft says, "It should be noted that node failure detection 
> is not the same
> as a link failure detection mechanism, particularly in the 
> case of multiple
> parallel unnumbered links."  What happens if you want 
> redundant control
> channels for control-channel resiliency?  I believe you would 
> still want a
> mechanism to detect control channel (link-layer) failures.
> 
>   In LMP, you can have multiple active control channels 
> between a pair of
> nodes.  You can configure control channels over shared 
> Ethernet and over
> SONET/SDH overhead, etc.  You send keep-alive Hellos over each control
> channel.  If you so desire, you can send all signaling 
> messages over the
> Ethernet control channels.  You can also choose to send all 
> remaining LMP
> messages over the SONET/SDH-based control channels.  Keeping 
> RSVP Hellos as
> "optional" would be fine.  Making them mandatory doesn't seem 
> like the right
> solution.
> 
> Thanks,
> Jonathan
> 
> P.S.  Should we move this discussion on the OIF list??
> 
> > -----Original Message-----
> > From: Dimitrios Pendarakis [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 3:16 PM
> > To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; 
> [email-masked]
> > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > Subject: RE: Last call - RSVP problems
> > 
> > 
> > Hi Jonathan,
> > 
> > One point to consider is that the signaling control 
> > channel might be realized over a different link layer 
> > than LMP. For example, LMP might be running in-fiber
> > over SONET/SDH overhead bytes, while RSVP is running 
> > over an out-of-band network such a shared Ethernet.
> > RSVP Hello allows independent detection of signaling 
> > channel failure, so it's a useful option to keep.
> > 
> > Thanks,
> > Dimitris
> > 
> > Dimitris Pendarakis
> > Tellium, Inc.
> > 
> > 
> > > -----Original Message-----
> > > From: Jonathan Lang [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 5:30 PM
> > > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > > Subject: RE: Last call - RSVP problems
> > > 
> > > 
> > > Fong,
> > > 
> > > 
> > > <snip>
> > > > Same as (2), any proposals that remove the refresh mechanism 
> > > > is going to be difficult to prove that all cases are covered.
> > > > 
> > > > Instead, we (will) recommend the following in OIF UNI document:
> > > >    
> > > >    Use RSVP Hello to detect control channel failure.
> > > Why wouldn't you use the LMP Hello to detect control channel 
> > > failure?  This
> > > is exactly what it is designed for.  From 
> > > draft-ietf-mpls-lsp-tunnel-08.txt,
> > > 
> > >   "This (RSVP Hello) mechanism is intended to be used when 
> > > notification of
> > > link layer
> > >    failures is not available and unnumbered links are not 
> > > used, or when
> > >    the failure detection mechanisms provided by the link 
> > layer are not
> > >    sufficient for timely node failure detection."
> > >  
> > > >    If a control channel failure is detected, LSPs states 
> > > >    are maintained as if a node continues to receive 
> > > >    RSVP refresh message from the failed control channel.
> > > >    The recommended Hello timer will be in second range,
> > > >    instead of ms range specified in RSVP-TE draft.  
> > > > 
> > > >    If a control channel failed permanently, manual intervention 
> > > >    may be required. This is to be studied.
> > > > 
> > > > p.s The text is currently being drafted as we type.
> > > 
> > 
> 

Delivery-date: Fri, 25 May 2001 17:19:23 -0700
Date: Fri, 25 May 2001 20:17:32 -0400
From: "C. R. Kalmanek" <[email-masked]>
To: Bala Rajagopalan <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

Bala,

Just getting back to email this evening...  

New objects will certainly be needed.  As for whether restoration
can be handled purely as extensions to the current drafts remains 
to be seen -- it would be nice.

chuck

Bala Rajagopalan wrote:
> 
> Chuck:
> 
> I believe that the restoration issue can be
> dealt with indepedent of the current drafts
> on last call. Do you see any obstacles to
> adding new objects/semantics (if any) to support
> restoration requirements as they arise?
> 
> BTW, there are some drafts floating around
> on shared mesh.
> 
> regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked]
> 
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 1:08 PM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> >
> >
> > I fully agree: there are a whole spectrum of options that we
> > need to sort through, and clear requirements are needed to
> > guide that process.  Our concern is with the last call.  It
> > doesn't make sense to progress drafts to RFC that are likely
> > in hindsight to be viewed as having serious deficiencies in
> > meeting restoration requirements.
> >
> > chuck
> >
> > John Drake wrote:
> > >
> > > The point is that in GMPLS, as in regular MPLS, restoration
> > consists of
> > > rerouting from the endpoints upon
> > > notification of failure.  There are a whole spectrum of
> > path and span
> > > protection possibilites beyond this
> > > that people (including us) have proposed, but in the absence of firm
> > > requirements, it's hard to know which
> > > to pursue.  I'm not sure 'shared mesh restoration'
> > completely covers it.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 9:54 AM
> > > To: John Drake
> > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > > [email-masked]
> > > Subject: Re: GMPLS Last Calls
> > >
> > > John,
> > >
> > > While there currently are no restoration requirements from the
> > > TE (or other) group, what Percy is saying is that shared mesh
> > > restoration WILL be a requirement from those groups.  Since the
> > > current GMPLS drafts don't meet this requirement, they are
> > > unlikely to meet key SP needs.
> > >
> > > I don't understand a process that starts the requirements
> > > development after last call for the signaling specifications.
> > >
> > > chuck
> > >
> > > John Drake wrote:
> > > >
> > > > Percy,
> > > >
> > > > There has been work on protocols for path restoration in
> > mesh networks by
> > > a
> > > > number of
> > > > people.  However, at the last IETF Kireeti and Vijay
> > clearly indicated
> > > that
> > > > this work,
> > > > while interesting, wouldn't be allowed to progress in advance of a
> > > > restoration requirements
> > > > draft from the TE group.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > > Sent: Thursday, May 24, 2001 11:55 AM
> > > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > There is a significant issue related to the absence of
> > restoration in the
> > > > signaling draft
> > > >
> > >
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt). Very specifically, Section 7 of this draft deals
> > with the case
> > > > involving protection information for link protection. While link
> > > protection
> > > > schemes may be desirable for fast recovery related to
> > high priority LSP's,
> > > > more cost-effective shared mesh restoration schemes would
> > be preferred for
> > > > the majority of traffic from a Service Provider's
> > perspective. This
> > > > observation is supported by the fact that many vendors
> > are currently
> > > > developing proprietary schemes for shared mesh
> > restoration. Hence, in
> > > > addition to the protection information, GMPLS signaling
> > needs to reflect a
> > > > minimum set of information/attributes required for shared
> > mesh restoration
> > > > without jeopardizing vendor proprietary solutions.
> > > >
> > > > The need for multiple types of restoration capabilities
> > is well documented
> > > > in the OIF/UNI I-D
> > > >
> > >
> > http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> > ework-uni-00.t
> > > > xt as follows:
> > > >
> > > > " Multiple types of facilities available for restoration
> > are needed
> > > >    within the network. The following options should be
> > considered for
> > > >    allocation of facilities to support restoration of failed
> > > >    connections:
> > > >    - Dedicated restoration capacity
> > > >    - Shared restoration capacity. This allows the network
> > to ensure
> > > >      high quality service for customers, while still managing its
> > > >      physical resources efficiently.
> > > >    - Un-restorable
> > > >    - Pre-emptable"
> > > >
> > > > The OIF/UNI I-D supports a range of different restoration
> > schemes through
> > > > the use of service level as a connection attribute. This
> > attribute is
> > > > defined as follows:
> > > >
> > > > " an integer attribute that indicates a class of service.
> > A carrier may
> > > > specify a range of different classes of service (e.g.
> > gold, silver,
> > > bronze)
> > > > with predefined characteristics (e.g. restoration plans).
> > The pre-defined
> > > > service types correspond to different types of network
> > restoration (e.g.
> > > no
> > > > restoration, 1+1 protection), connection set-up and hold
> > priorities,
> > > > reversion strategies for the connection after failures
> > have been repaired,
> > > > and retention strategies."
> > > >
> > > > It is therefore important that GMPLS be extended to be
> > able to support
> > > such
> > > > restoration schemes.
> > > >
> > > > Percy S. Tarapore
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: Ash, Gerald R (Jerry)
> > > > Sent: Thursday, May 24, 2001 2:20 PM
> > > > To: [email-masked]; [email-masked]
> > > > Cc: Ash, Gerald R (Jerry)
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > Quoting from the CCAMP/IETF-50 meeting minutes re the
> > GMPLS Architecture
> > > > draft:
> > > >
> > > > "Eve - Had hoped that CCAMP formation and expression of
> > requirements would
> > > > enable us to do more with architecture than reverse
> > architect proposed
> > > > solution. Think we should also look at carrier
> > requirements and look for
> > > > discrepancies with architecture.
> > > > Curtis - requirements of carriers not being addressed?
> > > > Eve - happy to discuss on mailing list in absence of time"
> > > >
> > > > There are still no documented service provider (SP)
> > requirements driving
> > > the
> > > > proposed GMPLS protocol extensions.  This is inconsistent
> > with the current
> > > > initiatives to provide SP requirements prior to protocol
> > extensions being
> > > > accepted, such as for protection/restoration, network
> > hierarchy, MPLS OAM,
> > > > MPLS/DiffServ TE, multi-area TE, etc.
> > > >
> > > > Here is a sample of SP requirements that are not being
> > addressed (other
> > > > requirements from our perspective are forthcoming):
> > > >
> > > > 1. Restoration requirements, particularly in support of
> > mesh restoration,
> > > > need to be supported by GMPLS.  For example, Section 7 of
> > the Generalized
> > > > Signaling I-D
> > > >
> > >
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt)
> > > > primarily discusses link protection, restoration
> > capabilities are largely
> > > > missing and need to be included.
> > > >
> > > > 2. Standards explicitly supported by GMPLS, such as
> > G.707, G.709, etc.,
> > > > should be clearly identified in the text and referenced
> > in the GMPLS I-Ds,
> > > > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > > [Reference
> > > > G.707] is supported by the Generalized Label Request."
> > > >
> > > > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > > > requirements to the list.  It would also help if more SPs
> > were invited to
> > > > co-author the GMPLS drafts, to help ensure that SP
> > requirements are more
> > > > adequately reflected and addressed.
> > > >
> > > > Jerry Ash
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: George Swallow [mailto:[email-masked]]
> > > > Sent: Monday, May 14, 2001 1:52 PM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: GMPLS Last Calls
> > > >
> > > > This message initiates a last call on four GMPLS drafts.  The last
> > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > >
> > > > The drafts are:
> > > >
> > > >     1.  Generalized MPLS - Signaling Functional Description
> > > >
> > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > >
> > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > >
> > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > >
> > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > >
> > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > >
> > > > The last call closes May 29, 12 pm GMT.
> > > >
> > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > >
> > > >
> > ======================================================================
> > > > George Swallow       Cisco Systems
> > (978) 244-8143
> > > >                      250 Apollo Drive
> > > >                      Chelmsford, Ma 01824
> >

Delivery-date: Fri, 25 May 2001 16:37:45 -0700
From: "Irfan Lateef" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 19:34:26 -0400

Dimitrios,

You have brought up a good point.
Is there any ongoing effort to standardize
the signalling mechanism on the optical side.
Namely in-band SONET-DCC OH bytes vs out-of-band
Ehternet vs in-band IP-over-SONET data plane etc.

Irfan Lateef

>From: Dimitrios Pendarakis <[email-masked]>
>To: "'Jonathan Lang'" <[email-masked]>, "'Fong Liaw'" 
><[email-masked]>,   "'suresh Katukam'" <[email-masked]>, 
>[email-masked]
>CC: "'Jennifer Yates'" <[email-masked]>, [email-masked],   
>[email-masked]
>Subject: RE: Last call - RSVP problems
>Date: Fri, 25 May 2001 18:16:12 -0400
>
>Hi Jonathan,
>
>One point to consider is that the signaling control
>channel might be realized over a different link layer
>than LMP. For example, LMP might be running in-fiber
>over SONET/SDH overhead bytes, while RSVP is running
>over an out-of-band network such a shared Ethernet.
>RSVP Hello allows independent detection of signaling
>channel failure, so it's a useful option to keep.
>
>Thanks,
>Dimitris
>
>Dimitris Pendarakis
>Tellium, Inc.
>
>
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 5:30 PM
> > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > Subject: RE: Last call - RSVP problems
> >
> >
> > Fong,
> >
> >
> > <snip>
> > > Same as (2), any proposals that remove the refresh mechanism
> > > is going to be difficult to prove that all cases are covered.
> > >
> > > Instead, we (will) recommend the following in OIF UNI document:
> > >
> > >    Use RSVP Hello to detect control channel failure.
> > Why wouldn't you use the LMP Hello to detect control channel
> > failure?  This
> > is exactly what it is designed for.  From
> > draft-ietf-mpls-lsp-tunnel-08.txt,
> >
> >   "This (RSVP Hello) mechanism is intended to be used when
> > notification of
> > link layer
> >    failures is not available and unnumbered links are not
> > used, or when
> >    the failure detection mechanisms provided by the link layer are not
> >    sufficient for timely node failure detection."
> >
> > >    If a control channel failure is detected, LSPs states
> > >    are maintained as if a node continues to receive
> > >    RSVP refresh message from the failed control channel.
> > >    The recommended Hello timer will be in second range,
> > >    instead of ms range specified in RSVP-TE draft.
> > >
> > >    If a control channel failed permanently, manual intervention
> > >    may be required. This is to be studied.
> > >
> > > p.s The text is currently being drafted as we type.
> >
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 25 May 2001 16:00:42 -0700
From: Jonathan Lang <[email-masked]>
To: 'Dimitrios Pendarakis' <[email-masked]>, Jonathan Lang <[email-masked]>, 'Fong Liaw' <[email-masked]>, 'suresh Katukam' <[email-masked]>, [email-masked]
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 15:55:31 -0700

Dimitris,
  The RSVP Hello Extension is intended to detect node failures and not
necessarily link (control channel) failures.  In particular, the tunnel
draft says, "It should be noted that node failure detection is not the same
as a link failure detection mechanism, particularly in the case of multiple
parallel unnumbered links."  What happens if you want redundant control
channels for control-channel resiliency?  I believe you would still want a
mechanism to detect control channel (link-layer) failures.

  In LMP, you can have multiple active control channels between a pair of
nodes.  You can configure control channels over shared Ethernet and over
SONET/SDH overhead, etc.  You send keep-alive Hellos over each control
channel.  If you so desire, you can send all signaling messages over the
Ethernet control channels.  You can also choose to send all remaining LMP
messages over the SONET/SDH-based control channels.  Keeping RSVP Hellos as
"optional" would be fine.  Making them mandatory doesn't seem like the right
solution.

Thanks,
Jonathan

P.S.  Should we move this discussion on the OIF list??

> -----Original Message-----
> From: Dimitrios Pendarakis [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 3:16 PM
> To: 'Jonathan Lang'; 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> Subject: RE: Last call - RSVP problems
> 
> 
> Hi Jonathan,
> 
> One point to consider is that the signaling control 
> channel might be realized over a different link layer 
> than LMP. For example, LMP might be running in-fiber
> over SONET/SDH overhead bytes, while RSVP is running 
> over an out-of-band network such a shared Ethernet.
> RSVP Hello allows independent detection of signaling 
> channel failure, so it's a useful option to keep.
> 
> Thanks,
> Dimitris
> 
> Dimitris Pendarakis
> Tellium, Inc.
> 
> 
> > -----Original Message-----
> > From: Jonathan Lang [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 5:30 PM
> > To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> > Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> > Subject: RE: Last call - RSVP problems
> > 
> > 
> > Fong,
> > 
> > 
> > <snip>
> > > Same as (2), any proposals that remove the refresh mechanism 
> > > is going to be difficult to prove that all cases are covered.
> > > 
> > > Instead, we (will) recommend the following in OIF UNI document:
> > >    
> > >    Use RSVP Hello to detect control channel failure.
> > Why wouldn't you use the LMP Hello to detect control channel 
> > failure?  This
> > is exactly what it is designed for.  From 
> > draft-ietf-mpls-lsp-tunnel-08.txt,
> > 
> >   "This (RSVP Hello) mechanism is intended to be used when 
> > notification of
> > link layer
> >    failures is not available and unnumbered links are not 
> > used, or when
> >    the failure detection mechanisms provided by the link 
> layer are not
> >    sufficient for timely node failure detection."
> >  
> > >    If a control channel failure is detected, LSPs states 
> > >    are maintained as if a node continues to receive 
> > >    RSVP refresh message from the failed control channel.
> > >    The recommended Hello timer will be in second range,
> > >    instead of ms range specified in RSVP-TE draft.  
> > > 
> > >    If a control channel failed permanently, manual intervention 
> > >    may be required. This is to be studied.
> > > 
> > > p.s The text is currently being drafted as we type.
> > 
> 

Delivery-date: Fri, 25 May 2001 15:54:43 -0700
Date: Sat, 26 May 2001 00:52:33 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Brungard, Deborah A" <[email-masked]>
CC: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type

This is a multi-part message in MIME format.
--------------30B7B4AF712B2489206E82D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Thanks for your comments. This is one very important issue that 
you raise here. Let's try to evaluate in a first time the criteria 
that we have to take into account here:

- The purpose in the document was to define an LSP EncType per 
  networking layer or more precisely per group of functional 
  networking layer (i.e. ODUk and OCh)

- I agree that today SDH/Sonet is a flat LSP EncType space (would
  be very difficult for me to say that LOVC and HOVC are separated 
  since included into a flat LSP EncType space - they don't appear
  as "two layers" in GMPLS but as TDM-LSPs a VC-11 as a VC-4-256c
  distinction is made through the use of the signal type)

- Today GMPLS-SIG introduce a distinction between non-standard DW
  and lambda layer (assumption is made here that the non-standard DW
  is a switching layer) without describing the stacking of these
  two layers i assume that when using lambda it is only with a framing
  procedure (that can be non-standard as well)

- So that i tried to use the previous encoding as an analogy to make
  things appearing more "natural" by defining two layers even if for
  the common understanding by ITU-T/T1 people a common G.709 is more
  appropriate

Am i missing any other criteria ? If you think so please tell me.

Now we take a common LSP EncType, then Signal Types have to be specified
to include ODU1, ODU2, ODU3 and OCh's and the multiplexing mechanism
specified for each Signal Type.

It doesn't seem to change fundamentally the functions if we take
a common LSP EncType. Let me however the needed time to think more
extensively about this proposal and discuss with other people 
involved into the document today (others are welcome) to decide
about this. I will keep you informed about these changes.

Regards,
Dimitri. 

"Brungard, Deborah A" wrote:
> 
> Thanks Dimitri for your response (and draft-gmpls-g709). In the draft,
> though, it refers to 3 code points for DW (1 for g709, 2 for prop.) and 2
> code points for Lambda (1 for g709, 1 for non-OTN). Whereas in the current
> mpls-generalized only 1 for DW and 1 for Lambda is provided. Is the
> intention to assign additional codes later to support these variations?
> 
> Separate from the assignment of code points, the use of the term digital
> wrapper (as you note in your draft on gmpls-g709)can have several
> interpretations. The term was used in the introduction of the concept in the
> standards bodies but it was never used in any of the standards (drafts or
> approved). The preference would be to have a separate code point for G709;
> and not confuse it with non-standard "wrappers" or lambdas. The G709 layers
> include the lambda layer (OMS). To align with the other code points (e.g.
> SDH/SONET) which include all the layers, it would be simpler to include all
> the layers for G709 with one code point.
> 
> Proposal:
> code point for G.709
> code point for digital wrapper (non-standard)
> code point for lambda (non-standard)
> 
> OK?
> 
> Regards,
> Deborah
> 
> -----Original Message-----
> From: Dimitri Papadimitriou [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 12:21 PM
> To: Brungard, Deborah A
> Cc: 'John Drake'; 'Yuri Landry'; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP
> encoding type
> 
> Hello,
> 
> You concerns on G.709 OTN have been addressed in the corresponding
> technology specific document (new version to be published very soon).
> 
> In order to make the distinction between the electrical and optical
> hierarchy through the corresponding networking layers (i.e. ODUk and
> OCh), we defined a G.709 DW (the ODUk layer) and G.709 OCh. While
> taking into account non-standard DW and Lambda (i.e. pre-OTN when
> using the ITU/T1 terminology).
> 
> Hope this clarifies the situation at least for this specific point.
> 
> Regards,
> Dimitri.
> 
> "Brungard, Deborah A" wrote:
> >
> > All,
> >
> > (I've changed the subject field to signal a "switch" of topics - and kept
> > q11 and t1x15 lists as the mail is related to their subject areas)
> >
> > I also had some questions/comments on the LSP encoding types- section
> 3.1.1-
> >
> > can someone explain why different values are used for different versions
> of
> > T1.105 and G.707? The later versions contain updates to include OC-768 and
> > new functions e.g. FEC, J0 support of 16-byte in addition to previous
> 1-byte
> > version, etc. One can not assume equipment supports all functions
> described
> > in any of the versions; one can only assume if the function is supported,
> it
> > is supported as defined. Example, equipment "supporting" T1.105 '95 may
> not
> > support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> > "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> > "supporting" details/references can be addressed in the technology
> specific
> > documents.
> >
> > Similar comment for PDH - E1 services are supported in the U.S. and 45M
> are
> > supported in Europe. One code can be used: PDH.
> >
> > For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> > digital wrapper - G709 defines a hierarchy: optical and electrical.
> Reading
> > the attached mail, on waveband switching and assigning Lambda as an LSP
> > type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> > Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> > functionality for OTN signals - it is different from today's SONET/metro
> WDM
> > equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in
> the
> > OTN technology specific document.
> >
> > Probably should include LSP ranges for future items (and proprietary?).
> >
> > Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc.
> SONET),
> > OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> >
> > The G-PID has discrete values for DS1, DS3 whereas only one value for all
> > STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> > others supported, and no SDH VC-4. The G-PID seems to be redundant info
> with
> > the technology specific parameters - is there a reason to support this in
> > the generalized label request?
> >
> > Regards,
> > Deborah Brungard
> > AT&T
> >
> > -----Original Message-----
> > From: John Drake [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 10:25 AM
> > To: 'Yuri Landry'; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena tion
> >
> > Yuri,
> >
> > I've attached a private note I sent to Dimitri regarding waveband
> switching.
> > It was originally put in at the suggestion of NorTel.  For both waveband
> > switching and fiber switching, you are dealing with a situation in which
> you
> > are using a standardized control plane to establish a multi-hop LSP with
> > proprietary encoding of data.  As I mentioned, this would be accomplished
> > using link coloring.
> >
> > Personally, I have no problem removing either waveband switching or fiber
> > switching, but we know have to accomodate them wrt the control plane, and
> I
> > seriously doubt that there will ever be a completely non-proprietary of
> > encoding the data for these types of LSPs.
> >
> > Note that I am using 'proprietary' in the exclusive sense.
> >
> > Thanks,
> >
> > John
> > -----Original Message-----
> > From: John Drake
> > Sent: Wednesday, March 28, 2001 11:15 AM
> > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> > Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> >
> > Dimitri.
> >
> > It's probably better to think of waveband switching as a special form of
> > fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at
> all.
> > Suppose the trunk side of a DWDM system is attached to a PXC.  In the
> fiber
> > switching case, the fiber between the DWDM system and a port on the PXC
> > contains the entire set of lambdas, while in the waveband switching case
> > there is a set of fibers between the DWDM system and a set of ports on the
> > PXC, each of which contains a separate waveband.
> >
> > In either case, the encoding of the signal on the fibers is completely
> > proprietary, and it's the job of routing to ensure that a correct path
> > through the network is obtained, such that the proprietary encoding is
> > maintained end-end.  This would probably be done through link coloring, so
> > that you only route across links that support NorTel waveband switching or
> > Tellabs waveband switching.
> >
> > So I think the signalling stuff is fine.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Yuri Landry [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 7:02 AM
> > To: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena tion
> >
> > Hello All,
> >
> > So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> > re-direct your attention to other drafts. Rob's suggestion should apply to
> > other drafts too.
> >
> > One example, is the waveband switching and waveband label a standard or
> > proprietary? Can author explain to me what exactly they means? How do they
> > work? Any other standard reference? There are questions about it but no
> > answer yet.
> >
> > Regards,
> >
> > Yuri.
> >
> > >From: "Lazer, Monica A, NNAD" <[email-masked]>
> > >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> > >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> > ><[email-masked]>
> > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena
> > >tion
> > >Date: Thu, 24 May 2001 18:11:36 -0400
> > >
> > >
> > >Rob, You proposal makes a lot of sense. Having the signaling standard
> > >support proprietary transport may jeopardize interoperability. The issue
> is
> > >not about GMPLS supporting non-standard rates, the issue is about putting
> > >in
> > >formal and very specific support for a proprietary transport solution in
> a
> > >standard document for signaling without taking the transport portion to a
> > >standards body. Having formal signaling support for a proprietary
> > >concatenation may cause interoperability issues when other vendors have a
> > >different solution to the concatenation and while the signaling would
> > >indicate the concatenation, the actual transport may not work.   On the
> > >other hand we recognize that there may be a need for some interim support
> > >for proprietary solutions.
> > >
> > >
> > >Eric,
> > >Below I have some additional specific comments for the document GMPLS
> > >Extensions for SONET and SDH Control
> > >
> > >
> > >CCT field (3 bits)
> > >Since arbitrary contiguous concatenation is not a standard concatenation,
> > >it
> > >falls within the vendor proprietary set of solutions.
> > >
> > >So the CCT bits may be used as follows:
> > >000    No contiguous concatenation requested
> > >001    Standard contiguous concatenation
> > >others Vendor specific contiguous concatenation
> > >
> > >Alternatively, a better solution is to use only 2 bits for this field and
> > >use one bit to show whether contiguous concatenation is requested and the
> > >second bit to show whether it is standard or non-standard contiguous
> > >concatenation.
> > >
> > >
> > >NCC field (16 bits)
> > >This information is not sufficient.
> > >NCC needs better description than a zero or non-zero number.
> > >
> > >SDH and SONET Labels
> > >
> > >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> > >GMPLS proposal limits virtual concatenation to remain within a single
> > >(component) link. If I understand this correctly, it means that GMPLS
> will
> > >not allow inverse multiplexing (virtual concatenation) in the transport
> > >plane if it requires different component links. This is too limiting.
> > >
> > >Annex 1 (sent out by Eric Mannie on 5/22)
> > >Defines another type of concatenation - Flexible arbitrary contiguous
> > >concatenation without describing precisely how it affects the OH bits.
> This
> > >means that it will be impossible to have this type of concatenation in a
> > >multi vendor environment based only on the GMPLS signaling. If the
> > >transport
> > >plane is proprietary, having the option in the signaling message will not
> > >fix the interoperability problem between two different vendors supporting
> > >their proprietary versions of arbitrary concatenation.
> > >
> > >Annex 2 (sent out by Eric Mannie on 5/22)
> > >Arbitrary contiguous concatenation needs definition work for
> > >interoperability.
> > >Flexible arbitrary contiguous concatenation may be available today to
> > >support contiguous signals, but it is not defined in the current
> standards.
> > >Clear agreements on OH usage are needed between supporting vendors.
> > >Maintenance and tracking of the signal needs to be well understood.
> > >
> > >
> > >
> > >Monica A. Lazer
> > >Advanced Transport Technology and Architecture Planning
> > >
> > >908 234 8462
> > >[email-masked]
> > >
> > >
> > >-----Original Message-----
> > >From: Rob Coltun [mailto:[email-masked]]
> > >Sent: Thursday, May 24, 2001 7:24 PM
> > >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > >concatenation
> > >
> > >All,
> > >     despite the heated arguments I think the discussion is important to
> > >have.
> > >
> > >I suggest that instead of  tagging non/pre-standard items in the current
> > >drafts
> > >that they be put into a separate Informational document  - this is the
> > >cleanest thing to do.
> > >We (the IETF) do have a tradition of publishing company proprietary
> > >protocols
> > >but not as standard track documents.
> > >
> > >thanks,
> > >---rob
> > >
> > >
> > >
> > >_______________________________________________
> > >IP-Optical mailing list
> > >[email-masked]
> > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > >
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------30B7B4AF712B2489206E82D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------30B7B4AF712B2489206E82D8--

Delivery-date: Fri, 25 May 2001 15:14:51 -0700
From: Dimitrios Pendarakis <[email-masked]>
To: "'Jonathan Lang'" <[email-masked]>, "'Fong Liaw'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>, [email-masked]
Cc: "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 18:16:12 -0400

Hi Jonathan,

One point to consider is that the signaling control 
channel might be realized over a different link layer 
than LMP. For example, LMP might be running in-fiber
over SONET/SDH overhead bytes, while RSVP is running 
over an out-of-band network such a shared Ethernet.
RSVP Hello allows independent detection of signaling 
channel failure, so it's a useful option to keep.

Thanks,
Dimitris

Dimitris Pendarakis
Tellium, Inc.

> -----Original Message-----
> From: Jonathan Lang [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 5:30 PM
> To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
> Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
> Subject: RE: Last call - RSVP problems
> 
> 
> Fong,
> 
> 
> <snip>
> > Same as (2), any proposals that remove the refresh mechanism 
> > is going to be difficult to prove that all cases are covered.
> > 
> > Instead, we (will) recommend the following in OIF UNI document:
> >    
> >    Use RSVP Hello to detect control channel failure.
> Why wouldn't you use the LMP Hello to detect control channel 
> failure?  This
> is exactly what it is designed for.  From 
> draft-ietf-mpls-lsp-tunnel-08.txt,
> 
>   "This (RSVP Hello) mechanism is intended to be used when 
> notification of
> link layer
>    failures is not available and unnumbered links are not 
> used, or when
>    the failure detection mechanisms provided by the link layer are not
>    sufficient for timely node failure detection."
>  
> >    If a control channel failure is detected, LSPs states 
> >    are maintained as if a node continues to receive 
> >    RSVP refresh message from the failed control channel.
> >    The recommended Hello timer will be in second range,
> >    instead of ms range specified in RSVP-TE draft.  
> > 
> >    If a control channel failed permanently, manual intervention 
> >    may be required. This is to be studied.
> > 
> > p.s The text is currently being drafted as we type.
> 

Delivery-date: Fri, 25 May 2001 15:14:15 -0700
Date: Fri, 25 May 2001 18:18:08 -0400
From: Guangzhi Li <[email-masked]>
To: [email-masked], [email-masked]
Subject: GMPLS last call

Hello,

I have one question on GMPLS contention solution.

Contention resolution has been extensively discussed for bi-directional
LSPs. However, it is not clear how contention would be resolved in a
network with both uni-directional and bi-directional LSPs.

Although the immediate applications for mixing uni-directional and
bi-directional LSPs in the same network is not really clear, a
consistent state machine is still required so as not to preclude this in

the future.

Has there been any consideration on this issue? If so, can someone
please explain the rules when contention occurs between a
uni-directional LSP and a bi-directional LSP.

Thanks,

-- Guanghzhi Li

Delivery-date: Fri, 25 May 2001 15:07:49 -0700
Date: Fri, 25 May 2001 18:11:44 -0400
From: Guangzhi Li <[email-masked]>
To: Fong Liaw <[email-masked]>
Cc: "'Jonathan Lang'" <[email-masked]>, "'suresh Katukam'" <[email-masked]>, [email-masked], "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last call - RSVP problems

>
> I agree that if LMP or any link layer fault detection technology
> (such as using SONET/SDH overhead to determine DCC down) can detect
> control channel failure, we don't need to use RSVP Hello.
>
> Note, In a node failure case, a node may lose all of
> its RSVP states. To cover this case, we recommend
> using the Srefresh procedure upon restoration of
> control channel. This will synchronize states on
> both sides.
>

Just thinking. If RSVP-PHOP uses node id instead of control channel
interface address, then control channel failure won't affect control
message forwarding. But node failure is still a problem.

-- Guangzhi

Delivery-date: Fri, 25 May 2001 15:01:27 -0700
Date: Fri, 25 May 2001 18:05:15 -0400
From: Guangzhi Li <[email-masked]>
To: Fong Liaw <[email-masked]>
Cc: "'suresh Katukam'" <[email-masked]>, [email-masked], "'Jennifer Yates'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Last call - RSVP problems

Fong:

>  "Infinite timer" is actually very problematice with RSVP.
> We have specifically recommend NOT to use this, after attempting
> to do it.

What are the specific problems? RSVP uses soft state because the traffic
route may change. In transport networks, the working path does not change
except restoration. If you can explain more, that would be help.

Let's see whether we can cover these problems from other methods, such as
link layer hello and reliable transmisson.

> >  (3) is achieved when Refresh Timers are set to Infinite. By default,
> >  circuit is kept irrespective of failures.
> >
>
> Same as (2), any proposals that remove the refresh mechanism
> is going to be difficult to prove that all cases are covered.

Has anybody proved that some cases have not been covered ? or assume that it
will be difficult to prove that all cases are coved. The second claim may
not be enough to avoid the "infinite timer" solution. If there is a
fundamental requirement to require soft-state, the question will become
easy.

> Instead, we (will) recommend the following in OIF UNI document:
>
>    Use RSVP Hello to detect control channel failure.
>    If a control channel failure is detected, LSPs states
>    are maintained as if a node continues to receive
>    RSVP refresh message from the failed control channel.
>    The recommended Hello timer will be in second range,
>    instead of ms range specified in RSVP-TE draft.
>
>    If a control channel failed permanently, manual intervention
>    may be required. This is to be studied.
>
> p.s The text is currently being drafted as we type.

This is one solution. But GMPLS document does not include this.

> Regards,
> -Fong
>

Thanks,

-- Guangzhi

Delivery-date: Fri, 25 May 2001 14:50:12 -0700
From: Fong Liaw <[email-masked]>
To: 'Jonathan Lang' <[email-masked]>, Fong Liaw <[email-masked]>,  'suresh Katukam' <[email-masked]>, [email-masked]
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 14:49:15 -0700

Hi Jonathan

>  -----Original Message-----
>  From: Jonathan Lang [mailto:[email-masked]]
>  Sent: Friday, May 25, 2001 2:30 PM
>  To: 'Fong Liaw'; 'suresh Katukam'; [email-masked]
>  Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
>  Subject: RE: Last call - RSVP problems
>  
>  
>  Fong,
>  
>  
>  <snip>
>  > Same as (2), any proposals that remove the refresh mechanism 
>  > is going to be difficult to prove that all cases are covered.
>  > 
>  > Instead, we (will) recommend the following in OIF UNI document:
>  >    
>  >    Use RSVP Hello to detect control channel failure.
>  Why wouldn't you use the LMP Hello to detect control channel 
>  failure?  This
>  is exactly what it is designed for.  From 
>  draft-ietf-mpls-lsp-tunnel-08.txt,
>  

I agree that if LMP or any link layer fault detection technology
(such as using SONET/SDH overhead to determine DCC down) can detect
control channel failure, we don't need to use RSVP Hello.

Note, In a node failure case, a node may lose all of 
its RSVP states. To cover this case, we recommend 
using the Srefresh procedure upon restoration of 
control channel. This will synchronize states on 
both sides.  

Regards,
-Fong

 >    "This (RSVP Hello) mechanism is intended to be used when 
>  notification of
>  link layer
>     failures is not available and unnumbered links are not 
>  used, or when
>     the failure detection mechanisms provided by the link 
>  layer are not
>     sufficient for timely node failure detection."
>   
>  >    If a control channel failure is detected, LSPs states 
>  >    are maintained as if a node continues to receive 
>  >    RSVP refresh message from the failed control channel.
>  >    The recommended Hello timer will be in second range,
>  >    instead of ms range specified in RSVP-TE draft.  
>  > 
>  >    If a control channel failed permanently, manual intervention 
>  >    may be required. This is to be studied.
>  > 
>  > p.s The text is currently being drafted as we type.
>  

Delivery-date: Fri, 25 May 2001 14:34:19 -0700
From: Jonathan Lang <[email-masked]>
To: 'Fong Liaw' <[email-masked]>, 'suresh Katukam' <[email-masked]>,  [email-masked]
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 14:29:51 -0700

Fong,

<snip>
> Same as (2), any proposals that remove the refresh mechanism 
> is going to be difficult to prove that all cases are covered.
> 
> Instead, we (will) recommend the following in OIF UNI document:
>    
>    Use RSVP Hello to detect control channel failure.
Why wouldn't you use the LMP Hello to detect control channel failure?  This
is exactly what it is designed for.  From draft-ietf-mpls-lsp-tunnel-08.txt,

  "This (RSVP Hello) mechanism is intended to be used when notification of
link layer
   failures is not available and unnumbered links are not used, or when
   the failure detection mechanisms provided by the link layer are not
   sufficient for timely node failure detection."
 
>    If a control channel failure is detected, LSPs states 
>    are maintained as if a node continues to receive 
>    RSVP refresh message from the failed control channel.
>    The recommended Hello timer will be in second range,
>    instead of ms range specified in RSVP-TE draft.  
> 
>    If a control channel failed permanently, manual intervention 
>    may be required. This is to be studied.
> 
> p.s The text is currently being drafted as we type.

Delivery-date: Fri, 25 May 2001 14:32:51 -0700
From: "Brungard, Deborah A" <[email-masked]>
To: "'Dimitri Papadimitriou'" <[email-masked]>
Cc: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding  type
Date: Fri, 25 May 2001 17:29:12 -0400

Thanks Dimitri for your response (and draft-gmpls-g709). In the draft,
though, it refers to 3 code points for DW (1 for g709, 2 for prop.) and 2
code points for Lambda (1 for g709, 1 for non-OTN). Whereas in the current
mpls-generalized only 1 for DW and 1 for Lambda is provided. Is the
intention to assign additional codes later to support these variations?

Separate from the assignment of code points, the use of the term digital
wrapper (as you note in your draft on gmpls-g709)can have several
interpretations. The term was used in the introduction of the concept in the
standards bodies but it was never used in any of the standards (drafts or
approved). The preference would be to have a separate code point for G709;
and not confuse it with non-standard "wrappers" or lambdas. The G709 layers
include the lambda layer (OMS). To align with the other code points (e.g.
SDH/SONET) which include all the layers, it would be simpler to include all
the layers for G709 with one code point.

Proposal:
code point for G.709
code point for digital wrapper (non-standard)
code point for lambda (non-standard)

OK?

Regards,
Deborah

-----Original Message-----
From: Dimitri Papadimitriou [mailto:[email-masked]]
Sent: Friday, May 25, 2001 12:21 PM
To: Brungard, Deborah A
Cc: 'John Drake'; 'Yuri Landry'; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP
encoding type

Hello,

You concerns on G.709 OTN have been addressed in the corresponding
technology specific document (new version to be published very soon).

In order to make the distinction between the electrical and optical
hierarchy through the corresponding networking layers (i.e. ODUk and
OCh), we defined a G.709 DW (the ODUk layer) and G.709 OCh. While 
taking into account non-standard DW and Lambda (i.e. pre-OTN when
using the ITU/T1 terminology).

Hope this clarifies the situation at least for this specific point.

Regards,
Dimitri.

"Brungard, Deborah A" wrote:
> 
> All,
> 
> (I've changed the subject field to signal a "switch" of topics - and kept
> q11 and t1x15 lists as the mail is related to their subject areas)
> 
> I also had some questions/comments on the LSP encoding types- section
3.1.1-
> 
> can someone explain why different values are used for different versions
of
> T1.105 and G.707? The later versions contain updates to include OC-768 and
> new functions e.g. FEC, J0 support of 16-byte in addition to previous
1-byte
> version, etc. One can not assume equipment supports all functions
described
> in any of the versions; one can only assume if the function is supported,
it
> is supported as defined. Example, equipment "supporting" T1.105 '95 may
not
> support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> "supporting" details/references can be addressed in the technology
specific
> documents.
> 
> Similar comment for PDH - E1 services are supported in the U.S. and 45M
are
> supported in Europe. One code can be used: PDH.
> 
> For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> digital wrapper - G709 defines a hierarchy: optical and electrical.
Reading
> the attached mail, on waveband switching and assigning Lambda as an LSP
> type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> functionality for OTN signals - it is different from today's SONET/metro
WDM
> equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in
the
> OTN technology specific document.
> 
> Probably should include LSP ranges for future items (and proprietary?).
> 
> Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc.
SONET),
> OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> 
> The G-PID has discrete values for DS1, DS3 whereas only one value for all
> STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> others supported, and no SDH VC-4. The G-PID seems to be redundant info
with
> the technology specific parameters - is there a reason to support this in
> the generalized label request?
> 
> Regards,
> Deborah Brungard
> AT&T
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 10:25 AM
> To: 'Yuri Landry'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband
switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which
you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and
I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at
all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the
fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 7:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue
is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in
a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS
will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits.
This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current
standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Fri, 25 May 2001 14:22:27 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Tarapore, Percy S'" <[email-masked]>, Bala Rajagopalan <[email-masked]>, "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Fri, 25 May 2001 17:22:31 -0400

This would be fine with me. John? Lou?

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Tarapore, Percy S [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:34 PM
> To: 'Bala Rajagopalan'; 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> 
> Bala,
> 
> Are you suggesting that restoration signaling requirements be 
> formulated in
> a separate GMPLS draft at a later date? If so, the current 
> draft should add
> text regarding the current scope (link protection only) as 
> well as future
> work (restoration) in Section 7.
> 
> Percy
> 
> -----Original Message-----
> From: Bala Rajagopalan [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 1:57 PM
> To: 'C. R. Kalmanek'; John Drake
> Cc: [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> 
> 
> Chuck:
> 
> I believe that the restoration issue can be
> dealt with indepedent of the current drafts
> on last call. Do you see any obstacles to
> adding new objects/semantics (if any) to support
> restoration requirements as they arise?
> 
> BTW, there are some drafts floating around
> on shared mesh.
> 
> regards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked] 
> 
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 1:08 PM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> > 
> > 
> > I fully agree: there are a whole spectrum of options that we
> > need to sort through, and clear requirements are needed to
> > guide that process.  Our concern is with the last call.  It
> > doesn't make sense to progress drafts to RFC that are likely 
> > in hindsight to be viewed as having serious deficiencies in
> > meeting restoration requirements.
> > 
> > chuck
> > 
> > John Drake wrote:
> > > 
> > > The point is that in GMPLS, as in regular MPLS, restoration 
> > consists of
> > > rerouting from the endpoints upon
> > > notification of failure.  There are a whole spectrum of 
> > path and span
> > > protection possibilites beyond this
> > > that people (including us) have proposed, but in the 
> absence of firm
> > > requirements, it's hard to know which
> > > to pursue.  I'm not sure 'shared mesh restoration' 
> > completely covers it.
> > > 
> > > Thanks,
> > > 
> > > John
> > > 
> > > -----Original Message-----
> > > From: C. R. Kalmanek [mailto:[email-masked]]
> > > Sent: Friday, May 25, 2001 9:54 AM
> > > To: John Drake
> > > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); 
> [email-masked];
> > > [email-masked]
> > > Subject: Re: GMPLS Last Calls
> > > 
> > > John,
> > > 
> > > While there currently are no restoration requirements from the
> > > TE (or other) group, what Percy is saying is that shared mesh
> > > restoration WILL be a requirement from those groups.  Since the
> > > current GMPLS drafts don't meet this requirement, they are
> > > unlikely to meet key SP needs.
> > > 
> > > I don't understand a process that starts the requirements
> > > development after last call for the signaling specifications.
> > > 
> > > chuck
> > > 
> > > John Drake wrote:
> > > >
> > > > Percy,
> > > >
> > > > There has been work on protocols for path restoration in 
> > mesh networks by
> > > a
> > > > number of
> > > > people.  However, at the last IETF Kireeti and Vijay 
> > clearly indicated
> > > that
> > > > this work,
> > > > while interesting, wouldn't be allowed to progress in 
> advance of a
> > > > restoration requirements
> > > > draft from the TE group.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > > Sent: Thursday, May 24, 2001 11:55 AM
> > > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > There is a significant issue related to the absence of 
> > restoration in the
> > > > signaling draft
> > > >
> > > 
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt). Very specifically, Section 7 of this draft deals 
> > with the case
> > > > involving protection information for link protection. While link
> > > protection
> > > > schemes may be desirable for fast recovery related to 
> > high priority LSP's,
> > > > more cost-effective shared mesh restoration schemes would 
> > be preferred for
> > > > the majority of traffic from a Service Provider's 
> > perspective. This
> > > > observation is supported by the fact that many vendors 
> > are currently
> > > > developing proprietary schemes for shared mesh 
> > restoration. Hence, in
> > > > addition to the protection information, GMPLS signaling 
> > needs to reflect a
> > > > minimum set of information/attributes required for shared 
> > mesh restoration
> > > > without jeopardizing vendor proprietary solutions.
> > > >
> > > > The need for multiple types of restoration capabilities 
> > is well documented
> > > > in the OIF/UNI I-D
> > > >
> > > 
> > http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> > ework-uni-00.t
> > > > xt as follows:
> > > >
> > > > " Multiple types of facilities available for restoration 
> > are needed
> > > >    within the network. The following options should be 
> > considered for
> > > >    allocation of facilities to support restoration of failed
> > > >    connections:
> > > >    - Dedicated restoration capacity
> > > >    - Shared restoration capacity. This allows the network 
> > to ensure
> > > >      high quality service for customers, while still 
> managing its
> > > >      physical resources efficiently.
> > > >    - Un-restorable
> > > >    - Pre-emptable"
> > > >
> > > > The OIF/UNI I-D supports a range of different restoration 
> > schemes through
> > > > the use of service level as a connection attribute. This 
> > attribute is
> > > > defined as follows:
> > > >
> > > > " an integer attribute that indicates a class of service. 
> > A carrier may
> > > > specify a range of different classes of service (e.g. 
> > gold, silver,
> > > bronze)
> > > > with predefined characteristics (e.g. restoration plans). 
> > The pre-defined
> > > > service types correspond to different types of network 
> > restoration (e.g.
> > > no
> > > > restoration, 1+1 protection), connection set-up and hold 
> > priorities,
> > > > reversion strategies for the connection after failures 
> > have been repaired,
> > > > and retention strategies."
> > > >
> > > > It is therefore important that GMPLS be extended to be 
> > able to support
> > > such
> > > > restoration schemes.
> > > >
> > > > Percy S. Tarapore
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: Ash, Gerald R (Jerry)
> > > > Sent: Thursday, May 24, 2001 2:20 PM
> > > > To: [email-masked]; [email-masked]
> > > > Cc: Ash, Gerald R (Jerry)
> > > > Subject: RE: GMPLS Last Calls
> > > >
> > > > Quoting from the CCAMP/IETF-50 meeting minutes re the 
> > GMPLS Architecture
> > > > draft:
> > > >
> > > > "Eve - Had hoped that CCAMP formation and expression of 
> > requirements would
> > > > enable us to do more with architecture than reverse 
> > architect proposed
> > > > solution. Think we should also look at carrier 
> > requirements and look for
> > > > discrepancies with architecture.
> > > > Curtis - requirements of carriers not being addressed?
> > > > Eve - happy to discuss on mailing list in absence of time"
> > > >
> > > > There are still no documented service provider (SP) 
> > requirements driving
> > > the
> > > > proposed GMPLS protocol extensions.  This is inconsistent 
> > with the current
> > > > initiatives to provide SP requirements prior to protocol 
> > extensions being
> > > > accepted, such as for protection/restoration, network 
> > hierarchy, MPLS OAM,
> > > > MPLS/DiffServ TE, multi-area TE, etc.
> > > >
> > > > Here is a sample of SP requirements that are not being 
> > addressed (other
> > > > requirements from our perspective are forthcoming):
> > > >
> > > > 1. Restoration requirements, particularly in support of 
> > mesh restoration,
> > > > need to be supported by GMPLS.  For example, Section 7 of 
> > the Generalized
> > > > Signaling I-D
> > > >
> > > 
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> > ed-signaling-0
> > > > 4.txt)
> > > > primarily discusses link protection, restoration 
> > capabilities are largely
> > > > missing and need to be included.
> > > >
> > > > 2. Standards explicitly supported by GMPLS, such as 
> > G.707, G.709, etc.,
> > > > should be clearly identified in the text and referenced 
> > in the GMPLS I-Ds,
> > > > e.g., in Section 3.1 of the Generalized Signaling I-D, 
> add "G.707
> > > [Reference
> > > > G.707] is supported by the Generalized Label Request."
> > > >
> > > > As per Eve's comment at IETF-50, SPs are encouraged to 
> post their
> > > > requirements to the list.  It would also help if more SPs 
> > were invited to
> > > > co-author the GMPLS drafts, to help ensure that SP 
> > requirements are more
> > > > adequately reflected and addressed.
> > > >
> > > > Jerry Ash
> > > > AT&T Labs
> > > >
> > > > -----Original Message-----
> > > > From: George Swallow [mailto:[email-masked]]
> > > > Sent: Monday, May 14, 2001 1:52 PM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: GMPLS Last Calls
> > > >
> > > > This message initiates a last call on four GMPLS 
> drafts.  The last
> > > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > > >
> > > > The drafts are:
> > > >
> > > >     1.  Generalized MPLS - Signaling Functional Description
> > > >
> > > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > > >
> > > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > > >
> > > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > > >
> > > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > > >
> > > >     4.  GMPLS Extensions for SONET and SDH Control
> > > >
> > > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > > >
> > > > The last call closes May 29, 12 pm GMT.
> > > >
> > > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > > >
> > > > 
> > 
> ======================================================================
> > > > George Swallow       Cisco Systems                   
> > (978) 244-8143
> > > >                      250 Apollo Drive
> > > >                      Chelmsford, Ma 01824
> > 
> 

Delivery-date: Fri, 25 May 2001 14:18:58 -0700
From: Fong Liaw <[email-masked]>
To: 'suresh Katukam' <[email-masked]>, [email-masked]
Cc: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 14:16:39 -0700

Suresh/Vishal/Jen

>  -----Original Message-----
>  From: suresh Katukam [mailto:[email-masked]]
>  Sent: Friday, May 25, 2001 12:06 PM
>  To: [email-masked]
>  Cc: 'Jennifer Yates'; [email-masked]; [email-masked]
>  Subject: Re: Last call - RSVP problems
>  
>  
>  >
>  
>  Vishal and Jen,
>  
>  One possible solution is that -
>  There are multiple types of persistency of circuits can be provided
>  
>  1. Tear down a Circuit if a control channel fails
>  2. Tear down a Circuit only if a data path fails.
>  3. Tear down a Circuit only when a Source Node or Destination Node
>  deletes by sending explicit messages.
>  
>  I guess, (3) is what normally happens in today's networks. 
>  Only Network
>  administrator deletes circuits through TL1/EMS etc when 
>  there are problems.
>  
>  (1) is achieved naturally by RSVP refresh mechanisms.
>  
>  (2) is achieved when Refresh Timers are set to Infinite (No 
>  RSVP refreshes)
>  and indicate in RSVP message that tear down when a Data Path Fails.
>  

"Infinite timer" is actually very problematice with RSVP. 
We have specifically recommend NOT to use this, after attempting
to do it.

>  (3) is achieved when Refresh Timers are set to Infinite. By default,
>  circuit is kept irrespective of failures.
>

Same as (2), any proposals that remove the refresh mechanism 
is going to be difficult to prove that all cases are covered.

Instead, we (will) recommend the following in OIF UNI document:
   
   Use RSVP Hello to detect control channel failure. 
   If a control channel failure is detected, LSPs states 
   are maintained as if a node continues to receive 
   RSVP refresh message from the failed control channel.
   The recommended Hello timer will be in second range,
   instead of ms range specified in RSVP-TE draft.  

   If a control channel failed permanently, manual intervention 
   may be required. This is to be studied.

p.s The text is currently being drafted as we type.

Regards,
-Fong  

>  Ofcourse, (2) & (3) introduces some problems when the control channel
>  comes alive. How do two neighboring nodes sync up on what 
>  circuits are
>  still alive and what is gone? This is kind of addressed in 
>  ATM and we could
>  borrow ideas from there. If we all agree on above 
>  persistency levels or just
>  with (3), then I can provide information on how to sync up 
>  etc once nodes
>  come back alive.
>  
>  Thanks,
>  Suresh
>  
>  
>  
>  >
>  > > ****
>  > > Signaling channel failure:
>  > > If any element along the RSVP signaling path of an LSP 
>  fails, the RSVP
>  > > soft state timer in nodes downstream of the failure will 
>  timeout and the
>  > > nodes will delete the LSP, even if the forwarding plane is still
>  > > working! When GMPLS is used to control a transport network, this
>  > > scenario will occur, since the reliability of control 
>  planes is likely
>  > > quite a bit lower than the cross-connects themselves.  
>  In transport
>  > > networks, the data plane reliability expectations are 
>  very high, and any
>  > > factor that increases the already steep challenge of 
>  meeting those
>  > > expectations is not acceptable.
>  > >
>  > > One of the cardinal principles of transport network 
>  architecture is that
>  > > control plane failure must *not* cause the data plane to 
>  fail.  This
>  > > point has been raised and acknowledged at the OIF, but 
>  so far does not
>  > > seem to have been addressed in any of the GMPLS drafts.
>  > >
>  > > Jen
>  
>  

Delivery-date: Fri, 25 May 2001 14:18:58 -0700
From: Jonathan Lang <[email-masked]>
To: 'Jennifer Yates' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 14:13:40 -0700

Jennifer,
  Please see inline comments.

Thanks,
Jonathan

> -----Original Message-----
> From: Jennifer Yates [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 11:06 AM
> To: [email-masked]; [email-masked]
> Subject: Last call - RSVP problems
> 
> 
> A number of potentially major protocol problems have been identified
> within the OIF with the current signaling protocols (focusing 
> on RSVP).
> These problems arise in transport networks because the data plane is
> separate from the signaling plane.
> 
> I don't believe these issues have been addressed on the mailing list -
> if they have, please explain where.
> 
> ****
> Connection (LSP) teardown:
> There is a problem with connection deletion in the current RSVP draft.
> If a PathTear is sent in the forward direction (with say a
> unidirectional connection), the first node (cross-connect) will delete
> the connection and then forward the PathTear to the next cross-connect
> and so on.
> 
> Since loss of light will propagate faster than the PathTears, all
> downstream cross-connects will detect the loss of light and 
> alarm on it, possibly triggering restoration.  This is clearly 
> unacceptable behavior.

If LMP fault management is used, the "multiple alarming" behavior will be
avoided.

> 
> The right solution is that the deletion message in the forward direction
> should inform all of the nodes that the connection is being deleted, and
> the actual deletion should propagate in the *reverse* direction.
> Therefore, additional protocol extensions are needed to get the correct
> behavior on deletion.
> 
> This issue has been already been discussed within OIF documents e.g.,
> OIF2001.200 (RSVP Extensions in support of deletion confirmation and
> maintenance during failure), and in the ITU e.g., "Signal flows during
> exception cases". This issue does not appear to be reflected in the
> GMPLS documents presented for last call.

Please see the LMP document for a description of the fault management
procedure.

> 
> ****
> Signaling channel failure:
> If any element along the RSVP signaling path of an LSP fails, the RSVP
> soft state timer in nodes downstream of the failure will timeout and the
> nodes will delete the LSP, even if the forwarding plane is still
> working! When GMPLS is used to control a transport network, this
> scenario will occur, since the reliability of control planes is likely
> quite a bit lower than the cross-connects themselves.  In transport
> networks, the data plane reliability expectations are very 
> high, and any factor that increases the already steep challenge of meeting
those
> expectations is not acceptable.
> 
> One of the cardinal principles of transport network architecture is that
> control plane failure must *not* cause the data plane to fail.  This
> point has been raised and acknowledged at the OIF, but so far does not
> seem to have been addressed in any of the GMPLS drafts.

  According to rfc2205, the state's lifetime L must satisfy: L>=
(K+0.5)*1.5*R where K is an integer and R is the refresh timer.  My
suggestion to the OIF back in January in Tampa was to use L (or effectively
K*R) to get the operation you are looking for.  I believe this will satisfy
your requirement and does not require any changes to the signaling protocol.

> 
> Jen
> 

Delivery-date: Fri, 25 May 2001 13:35:03 -0700
From: "Tarapore, Percy S" <[email-masked]>
To: "'Bala Rajagopalan'" <[email-masked]>, "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Fri, 25 May 2001 16:34:02 -0400

Bala,

Are you suggesting that restoration signaling requirements be formulated in
a separate GMPLS draft at a later date? If so, the current draft should add
text regarding the current scope (link protection only) as well as future
work (restoration) in Section 7.

Percy

-----Original Message-----
From: Bala Rajagopalan [mailto:[email-masked]]
Sent: Friday, May 25, 2001 1:57 PM
To: 'C. R. Kalmanek'; John Drake
Cc: [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

Chuck:

I believe that the restoration issue can be
dealt with indepedent of the current drafts
on last call. Do you see any obstacles to
adding new objects/semantics (if any) to support
restoration requirements as they arise?

BTW, there are some drafts floating around
on shared mesh.

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 1:08 PM
> To: John Drake
> Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> 
> I fully agree: there are a whole spectrum of options that we
> need to sort through, and clear requirements are needed to
> guide that process.  Our concern is with the last call.  It
> doesn't make sense to progress drafts to RFC that are likely 
> in hindsight to be viewed as having serious deficiencies in
> meeting restoration requirements.
> 
> chuck
> 
> John Drake wrote:
> > 
> > The point is that in GMPLS, as in regular MPLS, restoration 
> consists of
> > rerouting from the endpoints upon
> > notification of failure.  There are a whole spectrum of 
> path and span
> > protection possibilites beyond this
> > that people (including us) have proposed, but in the absence of firm
> > requirements, it's hard to know which
> > to pursue.  I'm not sure 'shared mesh restoration' 
> completely covers it.
> > 
> > Thanks,
> > 
> > John
> > 
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 9:54 AM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> > 
> > John,
> > 
> > While there currently are no restoration requirements from the
> > TE (or other) group, what Percy is saying is that shared mesh
> > restoration WILL be a requirement from those groups.  Since the
> > current GMPLS drafts don't meet this requirement, they are
> > unlikely to meet key SP needs.
> > 
> > I don't understand a process that starts the requirements
> > development after last call for the signaling specifications.
> > 
> > chuck
> > 
> > John Drake wrote:
> > >
> > > Percy,
> > >
> > > There has been work on protocols for path restoration in 
> mesh networks by
> > a
> > > number of
> > > people.  However, at the last IETF Kireeti and Vijay 
> clearly indicated
> > that
> > > this work,
> > > while interesting, wouldn't be allowed to progress in advance of a
> > > restoration requirements
> > > draft from the TE group.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 11:55 AM
> > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > Subject: RE: GMPLS Last Calls
> > >
> > > There is a significant issue related to the absence of 
> restoration in the
> > > signaling draft
> > >
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> ed-signaling-0
> > > 4.txt). Very specifically, Section 7 of this draft deals 
> with the case
> > > involving protection information for link protection. While link
> > protection
> > > schemes may be desirable for fast recovery related to 
> high priority LSP's,
> > > more cost-effective shared mesh restoration schemes would 
> be preferred for
> > > the majority of traffic from a Service Provider's 
> perspective. This
> > > observation is supported by the fact that many vendors 
> are currently
> > > developing proprietary schemes for shared mesh 
> restoration. Hence, in
> > > addition to the protection information, GMPLS signaling 
> needs to reflect a
> > > minimum set of information/attributes required for shared 
> mesh restoration
> > > without jeopardizing vendor proprietary solutions.
> > >
> > > The need for multiple types of restoration capabilities 
> is well documented
> > > in the OIF/UNI I-D
> > >
> > 
> http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> ework-uni-00.t
> > > xt as follows:
> > >
> > > " Multiple types of facilities available for restoration 
> are needed
> > >    within the network. The following options should be 
> considered for
> > >    allocation of facilities to support restoration of failed
> > >    connections:
> > >    - Dedicated restoration capacity
> > >    - Shared restoration capacity. This allows the network 
> to ensure
> > >      high quality service for customers, while still managing its
> > >      physical resources efficiently.
> > >    - Un-restorable
> > >    - Pre-emptable"
> > >
> > > The OIF/UNI I-D supports a range of different restoration 
> schemes through
> > > the use of service level as a connection attribute. This 
> attribute is
> > > defined as follows:
> > >
> > > " an integer attribute that indicates a class of service. 
> A carrier may
> > > specify a range of different classes of service (e.g. 
> gold, silver,
> > bronze)
> > > with predefined characteristics (e.g. restoration plans). 
> The pre-defined
> > > service types correspond to different types of network 
> restoration (e.g.
> > no
> > > restoration, 1+1 protection), connection set-up and hold 
> priorities,
> > > reversion strategies for the connection after failures 
> have been repaired,
> > > and retention strategies."
> > >
> > > It is therefore important that GMPLS be extended to be 
> able to support
> > such
> > > restoration schemes.
> > >
> > > Percy S. Tarapore
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: Ash, Gerald R (Jerry)
> > > Sent: Thursday, May 24, 2001 2:20 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: Ash, Gerald R (Jerry)
> > > Subject: RE: GMPLS Last Calls
> > >
> > > Quoting from the CCAMP/IETF-50 meeting minutes re the 
> GMPLS Architecture
> > > draft:
> > >
> > > "Eve - Had hoped that CCAMP formation and expression of 
> requirements would
> > > enable us to do more with architecture than reverse 
> architect proposed
> > > solution. Think we should also look at carrier 
> requirements and look for
> > > discrepancies with architecture.
> > > Curtis - requirements of carriers not being addressed?
> > > Eve - happy to discuss on mailing list in absence of time"
> > >
> > > There are still no documented service provider (SP) 
> requirements driving
> > the
> > > proposed GMPLS protocol extensions.  This is inconsistent 
> with the current
> > > initiatives to provide SP requirements prior to protocol 
> extensions being
> > > accepted, such as for protection/restoration, network 
> hierarchy, MPLS OAM,
> > > MPLS/DiffServ TE, multi-area TE, etc.
> > >
> > > Here is a sample of SP requirements that are not being 
> addressed (other
> > > requirements from our perspective are forthcoming):
> > >
> > > 1. Restoration requirements, particularly in support of 
> mesh restoration,
> > > need to be supported by GMPLS.  For example, Section 7 of 
> the Generalized
> > > Signaling I-D
> > >
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> ed-signaling-0
> > > 4.txt)
> > > primarily discusses link protection, restoration 
> capabilities are largely
> > > missing and need to be included.
> > >
> > > 2. Standards explicitly supported by GMPLS, such as 
> G.707, G.709, etc.,
> > > should be clearly identified in the text and referenced 
> in the GMPLS I-Ds,
> > > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > [Reference
> > > G.707] is supported by the Generalized Label Request."
> > >
> > > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > > requirements to the list.  It would also help if more SPs 
> were invited to
> > > co-author the GMPLS drafts, to help ensure that SP 
> requirements are more
> > > adequately reflected and addressed.
> > >
> > > Jerry Ash
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: George Swallow [mailto:[email-masked]]
> > > Sent: Monday, May 14, 2001 1:52 PM
> > > To: [email-masked]; [email-masked]
> > > Subject: GMPLS Last Calls
> > >
> > > This message initiates a last call on four GMPLS drafts.  The last
> > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > >
> > > The drafts are:
> > >
> > >     1.  Generalized MPLS - Signaling Functional Description
> > >
> > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > >
> > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > >
> > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > >
> > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > >
> > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > >
> > >     4.  GMPLS Extensions for SONET and SDH Control
> > >
> > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > >
> > > The last call closes May 29, 12 pm GMT.
> > >
> > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > >
> > > 
> ======================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> 

Delivery-date: Fri, 25 May 2001 13:17:40 -0700
Date: Fri, 25 May 2001 16:20:21 -0700
From: Rob Coltun <[email-masked]>
To: John Drake <[email-masked]>
Cc: [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi John,
    valid question -  I don't think this is true for BGP. There are extensions
to BGP that the working group has adopted.
Which TE drafts are you referring to?

We've said from the beginning that we didn't want to define new "data plane"
functionality for technologies where the data plane is being defined elsewhere
- whereas some of the functions aren't really new, and in cases might be de-facto standard
we recognize that certain "data plane" functionality are beyond the scope
of the IETF to define - so this keeps us more in line with (in this case) the ITU.

Note that IETF has defined the
MPLS data plane - if some other body were to define new functionality
for the MPLS data plane it would certainly cause confusion in the industry.
This standard stuff is certainly not easy.

Is it really that big an issue to just keep them in a separate RFC?

thanks,
---rob

John Drake wrote:

> Rob,
>
> Why isn't the proposed disclaimer sufficient?  If you look in the base TE
> drafts, for example, there are codepoints defined for use by specific,
> named, vendors.  I think the same is also true for BGP.
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Rob Coltun [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 6:54 PM
> To: [email-masked]
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
>
> All,
>     despite the heated arguments I think the discussion is important to
> have.
>
> I suggest that instead of  tagging non/pre-standard items in the current
> drafts
> that they be put into a separate Informational document  - this is the
> cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary
> protocols
> but not as standard track documents.
>
> thanks,
> ---rob

Delivery-date: Fri, 25 May 2001 12:51:38 -0700
Date: Fri, 25 May 2001 21:50:04 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Zhi-Wei Lin <[email-masked]>
CC: "Lazer, Monica A, NNAD" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------84A4F29550A45C3D7C16B5B3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Zhi,

Still i don't understand why you want to upgrade all the 
boxes when using FACC since it is a Line/MS point-to-point
mechanism ? What's your argument here ? I can use it for
instance for specific LTE-to-LTE "links" within the network.
Do you agree ? And the Eric's explanations provide you the
requested inter-working function. What do you think about ?

- Dimitri

Zhi-Wei Lin wrote:
> 
> Either way, box upgrades are needed.
> 
> So, again looking at the differences:
> 
> Virtual concat            arbitrary concat
> * Any combo of timeslot   * Any combo of timeslot
> * Each timslot can go on  * All timeslot must go on
>   any # of fiber paths      the same fiber path
> * Only endpoints need     * All boxes need to be
>   to be upgraded            upgraded
> * For interworking with   * Since all boxes need to
>   contiguous concat, only   be upgraded, this is
>   interworking point need   already handled
>   to be upgraded
> * Is already defined in   * To support, there must be
>   standards                 detailed description of the
>                             process so that transport-level
>                             interworking is possible, not
>                             just signal interworking
> * Already has LCAS        * LCAS type capability not yet
>   defined to allow any      defined, but is also possible
>   increase or decrease
>   to timeslot to allow
>   growing and shrinking
>   bandwidth use without
>   disrupting traffic
> 
> Did I miss anything??  I like Rob's suggestion on how to handle the
> standard versus "non-standard" features.
> 
> Zhi
> 
> Dimitri Papadimitriou wrote:
> >
> > Hi,
> >
> > Then you will use the S4 function VC-4-Xc to VC-4-Xv defined in
> > G.783 (more precisely S4-Xc<->S4-Xv_I VC-4-Xc to VC-4-Xv concatenation
> > interworking function - see section 12.5.2) at one edge and the inverse
> > function at the other. However, the mechanisms are different in this
> > case you access the POH while in the mechanism described by Greg you
> > only use a function that converts VC-4-Xc to VC-4-Xa (FACC) you don't
> > access the POH.
> >
> > Hope this help to understand the key difference.
> >
> > - Dimitri.
> >
> > "Lazer, Monica A, NNAD" wrote:
> > >
> > > It is not at all clear to me that those 2 are the only choices. You can do
> > > virtual concatenation at the end-points of the valuable link if you want to
> > > avoid having end systems do that. This would be the standards-compliant
> > > variance of 2. Am I missing something?
> > >
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > [email-masked]
> > >
> > > -----Original Message-----
> > > From: Bernstein, Greg [mailto:[email-masked]]
> > > Sent: Thursday, May 17, 2001 12:27 PM
> > > To: 'Zhi-Wei Lin'
> > > Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> > > [email-masked]; [email-masked]; t1x1.5; q11/15
> > > Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
> > >
> > > To avoid re-grooming either virtual concatenation or arbitrary concatenation
> > > can help, but the implications are quite different.
> > > Say we have a particularly valuable (expensive) link that we can't or don't
> > > want to re-groom then we have two options:
> > > (1)     Require that ALL end systems that could potentially use this link
> > > convert over to virtual concatenation from standard concatenation.
> > > (2)     Or, install boxes at both ends of the link that support the
> > > arbitrary concatenation that we've been discussing.
> > >
> > > Which of these seems more realistic and practical?
> > > Greg B.
> > >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > >         New phone: (510) 573-2237
> > >
> > >                 -----Original Message-----
> > >                 From:   Zhi-Wei Lin [mailto:[email-masked]]
> > >                 Sent:   Thursday, May 17, 2001 8:41 AM
> > >                 To:     Bernstein, Greg
> > >                 Cc:     'Maarten Vissers'; Anup Tirumala;
> > > [email-masked]; [email-masked]; [email-masked];
> > > t1x1.5; q11/15
> > >                 Subject:        Re: [IP-Optical] concatenation extensions in
> > > sonet/sdh
> > >
> > >                 Hi,
> > >
> > >                 some observations:
> > >
> > >                 in terms of re-grooming and such, I believe both virtual
> > > concatenation
> > >                 and arbitrary concatenation can perform this. One method is
> > >                 standardized, the other is proprietary.
> > >
> > >                 In terms of routing of the individual connections that make
> > > up the
> > >                 concatenated signal, virtual concatenation is more flexible
> > > than
> > >                 arbitrary concatenation, since you can put each component VC
> > > in
> > >                 different lines, and each component can be routed
> > > differently.
> > >
> > >                 In terms of interworking, yes the SIGNALLING can defnititely
> > > be made to
> > >                 interwork. However, the larger issue for interworking is
> > > support by the
> > >                 transport equipment themselves. Thus interworking involves
> > > TWO parts:
> > >                 signaling interworking and transport interworking. Having
> > > one without
> > >                 the other doesn't really help...
> > >
> > >                 Thus, in terms of solving real problems, either virtual or
> > > arbitrary can
> > >                 accomplish that, but IMO, virtual seems more flexible...and
> > >                 standardized...
> > >
> > >                 In terms of standards as fostering interoperability and
> > > stifling of
> > >                 innovation, in principle yes I agree. And therefore if
> > > arbitrary
> > >                 concatenation should be standardized, it should be
> > > standardized in the
> > >                 correct standards body. As Maarten mentioned, the relevant
> > > standards
> > >                 bodies discussed arbitrary concatenation years ago, and
> > > decided
> > >                 (hopefully based on their expert technical opinion - I
> > > wasn't involved)
> > >                 not to include arbitrary but instead to include virtual.
> > > IMO, there must
> > >                 be good reasons, and from what I can tell, I see virtual as
> > > been more
> > >                 flexible so that is a pretty good reason...we at IETF, being
> > > protocol
> > >                 experts (and budding transport experts?) should not try to
> > > second-guess
> > >                 the decisions without fully understanding the
> > > ramifications...
> > >
> > >                 As for stifling innovation, anytime you standardize anything
> > > there is
> > >                 always some factor of development that gets fixed (is this
> > > something
> > >                 that should not be said in a public forum??? -- sorry!!).
> > > Therefore
> > >                 there is always a tradeoff between innovation and
> > > standardization. I
> > >                 think the job of standards bodies is to try to balance these
> > > two factors
> > >                 such that the industry in general can live with the result
> > > without
> > >                 unduly burdening...
> > >
> > >                 agree?
> > >
> > >                 Zhi
> > >
> > >                 "Bernstein, Greg" wrote:
> > >                 >
> > >                 > A couple more points.
> > >                 > (1)     GMPLS works well with arbitrary concatenations
> > > need to specify the
> > >                 > time slots since it provides a signaling protocol that can
> > > do just that,
> > >                 > i.e., GMPLS actually enables this feature to interoperate.
> > >                 > (2)     Arbitrary concatenation offers a solution to a
> > > real problem, i.e.,
> > >                 > eliminates the need for re-grooming on lines that support
> > > it.  For those who
> > >                 > have invested non-trivial amounts of money in transoceanic
> > > links this can be
> > >                 > a significant savings.
> > >                 > (3)     The goal is interoperability and to solve real
> > > problems.  We've got
> > >                 > a real problem and with a minor edit to the GMPLS SONET
> > > specification we can
> > >                 > have an interoperable method for solving it.
> > >                 >
> > >                 > To be precise in the definition of arbitrary
> > > concatenation:
> > >                 > As a concatenated signal within a single SONET Line (SDH
> > > MS), with
> > >                 > potentially arbitrary timeslots used for its components.
> > >                 >
> > >                 > The current main application is: avoiding the need for
> > > service impacting
> > >                 > re-grooming. Note that this applies to standard sized
> > > signals and is a per
> > >                 > link property.
> > >                 >
> > >                 > Other applications do exist and are somewhat competitive
> > > with non-LCAS
> > >                 > virtual concatenation since the implementation of
> > > arbitrary concatenation
> > >                 > for odd sized signals is simpler than that of virtual
> > > concatenation.  Once
> > >                 > "odd" sized signals are used an entire path through the
> > > network must exist
> > >                 > that supports them.
> > >                 >
> > >                 > Folks I thought the role of standards organizations was to
> > > foster
> > >                 > interoperability that enables the industry to move forward
> > > rather than as a
> > >                 > means to stifle innovation. I think it is better for the
> > > marketplace to
> > >                 > decide which features are desirable.
> > >                 >
> > >                 > Greg B.
> > >                 >
> > >                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > >                 >         New phone: (510) 573-2237
> > >                 >
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------84A4F29550A45C3D7C16B5B3
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------84A4F29550A45C3D7C16B5B3--

Delivery-date: Fri, 25 May 2001 12:46:11 -0700
Date: Fri, 25 May 2001 15:45:57 -0400
From: Jennifer Yates <[email-masked]>
To: suresh Katukam <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Last call - RSVP problems

Hi Suresh,

>
> Ofcourse, (2) & (3) introduces some problems when the control channel
> comes alive. How do two neighboring nodes sync up on what circuits are
> still alive and what is gone? This is kind of addressed in ATM and we could
> borrow ideas from there. If we all agree on above persistency levels or just
> with (3), then I can provide information on how to sync up etc once nodes
> come back alive.

Another option (as Guangzhi pointed out) is that the refresh still be used, but
state NOT removed on timeout. That way, the refreshes can be used for
re-synching the state, but we don't have the problem of connections being
erroneously removed. It may also have a nice side benefit that if we have a
connection that is not torn down completely when it should have been (ie., some
links still remain up, even though the user attempted to remove the connection),
then we can use out-of-band techniques (e.g., network operator) for tearing down
this state rather than having it sit around in the network forever. The
important point is that the connection is not torn down automatically on loss of
refreshes.

Other solutions are to have the refreshes tunneled around failed signaling
channels, or have nodes downstream of a failure detect the failure and then
generate the necessary refreshes to keep the connection alive. I am not fond of
either of these last two solutions.

Finally, we could introduce a new mechanism for the synching up of state after
signaling node failure.
Borrowing ideas from other technologies is always worth investigating.

I think that this issue needs to be solved before we can take these documents to
last call.

Jen

Delivery-date: Fri, 25 May 2001 12:32:07 -0700
Date: Fri, 25 May 2001 15:31:33 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: "Lazer, Monica A, NNAD" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

Either way, box upgrades are needed.

So, again looking at the differences:

Virtual concat            arbitrary concat
* Any combo of timeslot   * Any combo of timeslot
* Each timslot can go on  * All timeslot must go on  
  any # of fiber paths      the same fiber path
* Only endpoints need     * All boxes need to be
  to be upgraded            upgraded
* For interworking with   * Since all boxes need to
  contiguous concat, only   be upgraded, this is
  interworking point need   already handled
  to be upgraded
* Is already defined in   * To support, there must be
  standards                 detailed description of the
                            process so that transport-level
                            interworking is possible, not
                            just signal interworking
* Already has LCAS        * LCAS type capability not yet
  defined to allow any      defined, but is also possible
  increase or decrease
  to timeslot to allow
  growing and shrinking
  bandwidth use without
  disrupting traffic

Did I miss anything??  I like Rob's suggestion on how to handle the
standard versus "non-standard" features.

Zhi

Dimitri Papadimitriou wrote:
> 
> Hi,
> 
> Then you will use the S4 function VC-4-Xc to VC-4-Xv defined in
> G.783 (more precisely S4-Xc<->S4-Xv_I VC-4-Xc to VC-4-Xv concatenation
> interworking function - see section 12.5.2) at one edge and the inverse
> function at the other. However, the mechanisms are different in this
> case you access the POH while in the mechanism described by Greg you
> only use a function that converts VC-4-Xc to VC-4-Xa (FACC) you don't
> access the POH.
> 
> Hope this help to understand the key difference.
> 
> - Dimitri.
> 
> "Lazer, Monica A, NNAD" wrote:
> >
> > It is not at all clear to me that those 2 are the only choices. You can do
> > virtual concatenation at the end-points of the valuable link if you want to
> > avoid having end systems do that. This would be the standards-compliant
> > variance of 2. Am I missing something?
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2001 12:27 PM
> > To: 'Zhi-Wei Lin'
> > Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> > [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
> >
> > To avoid re-grooming either virtual concatenation or arbitrary concatenation
> > can help, but the implications are quite different.
> > Say we have a particularly valuable (expensive) link that we can't or don't
> > want to re-groom then we have two options:
> > (1)     Require that ALL end systems that could potentially use this link
> > convert over to virtual concatenation from standard concatenation.
> > (2)     Or, install boxes at both ends of the link that support the
> > arbitrary concatenation that we've been discussing.
> >
> > Which of these seems more realistic and practical?
> > Greg B.
> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >         New phone: (510) 573-2237
> >
> >                 -----Original Message-----
> >                 From:   Zhi-Wei Lin [mailto:[email-masked]]
> >                 Sent:   Thursday, May 17, 2001 8:41 AM
> >                 To:     Bernstein, Greg
> >                 Cc:     'Maarten Vissers'; Anup Tirumala;
> > [email-masked]; [email-masked]; [email-masked];
> > t1x1.5; q11/15
> >                 Subject:        Re: [IP-Optical] concatenation extensions in
> > sonet/sdh
> >
> >                 Hi,
> >
> >                 some observations:
> >
> >                 in terms of re-grooming and such, I believe both virtual
> > concatenation
> >                 and arbitrary concatenation can perform this. One method is
> >                 standardized, the other is proprietary.
> >
> >                 In terms of routing of the individual connections that make
> > up the
> >                 concatenated signal, virtual concatenation is more flexible
> > than
> >                 arbitrary concatenation, since you can put each component VC
> > in
> >                 different lines, and each component can be routed
> > differently.
> >
> >                 In terms of interworking, yes the SIGNALLING can defnititely
> > be made to
> >                 interwork. However, the larger issue for interworking is
> > support by the
> >                 transport equipment themselves. Thus interworking involves
> > TWO parts:
> >                 signaling interworking and transport interworking. Having
> > one without
> >                 the other doesn't really help...
> >
> >                 Thus, in terms of solving real problems, either virtual or
> > arbitrary can
> >                 accomplish that, but IMO, virtual seems more flexible...and
> >                 standardized...
> >
> >                 In terms of standards as fostering interoperability and
> > stifling of
> >                 innovation, in principle yes I agree. And therefore if
> > arbitrary
> >                 concatenation should be standardized, it should be
> > standardized in the
> >                 correct standards body. As Maarten mentioned, the relevant
> > standards
> >                 bodies discussed arbitrary concatenation years ago, and
> > decided
> >                 (hopefully based on their expert technical opinion - I
> > wasn't involved)
> >                 not to include arbitrary but instead to include virtual.
> > IMO, there must
> >                 be good reasons, and from what I can tell, I see virtual as
> > been more
> >                 flexible so that is a pretty good reason...we at IETF, being
> > protocol
> >                 experts (and budding transport experts?) should not try to
> > second-guess
> >                 the decisions without fully understanding the
> > ramifications...
> >
> >                 As for stifling innovation, anytime you standardize anything
> > there is
> >                 always some factor of development that gets fixed (is this
> > something
> >                 that should not be said in a public forum??? -- sorry!!).
> > Therefore
> >                 there is always a tradeoff between innovation and
> > standardization. I
> >                 think the job of standards bodies is to try to balance these
> > two factors
> >                 such that the industry in general can live with the result
> > without
> >                 unduly burdening...
> >
> >                 agree?
> >
> >                 Zhi
> >
> >                 "Bernstein, Greg" wrote:
> >                 >
> >                 > A couple more points.
> >                 > (1)     GMPLS works well with arbitrary concatenations
> > need to specify the
> >                 > time slots since it provides a signaling protocol that can
> > do just that,
> >                 > i.e., GMPLS actually enables this feature to interoperate.
> >                 > (2)     Arbitrary concatenation offers a solution to a
> > real problem, i.e.,
> >                 > eliminates the need for re-grooming on lines that support
> > it.  For those who
> >                 > have invested non-trivial amounts of money in transoceanic
> > links this can be
> >                 > a significant savings.
> >                 > (3)     The goal is interoperability and to solve real
> > problems.  We've got
> >                 > a real problem and with a minor edit to the GMPLS SONET
> > specification we can
> >                 > have an interoperable method for solving it.
> >                 >
> >                 > To be precise in the definition of arbitrary
> > concatenation:
> >                 > As a concatenated signal within a single SONET Line (SDH
> > MS), with
> >                 > potentially arbitrary timeslots used for its components.
> >                 >
> >                 > The current main application is: avoiding the need for
> > service impacting
> >                 > re-grooming. Note that this applies to standard sized
> > signals and is a per
> >                 > link property.
> >                 >
> >                 > Other applications do exist and are somewhat competitive
> > with non-LCAS
> >                 > virtual concatenation since the implementation of
> > arbitrary concatenation
> >                 > for odd sized signals is simpler than that of virtual
> > concatenation.  Once
> >                 > "odd" sized signals are used an entire path through the
> > network must exist
> >                 > that supports them.
> >                 >
> >                 > Folks I thought the role of standards organizations was to
> > foster
> >                 > interoperability that enables the industry to move forward
> > rather than as a
> >                 > means to stifle innovation. I think it is better for the
> > marketplace to
> >                 > decide which features are desirable.
> >                 >
> >                 > Greg B.
> >                 >
> >                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >                 >         New phone: (510) 573-2237
> >                 >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Fri, 25 May 2001 12:02:33 -0700
Date: Fri, 25 May 2001 12:05:53 -0700
From: suresh Katukam <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: "'Jennifer Yates'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Last call - RSVP problems

>

Vishal and Jen,

One possible solution is that -
There are multiple types of persistency of circuits can be provided

1. Tear down a Circuit if a control channel fails
2. Tear down a Circuit only if a data path fails.
3. Tear down a Circuit only when a Source Node or Destination Node
deletes by sending explicit messages.

I guess, (3) is what normally happens in today's networks. Only Network
administrator deletes circuits through TL1/EMS etc when there are problems.

(1) is achieved naturally by RSVP refresh mechanisms.

(2) is achieved when Refresh Timers are set to Infinite (No RSVP refreshes)
and indicate in RSVP message that tear down when a Data Path Fails.

(3) is achieved when Refresh Timers are set to Infinite. By default,
circuit is kept irrespective of failures.

Ofcourse, (2) & (3) introduces some problems when the control channel
comes alive. How do two neighboring nodes sync up on what circuits are
still alive and what is gone? This is kind of addressed in ATM and we could
borrow ideas from there. If we all agree on above persistency levels or just
with (3), then I can provide information on how to sync up etc once nodes
come back alive.

Thanks,
Suresh

>
> > ****
> > Signaling channel failure:
> > If any element along the RSVP signaling path of an LSP fails, the RSVP
> > soft state timer in nodes downstream of the failure will timeout and the
> > nodes will delete the LSP, even if the forwarding plane is still
> > working! When GMPLS is used to control a transport network, this
> > scenario will occur, since the reliability of control planes is likely
> > quite a bit lower than the cross-connects themselves.  In transport
> > networks, the data plane reliability expectations are very high, and any
> > factor that increases the already steep challenge of meeting those
> > expectations is not acceptable.
> >
> > One of the cardinal principles of transport network architecture is that
> > control plane failure must *not* cause the data plane to fail.  This
> > point has been raised and acknowledged at the OIF, but so far does not
> > seem to have been addressed in any of the GMPLS drafts.
> >
> > Jen

Delivery-date: Fri, 25 May 2001 11:50:27 -0700
Date: Fri, 25 May 2001 20:47:55 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Jennifer Yates <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Last call - RSVP problems

This is a multi-part message in MIME format.
--------------FD8AFAC5ADBCC1426845D3AE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jennifer,

At that i didn't raise this question but today it seems we
don't have a LoL propagation (except in all-optical networks)
so i was surprised that this question raised at the OIF
since dealing with SDH/Sonet UNI. So in most cases today 
"PathTear" is a link-by-link deletion process the LoL won't
propagate faster than the PathTear since you can now control
the signal deletion at each hop. Am i right ?

Notice this does not preclude to generalize the process as
proposed in your suggestion.

- Dimitri.

Jennifer Yates wrote:
> 
> A number of potentially major protocol problems have been identified
> within the OIF with the current signaling protocols (focusing on RSVP).
> These problems arise in transport networks because the data plane is
> separate from the signaling plane.
> 
> I don't believe these issues have been addressed on the mailing list -
> if they have, please explain where.
> 
> ****
> Connection (LSP) teardown:
> There is a problem with connection deletion in the current RSVP draft.
> If a PathTear is sent in the forward direction (with say a
> unidirectional connection), the first node (cross-connect) will delete
> the connection and then forward the PathTear to the next cross-connect
> and so on.
> 
> Since loss of light will propagate faster than the PathTears, all
> downstream cross-connects will detect the loss of light and alarm on it,
> possibly triggering restoration.  This is clearly unacceptable behavior.
> 
> The right solution is that the deletion message in the forward direction
> should inform all of the nodes that the connection is being deleted, and
> the actual deletion should propagate in the *reverse* direction.
> Therefore, additional protocol extensions are needed to get the correct
> behavior on deletion.
> 
> This issue has been already been discussed within OIF documents e.g.,
> OIF2001.200 (RSVP Extensions in support of deletion confirmation and
> maintenance during failure), and in the ITU e.g., "Signal flows during
> exception cases". This issue does not appear to be reflected in the
> GMPLS documents presented for last call.
> 
> ****
> Signaling channel failure:
> If any element along the RSVP signaling path of an LSP fails, the RSVP
> soft state timer in nodes downstream of the failure will timeout and the
> nodes will delete the LSP, even if the forwarding plane is still
> working! When GMPLS is used to control a transport network, this
> scenario will occur, since the reliability of control planes is likely
> quite a bit lower than the cross-connects themselves.  In transport
> networks, the data plane reliability expectations are very high, and any
> factor that increases the already steep challenge of meeting those
> expectations is not acceptable.
> 
> One of the cardinal principles of transport network architecture is that
> control plane failure must *not* cause the data plane to fail.  This
> point has been raised and acknowledged at the OIF, but so far does not
> seem to have been addressed in any of the GMPLS drafts.
> 
> Jen
--------------FD8AFAC5ADBCC1426845D3AE
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------FD8AFAC5ADBCC1426845D3AE--

Delivery-date: Fri, 25 May 2001 11:45:05 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Jennifer Yates'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Last call - RSVP problems
Date: Fri, 25 May 2001 12:00:19 -0700

Jen,

Your points are well taken. My question is: will the carriers be willing to
provide some suggested solutions to both these problems, particularly
the second one.
Perhaps having corresponding IETF documents addressing these
problems and their possible solutions would help to move the
discussion forward.

-Vishal

On Friday, May 25, 2001 11:06 AM, Jennifer Yates [SMTP:[email-masked]] 
wrote:
> A number of potentially major protocol problems have been identified
> within the OIF with the current signaling protocols (focusing on RSVP).
> These problems arise in transport networks because the data plane is
> separate from the signaling plane.
>
> I don't believe these issues have been addressed on the mailing list -
> if they have, please explain where.
>
> ****
> Connection (LSP) teardown:
> There is a problem with connection deletion in the current RSVP draft.
> If a PathTear is sent in the forward direction (with say a
> unidirectional connection), the first node (cross-connect) will delete
> the connection and then forward the PathTear to the next cross-connect
> and so on.
>
> Since loss of light will propagate faster than the PathTears, all
> downstream cross-connects will detect the loss of light and alarm on it,
> possibly triggering restoration.  This is clearly unacceptable behavior.
>
> The right solution is that the deletion message in the forward direction
> should inform all of the nodes that the connection is being deleted, and
> the actual deletion should propagate in the *reverse* direction.
> Therefore, additional protocol extensions are needed to get the correct
> behavior on deletion.
>
> This issue has been already been discussed within OIF documents e.g.,
> OIF2001.200 (RSVP Extensions in support of deletion confirmation and
> maintenance during failure), and in the ITU e.g., "Signal flows during
> exception cases". This issue does not appear to be reflected in the
> GMPLS documents presented for last call.
>
> ****
> Signaling channel failure:
> If any element along the RSVP signaling path of an LSP fails, the RSVP
> soft state timer in nodes downstream of the failure will timeout and the
> nodes will delete the LSP, even if the forwarding plane is still
> working! When GMPLS is used to control a transport network, this
> scenario will occur, since the reliability of control planes is likely
> quite a bit lower than the cross-connects themselves.  In transport
> networks, the data plane reliability expectations are very high, and any
> factor that increases the already steep challenge of meeting those
> expectations is not acceptable.
>
> One of the cardinal principles of transport network architecture is that
> control plane failure must *not* cause the data plane to fail.  This
> point has been raised and acknowledged at the OIF, but so far does not
> seem to have been addressed in any of the GMPLS drafts.
>
> Jen

Delivery-date: Fri, 25 May 2001 11:44:26 -0700
Date: Fri, 25 May 2001 14:36:19 -0400
From: Jennifer Yates <[email-masked]>
To: [email-masked]
Subject: Last call - RSVP problems

A number of potentially major protocol problems have been identified
within the OIF with the current signaling protocols (focusing on RSVP).
These problems arise in transport networks because the data plane is
separate from the signaling plane.

I don't believe these issues have been addressed on the mailing list -
if they have, please explain where.

****
Connection (LSP) teardown:
There is a problem with connection deletion in the current RSVP draft.
If a PathTear is sent in the forward direction (with say a
unidirectional connection), the first node (cross-connect) will delete
the connection and then forward the PathTear to the next cross-connect
and so on.

Since loss of light will propagate faster than the PathTears, all
downstream cross-connects will detect the loss of light and alarm on it,
possibly triggering restoration.  This is clearly unacceptable behavior.

The right solution is that the deletion message in the forward direction
should inform all of the nodes that the connection is being deleted, and
the actual deletion should propagate in the *reverse* direction.
Therefore, additional protocol extensions are needed to get the correct
behavior on deletion.

This issue has been already been discussed within OIF documents e.g.,
OIF2001.200 (RSVP Extensions in support of deletion confirmation and
maintenance during failure), and in the ITU e.g., "Signal flows during
exception cases". This issue does not appear to be reflected in the
GMPLS documents presented for last call.

****
Signaling channel failure:
If any element along the RSVP signaling path of an LSP fails, the RSVP
soft state timer in nodes downstream of the failure will timeout and the
nodes will delete the LSP, even if the forwarding plane is still
working! When GMPLS is used to control a transport network, this
scenario will occur, since the reliability of control planes is likely
quite a bit lower than the cross-connects themselves.  In transport
networks, the data plane reliability expectations are very high, and any
factor that increases the already steep challenge of meeting those
expectations is not acceptable.

One of the cardinal principles of transport network architecture is that
control plane failure must *not* cause the data plane to fail.  This
point has been raised and acknowledged at the OIF, but so far does not
seem to have been addressed in any of the GMPLS drafts.

Jen

Delivery-date: Fri, 25 May 2001 11:16:40 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: GMPLS Last Calls: Comments on restoration requirements
Date: Fri, 25 May 2001 11:38:33 -0700

Chuck,

In response to restoration and survivability requirements, I would like to 
point
out that a framework for MPLS recovery is an MPLS WG document (and
has been for some time now; in fact, after we submit the final revision in
the next week or so, based on feedback we received after the last IETF, it
should go to last call as per the decision of the ADs at the last IETF).

http://search.ietf.org/internet-drafts/draft-ietf-mpls-recovery-frmwrk-02.txt

Also, at the last  IETF, there was support for this document being a  good
starting point for the generation of more general restoration requirements
by the TE WG.

FYI, about a year ago, we had submitted a draft to the TE WG
titled
"Network survivability considerations for traffic engineered IP networks,"
draft-owens-te-network-survivability-00.txt,
which was ahead of its times, and the TE WG was not ready
for it then. The abstract for the draft reads:

"Network survivability refers to the capability of the network to
maintain service continuity in the presence of faults within the
network [1]. This can be accomplished by recovering from network
failures quickly and maintaining the required QoS for existing
services. With the increasing sophistication of network technologies,
survivability capabilities are becoming available at multiple layers,
allowing for protection and restoration to occur at any layer of the
network. This makes it important to: scrutinize the recovery features
of different network layers, understand the pros and cons of performing
recovery at each layer, and assess how the interactions between layers
impact network survivability. With these objectives in mind, this draft
examines the considerations for network survivability at different
layers of the network."

The initial version was an attempt to hightlight all the issues, and an
overview, but it has since expired. Perhaps now
is a good time to resurrect it.

We would be happy to collaborate with any carriers that are interested
in progressing these requirements (in addition to Williams) within the
IETF.

Thanks,

-Vishal

On Friday, May 25, 2001 9:54 AM, C. R. Kalmanek [SMTP:[email-masked]] 
wrote:
> John,
>
> While there currently are no restoration requirements from the
> TE (or other) group, what Percy is saying is that shared mesh
> restoration WILL be a requirement from those groups.  Since the
> current GMPLS drafts don't meet this requirement, they are
> unlikely to meet key SP needs.
>
> I don't understand a process that starts the requirements
> development after last call for the signaling specifications.
>
> chuck
>
> John Drake wrote:
> >
> > Percy,
> >
> > There has been work on protocols for path restoration in mesh networks by a
> > number of
> > people.  However, at the last IETF Kireeti and Vijay clearly indicated that
> > this work,
> > while interesting, wouldn't be allowed to progress in advance of a
> > restoration requirements
> > draft from the TE group.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 11:55 AM
> > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> > There is a significant issue related to the absence of restoration in the
> > signaling draft
> > 
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> >
> > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > involving protection information for link protection. While link protection
> > schemes may be desirable for fast recovery related to high priority LSP's,
> > more cost-effective shared mesh restoration schemes would be preferred for
> > the majority of traffic from a Service Provider's perspective. This
> > observation is supported by the fact that many vendors are currently
> > developing proprietary schemes for shared mesh restoration. Hence, in
> > addition to the protection information, GMPLS signaling needs to reflect a
> > minimum set of information/attributes required for shared mesh restoration
> > without jeopardizing vendor proprietary solutions.
> >
> > The need for multiple types of restoration capabilities is well documented
> > in the OIF/UNI I-D
> > http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-
> > 00.t
> > xt as follows:
> >
> > " Multiple types of facilities available for restoration are needed
> >    within the network. The following options should be considered for
> >    allocation of facilities to support restoration of failed
> >    connections:
> >    - Dedicated restoration capacity
> >    - Shared restoration capacity. This allows the network to ensure
> >      high quality service for customers, while still managing its
> >      physical resources efficiently.
> >    - Un-restorable
> >    - Pre-emptable"
> >
> > The OIF/UNI I-D supports a range of different restoration schemes through
> > the use of service level as a connection attribute. This attribute is
> > defined as follows:
> >
> > " an integer attribute that indicates a class of service. A carrier may
> > specify a range of different classes of service (e.g. gold, silver, bronze)
> > with predefined characteristics (e.g. restoration plans). The pre-defined
> > service types correspond to different types of network restoration (e.g. no
> > restoration, 1+1 protection), connection set-up and hold priorities,
> > reversion strategies for the connection after failures have been repaired,
> > and retention strategies."
> >
> > It is therefore important that GMPLS be extended to be able to support such
> > restoration schemes.
> >
> > Percy S. Tarapore
> > AT&T Labs
> >
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry)
> > Sent: Thursday, May 24, 2001 2:20 PM
> > To: [email-masked]; [email-masked]
> > Cc: Ash, Gerald R (Jerry)
> > Subject: RE: GMPLS Last Calls
> >
> > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > draft:
> >
> > "Eve - Had hoped that CCAMP formation and expression of requirements would
> > enable us to do more with architecture than reverse architect proposed
> > solution. Think we should also look at carrier requirements and look for
> > discrepancies with architecture.
> > Curtis - requirements of carriers not being addressed?
> > Eve - happy to discuss on mailing list in absence of time"
> >
> > There are still no documented service provider (SP) requirements driving
> > the
> > proposed GMPLS protocol extensions.  This is inconsistent with the current
> > initiatives to provide SP requirements prior to protocol extensions being
> > accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> > MPLS/DiffServ TE, multi-area TE, etc.
> >
> > Here is a sample of SP requirements that are not being addressed (other
> > requirements from our perspective are forthcoming):
> >
> > 1. Restoration requirements, particularly in support of mesh restoration,
> > need to be supported by GMPLS.  For example, Section 7 of the Generalized
> > Signaling I-D
> > 
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> >
> > 4.txt)
> > primarily discusses link protection, restoration capabilities are largely
> > missing and need to be included.
> >
> > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > should be clearly identified in the text and referenced in the GMPLS I-Ds,
> > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > [Reference
> > G.707] is supported by the Generalized Label Request."
> >
> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
> >
> > Jerry Ash
> > AT&T Labs
> >
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: Monday, May 14, 2001 1:52 PM
> > To: [email-masked]; [email-masked]
> > Subject: GMPLS Last Calls
> >
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> >
> > The drafts are:
> >
> >     1.  Generalized MPLS - Signaling Functional Description
> >
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> >
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> >
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> >
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> >
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> >
> >     4.  GMPLS Extensions for SONET and SDH Control
> >
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> >
> > The last call closes May 29, 12 pm GMT.
> >
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824

Delivery-date: Fri, 25 May 2001 11:00:52 -0700
Date: Fri, 25 May 2001 13:56:09 -0400
From: "C. R. Kalmanek" <[email-masked]>
To: Dimitri Papadimitriou <[email-masked]>
Cc: John Drake <[email-masked]>, "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

Hi, Dimitri,

I agree with the IAB direction on this.  We're also familiar 
with all of the proposals that you mention and believe that 
there are some things missing.  In any event, as I'm sure you 
would agree, without requirements it would be hard to say with
confidence that the current GMPLS specs can be readily extended
to meet the (non-existent) requirements :).

chuck

Dimitri Papadimitriou wrote:
> 
> Hi all,
> 
> From that point of view it is clear that during the last IETF meeting
> and if i am not making a mistake there were at least 3 presentations
> from that aspect (as John mentioned) these edge-to-edge restoration
> mechanisms are based either on extending current notification and
> signalling mechanisms (here signalling protocols are the same than
> those used to provision or establish the LSPs) or using a specific
> signalling protocol different from the one used to provision or setup
> these LSPs. Notice as well that link restoration (and not only
> protection) could be also discussed from that perspective.
> 
> Notice that IETF AB have asked us to wait upon the TE WG requirements
> on "network survivability" prior to continue to propose technical
> solutions. I agree with John that with the current status it is rather
> difficult to know if (even partially) which direction to pursue.
> 
> Regards,
> - Dimitri.
> 
> John Drake wrote:
> >
> > The point is that in GMPLS, as in regular MPLS, restoration consists of
> > rerouting from the endpoints upon
> > notification of failure.  There are a whole spectrum of path and span
> > protection possibilites beyond this
> > that people (including us) have proposed, but in the absence of firm
> > requirements, it's hard to know which
> > to pursue.  I'm not sure 'shared mesh restoration' completely covers it.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 9:54 AM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> >
> > John,
> >
> > While there currently are no restoration requirements from the
> > TE (or other) group, what Percy is saying is that shared mesh
> > restoration WILL be a requirement from those groups.  Since the
> > current GMPLS drafts don't meet this requirement, they are
> > unlikely to meet key SP needs.
> >
> > I don't understand a process that starts the requirements
> > development after last call for the signaling specifications.
> >
> > chuck
> >
> > John Drake wrote:
> > >
> > > Percy,
> > >
> > > There has been work on protocols for path restoration in mesh networks by
> > a
> > > number of
> > > people.  However, at the last IETF Kireeti and Vijay clearly indicated
> > that
> > > this work,
> > > while interesting, wouldn't be allowed to progress in advance of a
> > > restoration requirements
> > > draft from the TE group.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 11:55 AM
> > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > Subject: RE: GMPLS Last Calls
> > >
> > > There is a significant issue related to the absence of restoration in the
> > > signaling draft
> > >
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > > involving protection information for link protection. While link
> > protection
> > > schemes may be desirable for fast recovery related to high priority LSP's,
> > > more cost-effective shared mesh restoration schemes would be preferred for
> > > the majority of traffic from a Service Provider's perspective. This
> > > observation is supported by the fact that many vendors are currently
> > > developing proprietary schemes for shared mesh restoration. Hence, in
> > > addition to the protection information, GMPLS signaling needs to reflect a
> > > minimum set of information/attributes required for shared mesh restoration
> > > without jeopardizing vendor proprietary solutions.
> > >
> > > The need for multiple types of restoration capabilities is well documented
> > > in the OIF/UNI I-D
> > >
> > http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> > > xt as follows:
> > >
> > > " Multiple types of facilities available for restoration are needed
> > >    within the network. The following options should be considered for
> > >    allocation of facilities to support restoration of failed
> > >    connections:
> > >    - Dedicated restoration capacity
> > >    - Shared restoration capacity. This allows the network to ensure
> > >      high quality service for customers, while still managing its
> > >      physical resources efficiently.
> > >    - Un-restorable
> > >    - Pre-emptable"
> > >
> > > The OIF/UNI I-D supports a range of different restoration schemes through
> > > the use of service level as a connection attribute. This attribute is
> > > defined as follows:
> > >
> > > " an integer attribute that indicates a class of service. A carrier may
> > > specify a range of different classes of service (e.g. gold, silver,
> > bronze)
> > > with predefined characteristics (e.g. restoration plans). The pre-defined
> > > service types correspond to different types of network restoration (e.g.
> > no
> > > restoration, 1+1 protection), connection set-up and hold priorities,
> > > reversion strategies for the connection after failures have been repaired,
> > > and retention strategies."
> > >
> > > It is therefore important that GMPLS be extended to be able to support
> > such
> > > restoration schemes.
> > >
> > > Percy S. Tarapore
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: Ash, Gerald R (Jerry)
> > > Sent: Thursday, May 24, 2001 2:20 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: Ash, Gerald R (Jerry)
> > > Subject: RE: GMPLS Last Calls
> > >
> > > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > > draft:
> > >
> > > "Eve - Had hoped that CCAMP formation and expression of requirements would
> > > enable us to do more with architecture than reverse architect proposed
> > > solution. Think we should also look at carrier requirements and look for
> > > discrepancies with architecture.
> > > Curtis - requirements of carriers not being addressed?
> > > Eve - happy to discuss on mailing list in absence of time"
> > >
> > > There are still no documented service provider (SP) requirements driving
> > the
> > > proposed GMPLS protocol extensions.  This is inconsistent with the current
> > > initiatives to provide SP requirements prior to protocol extensions being
> > > accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> > > MPLS/DiffServ TE, multi-area TE, etc.
> > >
> > > Here is a sample of SP requirements that are not being addressed (other
> > > requirements from our perspective are forthcoming):
> > >
> > > 1. Restoration requirements, particularly in support of mesh restoration,
> > > need to be supported by GMPLS.  For example, Section 7 of the Generalized
> > > Signaling I-D
> > >
> > (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > > 4.txt)
> > > primarily discusses link protection, restoration capabilities are largely
> > > missing and need to be included.
> > >
> > > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > > should be clearly identified in the text and referenced in the GMPLS I-Ds,
> > > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > [Reference
> > > G.707] is supported by the Generalized Label Request."
> > >
> > > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > > requirements to the list.  It would also help if more SPs were invited to
> > > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > > adequately reflected and addressed.
> > >
> > > Jerry Ash
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: George Swallow [mailto:[email-masked]]
> > > Sent: Monday, May 14, 2001 1:52 PM
> > > To: [email-masked]; [email-masked]
> > > Subject: GMPLS Last Calls
> > >
> > > This message initiates a last call on four GMPLS drafts.  The last
> > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > >
> > > The drafts are:
> > >
> > >     1.  Generalized MPLS - Signaling Functional Description
> > >
> > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > >
> > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > >
> > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > >
> > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > >
> > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > >
> > >     4.  GMPLS Extensions for SONET and SDH Control
> > >
> > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > >
> > > The last call closes May 29, 12 pm GMT.
> > >
> > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > >
> > > ======================================================================
> > > George Swallow       Cisco Systems                   (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824

Delivery-date: Fri, 25 May 2001 11:00:18 -0700
Date: Fri, 25 May 2001 19:55:11 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Lazer, Monica A, NNAD" <[email-masked]>
CC: "'Bernstein, Greg'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------72291D6177CFE37BE4447EE8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Then you will use the S4 function VC-4-Xc to VC-4-Xv defined in
G.783 (more precisely S4-Xc<->S4-Xv_I VC-4-Xc to VC-4-Xv concatenation
interworking function - see section 12.5.2) at one edge and the inverse
function at the other. However, the mechanisms are different in this 
case you access the POH while in the mechanism described by Greg you 
only use a function that converts VC-4-Xc to VC-4-Xa (FACC) you don't
access the POH.

Hope this help to understand the key difference.

- Dimitri.

"Lazer, Monica A, NNAD" wrote:
> 
> It is not at all clear to me that those 2 are the only choices. You can do
> virtual concatenation at the end-points of the valuable link if you want to
> avoid having end systems do that. This would be the standards-compliant
> variance of 2. Am I missing something?
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 12:27 PM
> To: 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh
> 
> To avoid re-grooming either virtual concatenation or arbitrary concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we can't or don't
> want to re-groom then we have two options:
> (1)     Require that ALL end systems that could potentially use this link
> convert over to virtual concatenation from standard concatenation.
> (2)     Or, install boxes at both ends of the link that support the
> arbitrary concatenation that we've been discussing.
> 
> Which of these seems more realistic and practical?
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Zhi-Wei Lin [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 To:     Bernstein, Greg
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        Re: [IP-Optical] concatenation extensions in
> sonet/sdh
> 
>                 Hi,
> 
>                 some observations:
> 
>                 in terms of re-grooming and such, I believe both virtual
> concatenation
>                 and arbitrary concatenation can perform this. One method is
>                 standardized, the other is proprietary.
> 
>                 In terms of routing of the individual connections that make
> up the
>                 concatenated signal, virtual concatenation is more flexible
> than
>                 arbitrary concatenation, since you can put each component VC
> in
>                 different lines, and each component can be routed
> differently.
> 
>                 In terms of interworking, yes the SIGNALLING can defnititely
> be made to
>                 interwork. However, the larger issue for interworking is
> support by the
>                 transport equipment themselves. Thus interworking involves
> TWO parts:
>                 signaling interworking and transport interworking. Having
> one without
>                 the other doesn't really help...
> 
>                 Thus, in terms of solving real problems, either virtual or
> arbitrary can
>                 accomplish that, but IMO, virtual seems more flexible...and
>                 standardized...
> 
>                 In terms of standards as fostering interoperability and
> stifling of
>                 innovation, in principle yes I agree. And therefore if
> arbitrary
>                 concatenation should be standardized, it should be
> standardized in the
>                 correct standards body. As Maarten mentioned, the relevant
> standards
>                 bodies discussed arbitrary concatenation years ago, and
> decided
>                 (hopefully based on their expert technical opinion - I
> wasn't involved)
>                 not to include arbitrary but instead to include virtual.
> IMO, there must
>                 be good reasons, and from what I can tell, I see virtual as
> been more
>                 flexible so that is a pretty good reason...we at IETF, being
> protocol
>                 experts (and budding transport experts?) should not try to
> second-guess
>                 the decisions without fully understanding the
> ramifications...
> 
>                 As for stifling innovation, anytime you standardize anything
> there is
>                 always some factor of development that gets fixed (is this
> something
>                 that should not be said in a public forum??? -- sorry!!).
> Therefore
>                 there is always a tradeoff between innovation and
> standardization. I
>                 think the job of standards bodies is to try to balance these
> two factors
>                 such that the industry in general can live with the result
> without
>                 unduly burdening...
> 
>                 agree?
> 
>                 Zhi
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > A couple more points.
>                 > (1)     GMPLS works well with arbitrary concatenations
> need to specify the
>                 > time slots since it provides a signaling protocol that can
> do just that,
>                 > i.e., GMPLS actually enables this feature to interoperate.
>                 > (2)     Arbitrary concatenation offers a solution to a
> real problem, i.e.,
>                 > eliminates the need for re-grooming on lines that support
> it.  For those who
>                 > have invested non-trivial amounts of money in transoceanic
> links this can be
>                 > a significant savings.
>                 > (3)     The goal is interoperability and to solve real
> problems.  We've got
>                 > a real problem and with a minor edit to the GMPLS SONET
> specification we can
>                 > have an interoperable method for solving it.
>                 >
>                 > To be precise in the definition of arbitrary
> concatenation:
>                 > As a concatenated signal within a single SONET Line (SDH
> MS), with
>                 > potentially arbitrary timeslots used for its components.
>                 >
>                 > The current main application is: avoiding the need for
> service impacting
>                 > re-grooming. Note that this applies to standard sized
> signals and is a per
>                 > link property.
>                 >
>                 > Other applications do exist and are somewhat competitive
> with non-LCAS
>                 > virtual concatenation since the implementation of
> arbitrary concatenation
>                 > for odd sized signals is simpler than that of virtual
> concatenation.  Once
>                 > "odd" sized signals are used an entire path through the
> network must exist
>                 > that supports them.
>                 >
>                 > Folks I thought the role of standards organizations was to
> foster
>                 > interoperability that enables the industry to move forward
> rather than as a
>                 > means to stifle innovation. I think it is better for the
> marketplace to
>                 > decide which features are desirable.
>                 >
>                 > Greg B.
>                 >
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------72291D6177CFE37BE4447EE8
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------72291D6177CFE37BE4447EE8--

Delivery-date: Fri, 25 May 2001 10:59:31 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Fri, 25 May 2001 13:56:53 -0400

Chuck:

I believe that the restoration issue can be
dealt with indepedent of the current drafts
on last call. Do you see any obstacles to
adding new objects/semantics (if any) to support
restoration requirements as they arise?

BTW, there are some drafts floating around
on shared mesh.

regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 1:08 PM
> To: John Drake
> Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> 
> I fully agree: there are a whole spectrum of options that we
> need to sort through, and clear requirements are needed to
> guide that process.  Our concern is with the last call.  It
> doesn't make sense to progress drafts to RFC that are likely 
> in hindsight to be viewed as having serious deficiencies in
> meeting restoration requirements.
> 
> chuck
> 
> John Drake wrote:
> > 
> > The point is that in GMPLS, as in regular MPLS, restoration 
> consists of
> > rerouting from the endpoints upon
> > notification of failure.  There are a whole spectrum of 
> path and span
> > protection possibilites beyond this
> > that people (including us) have proposed, but in the absence of firm
> > requirements, it's hard to know which
> > to pursue.  I'm not sure 'shared mesh restoration' 
> completely covers it.
> > 
> > Thanks,
> > 
> > John
> > 
> > -----Original Message-----
> > From: C. R. Kalmanek [mailto:[email-masked]]
> > Sent: Friday, May 25, 2001 9:54 AM
> > To: John Drake
> > Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> > [email-masked]
> > Subject: Re: GMPLS Last Calls
> > 
> > John,
> > 
> > While there currently are no restoration requirements from the
> > TE (or other) group, what Percy is saying is that shared mesh
> > restoration WILL be a requirement from those groups.  Since the
> > current GMPLS drafts don't meet this requirement, they are
> > unlikely to meet key SP needs.
> > 
> > I don't understand a process that starts the requirements
> > development after last call for the signaling specifications.
> > 
> > chuck
> > 
> > John Drake wrote:
> > >
> > > Percy,
> > >
> > > There has been work on protocols for path restoration in 
> mesh networks by
> > a
> > > number of
> > > people.  However, at the last IETF Kireeti and Vijay 
> clearly indicated
> > that
> > > this work,
> > > while interesting, wouldn't be allowed to progress in advance of a
> > > restoration requirements
> > > draft from the TE group.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Tarapore, Percy S [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 11:55 AM
> > > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > > Subject: RE: GMPLS Last Calls
> > >
> > > There is a significant issue related to the absence of 
> restoration in the
> > > signaling draft
> > >
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> ed-signaling-0
> > > 4.txt). Very specifically, Section 7 of this draft deals 
> with the case
> > > involving protection information for link protection. While link
> > protection
> > > schemes may be desirable for fast recovery related to 
> high priority LSP's,
> > > more cost-effective shared mesh restoration schemes would 
> be preferred for
> > > the majority of traffic from a Service Provider's 
> perspective. This
> > > observation is supported by the fact that many vendors 
> are currently
> > > developing proprietary schemes for shared mesh 
> restoration. Hence, in
> > > addition to the protection information, GMPLS signaling 
> needs to reflect a
> > > minimum set of information/attributes required for shared 
> mesh restoration
> > > without jeopardizing vendor proprietary solutions.
> > >
> > > The need for multiple types of restoration capabilities 
> is well documented
> > > in the OIF/UNI I-D
> > >
> > 
> http://search.ietf.org/internet-drafts/draft-many-carrier-fram
> ework-uni-00.t
> > > xt as follows:
> > >
> > > " Multiple types of facilities available for restoration 
> are needed
> > >    within the network. The following options should be 
> considered for
> > >    allocation of facilities to support restoration of failed
> > >    connections:
> > >    - Dedicated restoration capacity
> > >    - Shared restoration capacity. This allows the network 
> to ensure
> > >      high quality service for customers, while still managing its
> > >      physical resources efficiently.
> > >    - Un-restorable
> > >    - Pre-emptable"
> > >
> > > The OIF/UNI I-D supports a range of different restoration 
> schemes through
> > > the use of service level as a connection attribute. This 
> attribute is
> > > defined as follows:
> > >
> > > " an integer attribute that indicates a class of service. 
> A carrier may
> > > specify a range of different classes of service (e.g. 
> gold, silver,
> > bronze)
> > > with predefined characteristics (e.g. restoration plans). 
> The pre-defined
> > > service types correspond to different types of network 
> restoration (e.g.
> > no
> > > restoration, 1+1 protection), connection set-up and hold 
> priorities,
> > > reversion strategies for the connection after failures 
> have been repaired,
> > > and retention strategies."
> > >
> > > It is therefore important that GMPLS be extended to be 
> able to support
> > such
> > > restoration schemes.
> > >
> > > Percy S. Tarapore
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: Ash, Gerald R (Jerry)
> > > Sent: Thursday, May 24, 2001 2:20 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: Ash, Gerald R (Jerry)
> > > Subject: RE: GMPLS Last Calls
> > >
> > > Quoting from the CCAMP/IETF-50 meeting minutes re the 
> GMPLS Architecture
> > > draft:
> > >
> > > "Eve - Had hoped that CCAMP formation and expression of 
> requirements would
> > > enable us to do more with architecture than reverse 
> architect proposed
> > > solution. Think we should also look at carrier 
> requirements and look for
> > > discrepancies with architecture.
> > > Curtis - requirements of carriers not being addressed?
> > > Eve - happy to discuss on mailing list in absence of time"
> > >
> > > There are still no documented service provider (SP) 
> requirements driving
> > the
> > > proposed GMPLS protocol extensions.  This is inconsistent 
> with the current
> > > initiatives to provide SP requirements prior to protocol 
> extensions being
> > > accepted, such as for protection/restoration, network 
> hierarchy, MPLS OAM,
> > > MPLS/DiffServ TE, multi-area TE, etc.
> > >
> > > Here is a sample of SP requirements that are not being 
> addressed (other
> > > requirements from our perspective are forthcoming):
> > >
> > > 1. Restoration requirements, particularly in support of 
> mesh restoration,
> > > need to be supported by GMPLS.  For example, Section 7 of 
> the Generalized
> > > Signaling I-D
> > >
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generaliz
> ed-signaling-0
> > > 4.txt)
> > > primarily discusses link protection, restoration 
> capabilities are largely
> > > missing and need to be included.
> > >
> > > 2. Standards explicitly supported by GMPLS, such as 
> G.707, G.709, etc.,
> > > should be clearly identified in the text and referenced 
> in the GMPLS I-Ds,
> > > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> > [Reference
> > > G.707] is supported by the Generalized Label Request."
> > >
> > > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > > requirements to the list.  It would also help if more SPs 
> were invited to
> > > co-author the GMPLS drafts, to help ensure that SP 
> requirements are more
> > > adequately reflected and addressed.
> > >
> > > Jerry Ash
> > > AT&T Labs
> > >
> > > -----Original Message-----
> > > From: George Swallow [mailto:[email-masked]]
> > > Sent: Monday, May 14, 2001 1:52 PM
> > > To: [email-masked]; [email-masked]
> > > Subject: GMPLS Last Calls
> > >
> > > This message initiates a last call on four GMPLS drafts.  The last
> > > call is being issued jointly in the MPLS and CCAMP workgroups.
> > >
> > > The drafts are:
> > >
> > >     1.  Generalized MPLS - Signaling Functional Description
> > >
> > >            <draft-ietf-mpls-generalized-signaling-04.txt>
> > >
> > >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> > >
> > >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> > >
> > >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> > >
> > >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> > >
> > >     4.  GMPLS Extensions for SONET and SDH Control
> > >
> > >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> > >
> > > The last call closes May 29, 12 pm GMT.
> > >
> > > -  V2KG (Vijay, Vijay, Kireeti, & George)
> > >
> > > 
> ======================================================================
> > > George Swallow       Cisco Systems                   
> (978) 244-8143
> > >                      250 Apollo Drive
> > >                      Chelmsford, Ma 01824
> 

Delivery-date: Fri, 25 May 2001 10:40:06 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Fri, 25 May 2001 13:36:13 -0400

It is not at all clear to me that those 2 are the only choices. You can do
virtual concatenation at the end-points of the valuable link if you want to
avoid having end systems do that. This would be the standards-compliant
variance of 2. Am I missing something?

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 12:27 PM
To: 'Zhi-Wei Lin'
Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
[email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

To avoid re-grooming either virtual concatenation or arbitrary concatenation
can help, but the implications are quite different.
Say we have a particularly valuable (expensive) link that we can't or don't
want to re-groom then we have two options:
(1)     Require that ALL end systems that could potentially use this link
convert over to virtual concatenation from standard concatenation.
(2)     Or, install boxes at both ends of the link that support the
arbitrary concatenation that we've been discussing.

Which of these seems more realistic and practical?
Greg B.
        Dr. Greg M. Bernstein, Senior Scientist, Ciena
        New phone: (510) 573-2237

                -----Original Message-----
                From:   Zhi-Wei Lin [mailto:[email-masked]]
                Sent:   Thursday, May 17, 2001 8:41 AM
                To:     Bernstein, Greg
                Cc:     'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
                Subject:        Re: [IP-Optical] concatenation extensions in
sonet/sdh

                Hi,

                some observations:

                in terms of re-grooming and such, I believe both virtual
concatenation
                and arbitrary concatenation can perform this. One method is
                standardized, the other is proprietary.

                In terms of routing of the individual connections that make
up the
                concatenated signal, virtual concatenation is more flexible
than
                arbitrary concatenation, since you can put each component VC
in
                different lines, and each component can be routed
differently.

                In terms of interworking, yes the SIGNALLING can defnititely
be made to
                interwork. However, the larger issue for interworking is
support by the
                transport equipment themselves. Thus interworking involves
TWO parts:
                signaling interworking and transport interworking. Having
one without
                the other doesn't really help...

                Thus, in terms of solving real problems, either virtual or
arbitrary can
                accomplish that, but IMO, virtual seems more flexible...and
                standardized...

                In terms of standards as fostering interoperability and
stifling of
                innovation, in principle yes I agree. And therefore if
arbitrary
                concatenation should be standardized, it should be
standardized in the
                correct standards body. As Maarten mentioned, the relevant
standards
                bodies discussed arbitrary concatenation years ago, and
decided
                (hopefully based on their expert technical opinion - I
wasn't involved)
                not to include arbitrary but instead to include virtual.
IMO, there must
                be good reasons, and from what I can tell, I see virtual as
been more
                flexible so that is a pretty good reason...we at IETF, being
protocol
                experts (and budding transport experts?) should not try to
second-guess
                the decisions without fully understanding the
ramifications...

                As for stifling innovation, anytime you standardize anything
there is
                always some factor of development that gets fixed (is this
something
                that should not be said in a public forum??? -- sorry!!).
Therefore
                there is always a tradeoff between innovation and
standardization. I
                think the job of standards bodies is to try to balance these
two factors
                such that the industry in general can live with the result
without
                unduly burdening...

                agree?

                Zhi

                "Bernstein, Greg" wrote:
                >
                > A couple more points.
                > (1)     GMPLS works well with arbitrary concatenations
need to specify the
                > time slots since it provides a signaling protocol that can
do just that,
                > i.e., GMPLS actually enables this feature to interoperate.
                > (2)     Arbitrary concatenation offers a solution to a
real problem, i.e.,
                > eliminates the need for re-grooming on lines that support
it.  For those who
                > have invested non-trivial amounts of money in transoceanic
links this can be
                > a significant savings.
                > (3)     The goal is interoperability and to solve real
problems.  We've got
                > a real problem and with a minor edit to the GMPLS SONET
specification we can
                > have an interoperable method for solving it.
                >
                > To be precise in the definition of arbitrary
concatenation:
                > As a concatenated signal within a single SONET Line (SDH
MS), with
                > potentially arbitrary timeslots used for its components.
                >
                > The current main application is: avoiding the need for
service impacting
                > re-grooming. Note that this applies to standard sized
signals and is a per
                > link property.
                >
                > Other applications do exist and are somewhat competitive
with non-LCAS
                > virtual concatenation since the implementation of
arbitrary concatenation
                > for odd sized signals is simpler than that of virtual
concatenation.  Once
                > "odd" sized signals are used an entire path through the
network must exist
                > that supports them.
                >
                > Folks I thought the role of standards organizations was to
foster
                > interoperability that enables the industry to move forward
rather than as a
                > means to stifle innovation. I think it is better for the
marketplace to
                > decide which features are desirable.
                >
                > Greg B.
                >
                >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
                >         New phone: (510) 573-2237
                >

Delivery-date: Fri, 25 May 2001 10:25:30 -0700
Date: Fri, 25 May 2001 19:24:16 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: John Drake <[email-masked]>, "'C. R. Kalmanek'" <[email-masked]>, "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

This is a multi-part message in MIME format.
--------------53760D5AEC6FE7ECCAD53003
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

>From that point of view it is clear that during the last IETF meeting
and if i am not making a mistake there were at least 3 presentations
from that aspect (as John mentioned) these edge-to-edge restoration
mechanisms are based either on extending current notification and 
signalling mechanisms (here signalling protocols are the same than 
those used to provision or establish the LSPs) or using a specific 
signalling protocol different from the one used to provision or setup
these LSPs. Notice as well that link restoration (and not only 
protection) could be also discussed from that perspective.

Notice that IETF AB have asked us to wait upon the TE WG requirements
on "network survivability" prior to continue to propose technical 
solutions. I agree with John that with the current status it is rather
difficult to know if (even partially) which direction to pursue.

Regards,
- Dimitri.

John Drake wrote:
> 
> The point is that in GMPLS, as in regular MPLS, restoration consists of
> rerouting from the endpoints upon
> notification of failure.  There are a whole spectrum of path and span
> protection possibilites beyond this
> that people (including us) have proposed, but in the absence of firm
> requirements, it's hard to know which
> to pursue.  I'm not sure 'shared mesh restoration' completely covers it.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 9:54 AM
> To: John Drake
> Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> John,
> 
> While there currently are no restoration requirements from the
> TE (or other) group, what Percy is saying is that shared mesh
> restoration WILL be a requirement from those groups.  Since the
> current GMPLS drafts don't meet this requirement, they are
> unlikely to meet key SP needs.
> 
> I don't understand a process that starts the requirements
> development after last call for the signaling specifications.
> 
> chuck
> 
> John Drake wrote:
> >
> > Percy,
> >
> > There has been work on protocols for path restoration in mesh networks by
> a
> > number of
> > people.  However, at the last IETF Kireeti and Vijay clearly indicated
> that
> > this work,
> > while interesting, wouldn't be allowed to progress in advance of a
> > restoration requirements
> > draft from the TE group.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 11:55 AM
> > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> > There is a significant issue related to the absence of restoration in the
> > signaling draft
> >
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > involving protection information for link protection. While link
> protection
> > schemes may be desirable for fast recovery related to high priority LSP's,
> > more cost-effective shared mesh restoration schemes would be preferred for
> > the majority of traffic from a Service Provider's perspective. This
> > observation is supported by the fact that many vendors are currently
> > developing proprietary schemes for shared mesh restoration. Hence, in
> > addition to the protection information, GMPLS signaling needs to reflect a
> > minimum set of information/attributes required for shared mesh restoration
> > without jeopardizing vendor proprietary solutions.
> >
> > The need for multiple types of restoration capabilities is well documented
> > in the OIF/UNI I-D
> >
> http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> > xt as follows:
> >
> > " Multiple types of facilities available for restoration are needed
> >    within the network. The following options should be considered for
> >    allocation of facilities to support restoration of failed
> >    connections:
> >    - Dedicated restoration capacity
> >    - Shared restoration capacity. This allows the network to ensure
> >      high quality service for customers, while still managing its
> >      physical resources efficiently.
> >    - Un-restorable
> >    - Pre-emptable"
> >
> > The OIF/UNI I-D supports a range of different restoration schemes through
> > the use of service level as a connection attribute. This attribute is
> > defined as follows:
> >
> > " an integer attribute that indicates a class of service. A carrier may
> > specify a range of different classes of service (e.g. gold, silver,
> bronze)
> > with predefined characteristics (e.g. restoration plans). The pre-defined
> > service types correspond to different types of network restoration (e.g.
> no
> > restoration, 1+1 protection), connection set-up and hold priorities,
> > reversion strategies for the connection after failures have been repaired,
> > and retention strategies."
> >
> > It is therefore important that GMPLS be extended to be able to support
> such
> > restoration schemes.
> >
> > Percy S. Tarapore
> > AT&T Labs
> >
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry)
> > Sent: Thursday, May 24, 2001 2:20 PM
> > To: [email-masked]; [email-masked]
> > Cc: Ash, Gerald R (Jerry)
> > Subject: RE: GMPLS Last Calls
> >
> > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > draft:
> >
> > "Eve - Had hoped that CCAMP formation and expression of requirements would
> > enable us to do more with architecture than reverse architect proposed
> > solution. Think we should also look at carrier requirements and look for
> > discrepancies with architecture.
> > Curtis - requirements of carriers not being addressed?
> > Eve - happy to discuss on mailing list in absence of time"
> >
> > There are still no documented service provider (SP) requirements driving
> the
> > proposed GMPLS protocol extensions.  This is inconsistent with the current
> > initiatives to provide SP requirements prior to protocol extensions being
> > accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> > MPLS/DiffServ TE, multi-area TE, etc.
> >
> > Here is a sample of SP requirements that are not being addressed (other
> > requirements from our perspective are forthcoming):
> >
> > 1. Restoration requirements, particularly in support of mesh restoration,
> > need to be supported by GMPLS.  For example, Section 7 of the Generalized
> > Signaling I-D
> >
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt)
> > primarily discusses link protection, restoration capabilities are largely
> > missing and need to be included.
> >
> > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > should be clearly identified in the text and referenced in the GMPLS I-Ds,
> > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> [Reference
> > G.707] is supported by the Generalized Label Request."
> >
> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
> >
> > Jerry Ash
> > AT&T Labs
> >
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: Monday, May 14, 2001 1:52 PM
> > To: [email-masked]; [email-masked]
> > Subject: GMPLS Last Calls
> >
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> >
> > The drafts are:
> >
> >     1.  Generalized MPLS - Signaling Functional Description
> >
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> >
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> >
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> >
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> >
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> >
> >     4.  GMPLS Extensions for SONET and SDH Control
> >
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> >
> > The last call closes May 29, 12 pm GMT.
> >
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824
--------------53760D5AEC6FE7ECCAD53003
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------53760D5AEC6FE7ECCAD53003--

Delivery-date: Fri, 25 May 2001 10:15:08 -0700
Date: Fri, 25 May 2001 13:07:36 -0400
From: "C. R. Kalmanek" <[email-masked]>
To: John Drake <[email-masked]>
Cc: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

I fully agree: there are a whole spectrum of options that we
need to sort through, and clear requirements are needed to
guide that process.  Our concern is with the last call.  It
doesn't make sense to progress drafts to RFC that are likely 
in hindsight to be viewed as having serious deficiencies in
meeting restoration requirements.

chuck

John Drake wrote:
> 
> The point is that in GMPLS, as in regular MPLS, restoration consists of
> rerouting from the endpoints upon
> notification of failure.  There are a whole spectrum of path and span
> protection possibilites beyond this
> that people (including us) have proposed, but in the absence of firm
> requirements, it's hard to know which
> to pursue.  I'm not sure 'shared mesh restoration' completely covers it.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: C. R. Kalmanek [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 9:54 AM
> To: John Drake
> Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
> [email-masked]
> Subject: Re: GMPLS Last Calls
> 
> John,
> 
> While there currently are no restoration requirements from the
> TE (or other) group, what Percy is saying is that shared mesh
> restoration WILL be a requirement from those groups.  Since the
> current GMPLS drafts don't meet this requirement, they are
> unlikely to meet key SP needs.
> 
> I don't understand a process that starts the requirements
> development after last call for the signaling specifications.
> 
> chuck
> 
> John Drake wrote:
> >
> > Percy,
> >
> > There has been work on protocols for path restoration in mesh networks by
> a
> > number of
> > people.  However, at the last IETF Kireeti and Vijay clearly indicated
> that
> > this work,
> > while interesting, wouldn't be allowed to progress in advance of a
> > restoration requirements
> > draft from the TE group.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Tarapore, Percy S [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 11:55 AM
> > To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> > Subject: RE: GMPLS Last Calls
> >
> > There is a significant issue related to the absence of restoration in the
> > signaling draft
> >
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt). Very specifically, Section 7 of this draft deals with the case
> > involving protection information for link protection. While link
> protection
> > schemes may be desirable for fast recovery related to high priority LSP's,
> > more cost-effective shared mesh restoration schemes would be preferred for
> > the majority of traffic from a Service Provider's perspective. This
> > observation is supported by the fact that many vendors are currently
> > developing proprietary schemes for shared mesh restoration. Hence, in
> > addition to the protection information, GMPLS signaling needs to reflect a
> > minimum set of information/attributes required for shared mesh restoration
> > without jeopardizing vendor proprietary solutions.
> >
> > The need for multiple types of restoration capabilities is well documented
> > in the OIF/UNI I-D
> >
> http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> > xt as follows:
> >
> > " Multiple types of facilities available for restoration are needed
> >    within the network. The following options should be considered for
> >    allocation of facilities to support restoration of failed
> >    connections:
> >    - Dedicated restoration capacity
> >    - Shared restoration capacity. This allows the network to ensure
> >      high quality service for customers, while still managing its
> >      physical resources efficiently.
> >    - Un-restorable
> >    - Pre-emptable"
> >
> > The OIF/UNI I-D supports a range of different restoration schemes through
> > the use of service level as a connection attribute. This attribute is
> > defined as follows:
> >
> > " an integer attribute that indicates a class of service. A carrier may
> > specify a range of different classes of service (e.g. gold, silver,
> bronze)
> > with predefined characteristics (e.g. restoration plans). The pre-defined
> > service types correspond to different types of network restoration (e.g.
> no
> > restoration, 1+1 protection), connection set-up and hold priorities,
> > reversion strategies for the connection after failures have been repaired,
> > and retention strategies."
> >
> > It is therefore important that GMPLS be extended to be able to support
> such
> > restoration schemes.
> >
> > Percy S. Tarapore
> > AT&T Labs
> >
> > -----Original Message-----
> > From: Ash, Gerald R (Jerry)
> > Sent: Thursday, May 24, 2001 2:20 PM
> > To: [email-masked]; [email-masked]
> > Cc: Ash, Gerald R (Jerry)
> > Subject: RE: GMPLS Last Calls
> >
> > Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> > draft:
> >
> > "Eve - Had hoped that CCAMP formation and expression of requirements would
> > enable us to do more with architecture than reverse architect proposed
> > solution. Think we should also look at carrier requirements and look for
> > discrepancies with architecture.
> > Curtis - requirements of carriers not being addressed?
> > Eve - happy to discuss on mailing list in absence of time"
> >
> > There are still no documented service provider (SP) requirements driving
> the
> > proposed GMPLS protocol extensions.  This is inconsistent with the current
> > initiatives to provide SP requirements prior to protocol extensions being
> > accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> > MPLS/DiffServ TE, multi-area TE, etc.
> >
> > Here is a sample of SP requirements that are not being addressed (other
> > requirements from our perspective are forthcoming):
> >
> > 1. Restoration requirements, particularly in support of mesh restoration,
> > need to be supported by GMPLS.  For example, Section 7 of the Generalized
> > Signaling I-D
> >
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> > 4.txt)
> > primarily discusses link protection, restoration capabilities are largely
> > missing and need to be included.
> >
> > 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> > should be clearly identified in the text and referenced in the GMPLS I-Ds,
> > e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
> [Reference
> > G.707] is supported by the Generalized Label Request."
> >
> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
> >
> > Jerry Ash
> > AT&T Labs
> >
> > -----Original Message-----
> > From: George Swallow [mailto:[email-masked]]
> > Sent: Monday, May 14, 2001 1:52 PM
> > To: [email-masked]; [email-masked]
> > Subject: GMPLS Last Calls
> >
> > This message initiates a last call on four GMPLS drafts.  The last
> > call is being issued jointly in the MPLS and CCAMP workgroups.
> >
> > The drafts are:
> >
> >     1.  Generalized MPLS - Signaling Functional Description
> >
> >            <draft-ietf-mpls-generalized-signaling-04.txt>
> >
> >     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> >
> >            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> >
> >     3.  Generalized MPLS Signaling - CR-LDP Extensions
> >
> >            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> >
> >     4.  GMPLS Extensions for SONET and SDH Control
> >
> >            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> >
> > The last call closes May 29, 12 pm GMT.
> >
> > -  V2KG (Vijay, Vijay, Kireeti, & George)
> >
> > ======================================================================
> > George Swallow       Cisco Systems                   (978) 244-8143
> >                      250 Apollo Drive
> >                      Chelmsford, Ma 01824

Delivery-date: Fri, 25 May 2001 10:03:36 -0700
From: John Drake <[email-masked]>
To: "'C. R. Kalmanek'" <[email-masked]>, John Drake <[email-masked]>
Cc: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Fri, 25 May 2001 09:58:16 -0700

The point is that in GMPLS, as in regular MPLS, restoration consists of
rerouting from the endpoints upon
notification of failure.  There are a whole spectrum of path and span
protection possibilites beyond this
that people (including us) have proposed, but in the absence of firm
requirements, it's hard to know which
to pursue.  I'm not sure 'shared mesh restoration' completely covers it.

Thanks,

John  

-----Original Message-----
From: C. R. Kalmanek [mailto:[email-masked]]
Sent: Friday, May 25, 2001 9:54 AM
To: John Drake
Cc: 'Tarapore, Percy S'; Ash, Gerald R (Jerry); [email-masked];
[email-masked]
Subject: Re: GMPLS Last Calls

John,

While there currently are no restoration requirements from the 
TE (or other) group, what Percy is saying is that shared mesh 
restoration WILL be a requirement from those groups.  Since the 
current GMPLS drafts don't meet this requirement, they are 
unlikely to meet key SP needs.

I don't understand a process that starts the requirements 
development after last call for the signaling specifications.

chuck

John Drake wrote:
> 
> Percy,
> 
> There has been work on protocols for path restoration in mesh networks by
a
> number of
> people.  However, at the last IETF Kireeti and Vijay clearly indicated
that
> this work,
> while interesting, wouldn't be allowed to progress in advance of a
> restoration requirements
> draft from the TE group.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Tarapore, Percy S [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 11:55 AM
> To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> There is a significant issue related to the absence of restoration in the
> signaling draft
>
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> 4.txt). Very specifically, Section 7 of this draft deals with the case
> involving protection information for link protection. While link
protection
> schemes may be desirable for fast recovery related to high priority LSP's,
> more cost-effective shared mesh restoration schemes would be preferred for
> the majority of traffic from a Service Provider's perspective. This
> observation is supported by the fact that many vendors are currently
> developing proprietary schemes for shared mesh restoration. Hence, in
> addition to the protection information, GMPLS signaling needs to reflect a
> minimum set of information/attributes required for shared mesh restoration
> without jeopardizing vendor proprietary solutions.
> 
> The need for multiple types of restoration capabilities is well documented
> in the OIF/UNI I-D
>
http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> xt as follows:
> 
> " Multiple types of facilities available for restoration are needed
>    within the network. The following options should be considered for
>    allocation of facilities to support restoration of failed
>    connections:
>    - Dedicated restoration capacity
>    - Shared restoration capacity. This allows the network to ensure
>      high quality service for customers, while still managing its
>      physical resources efficiently.
>    - Un-restorable
>    - Pre-emptable"
> 
> The OIF/UNI I-D supports a range of different restoration schemes through
> the use of service level as a connection attribute. This attribute is
> defined as follows:
> 
> " an integer attribute that indicates a class of service. A carrier may
> specify a range of different classes of service (e.g. gold, silver,
bronze)
> with predefined characteristics (e.g. restoration plans). The pre-defined
> service types correspond to different types of network restoration (e.g.
no
> restoration, 1+1 protection), connection set-up and hold priorities,
> reversion strategies for the connection after failures have been repaired,
> and retention strategies."
> 
> It is therefore important that GMPLS be extended to be able to support
such
> restoration schemes.
> 
> Percy S. Tarapore
> AT&T Labs
> 
> -----Original Message-----
> From: Ash, Gerald R (Jerry)
> Sent: Thursday, May 24, 2001 2:20 PM
> To: [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry)
> Subject: RE: GMPLS Last Calls
> 
> Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> draft:
> 
> "Eve - Had hoped that CCAMP formation and expression of requirements would
> enable us to do more with architecture than reverse architect proposed
> solution. Think we should also look at carrier requirements and look for
> discrepancies with architecture.
> Curtis - requirements of carriers not being addressed?
> Eve - happy to discuss on mailing list in absence of time"
> 
> There are still no documented service provider (SP) requirements driving
the
> proposed GMPLS protocol extensions.  This is inconsistent with the current
> initiatives to provide SP requirements prior to protocol extensions being
> accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> MPLS/DiffServ TE, multi-area TE, etc.
> 
> Here is a sample of SP requirements that are not being addressed (other
> requirements from our perspective are forthcoming):
> 
> 1. Restoration requirements, particularly in support of mesh restoration,
> need to be supported by GMPLS.  For example, Section 7 of the Generalized
> Signaling I-D
>
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> 4.txt)
> primarily discusses link protection, restoration capabilities are largely
> missing and need to be included.
> 
> 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> should be clearly identified in the text and referenced in the GMPLS I-Ds,
> e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707
[Reference
> G.707] is supported by the Generalized Label Request."
> 
> As per Eve's comment at IETF-50, SPs are encouraged to post their
> requirements to the list.  It would also help if more SPs were invited to
> co-author the GMPLS drafts, to help ensure that SP requirements are more
> adequately reflected and addressed.
> 
> Jerry Ash
> AT&T Labs
> 
> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 1:52 PM
> To: [email-masked]; [email-masked]
> Subject: GMPLS Last Calls
> 
> This message initiates a last call on four GMPLS drafts.  The last
> call is being issued jointly in the MPLS and CCAMP workgroups.
> 
> The drafts are:
> 
>     1.  Generalized MPLS - Signaling Functional Description
> 
>            <draft-ietf-mpls-generalized-signaling-04.txt>
> 
>     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> 
>            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> 
>     3.  Generalized MPLS Signaling - CR-LDP Extensions
> 
>            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> 
>     4.  GMPLS Extensions for SONET and SDH Control
> 
>            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> 
> The last call closes May 29, 12 pm GMT.
> 
> -  V2KG (Vijay, Vijay, Kireeti, & George)
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Delivery-date: Fri, 25 May 2001 10:01:47 -0700
Date: Fri, 25 May 2001 12:54:14 -0400
From: "C. R. Kalmanek" <[email-masked]>
To: John Drake <[email-masked]>
Cc: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls

John,

While there currently are no restoration requirements from the 
TE (or other) group, what Percy is saying is that shared mesh 
restoration WILL be a requirement from those groups.  Since the 
current GMPLS drafts don't meet this requirement, they are 
unlikely to meet key SP needs.

I don't understand a process that starts the requirements 
development after last call for the signaling specifications.

chuck

John Drake wrote:
> 
> Percy,
> 
> There has been work on protocols for path restoration in mesh networks by a
> number of
> people.  However, at the last IETF Kireeti and Vijay clearly indicated that
> this work,
> while interesting, wouldn't be allowed to progress in advance of a
> restoration requirements
> draft from the TE group.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Tarapore, Percy S [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 11:55 AM
> To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
> Subject: RE: GMPLS Last Calls
> 
> There is a significant issue related to the absence of restoration in the
> signaling draft
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> 4.txt). Very specifically, Section 7 of this draft deals with the case
> involving protection information for link protection. While link protection
> schemes may be desirable for fast recovery related to high priority LSP's,
> more cost-effective shared mesh restoration schemes would be preferred for
> the majority of traffic from a Service Provider's perspective. This
> observation is supported by the fact that many vendors are currently
> developing proprietary schemes for shared mesh restoration. Hence, in
> addition to the protection information, GMPLS signaling needs to reflect a
> minimum set of information/attributes required for shared mesh restoration
> without jeopardizing vendor proprietary solutions.
> 
> The need for multiple types of restoration capabilities is well documented
> in the OIF/UNI I-D
> http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
> xt as follows:
> 
> " Multiple types of facilities available for restoration are needed
>    within the network. The following options should be considered for
>    allocation of facilities to support restoration of failed
>    connections:
>    - Dedicated restoration capacity
>    - Shared restoration capacity. This allows the network to ensure
>      high quality service for customers, while still managing its
>      physical resources efficiently.
>    - Un-restorable
>    - Pre-emptable"
> 
> The OIF/UNI I-D supports a range of different restoration schemes through
> the use of service level as a connection attribute. This attribute is
> defined as follows:
> 
> " an integer attribute that indicates a class of service. A carrier may
> specify a range of different classes of service (e.g. gold, silver, bronze)
> with predefined characteristics (e.g. restoration plans). The pre-defined
> service types correspond to different types of network restoration (e.g. no
> restoration, 1+1 protection), connection set-up and hold priorities,
> reversion strategies for the connection after failures have been repaired,
> and retention strategies."
> 
> It is therefore important that GMPLS be extended to be able to support such
> restoration schemes.
> 
> Percy S. Tarapore
> AT&T Labs
> 
> -----Original Message-----
> From: Ash, Gerald R (Jerry)
> Sent: Thursday, May 24, 2001 2:20 PM
> To: [email-masked]; [email-masked]
> Cc: Ash, Gerald R (Jerry)
> Subject: RE: GMPLS Last Calls
> 
> Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
> draft:
> 
> "Eve - Had hoped that CCAMP formation and expression of requirements would
> enable us to do more with architecture than reverse architect proposed
> solution. Think we should also look at carrier requirements and look for
> discrepancies with architecture.
> Curtis - requirements of carriers not being addressed?
> Eve - happy to discuss on mailing list in absence of time"
> 
> There are still no documented service provider (SP) requirements driving the
> proposed GMPLS protocol extensions.  This is inconsistent with the current
> initiatives to provide SP requirements prior to protocol extensions being
> accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
> MPLS/DiffServ TE, multi-area TE, etc.
> 
> Here is a sample of SP requirements that are not being addressed (other
> requirements from our perspective are forthcoming):
> 
> 1. Restoration requirements, particularly in support of mesh restoration,
> need to be supported by GMPLS.  For example, Section 7 of the Generalized
> Signaling I-D
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
> 4.txt)
> primarily discusses link protection, restoration capabilities are largely
> missing and need to be included.
> 
> 2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
> should be clearly identified in the text and referenced in the GMPLS I-Ds,
> e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707 [Reference
> G.707] is supported by the Generalized Label Request."
> 
> As per Eve's comment at IETF-50, SPs are encouraged to post their
> requirements to the list.  It would also help if more SPs were invited to
> co-author the GMPLS drafts, to help ensure that SP requirements are more
> adequately reflected and addressed.
> 
> Jerry Ash
> AT&T Labs
> 
> -----Original Message-----
> From: George Swallow [mailto:[email-masked]]
> Sent: Monday, May 14, 2001 1:52 PM
> To: [email-masked]; [email-masked]
> Subject: GMPLS Last Calls
> 
> This message initiates a last call on four GMPLS drafts.  The last
> call is being issued jointly in the MPLS and CCAMP workgroups.
> 
> The drafts are:
> 
>     1.  Generalized MPLS - Signaling Functional Description
> 
>            <draft-ietf-mpls-generalized-signaling-04.txt>
> 
>     2.  Generalized MPLS Signaling - RSVP-TE Extensions
> 
>            <draft-ietf-mpls-generalized-rsvp-te-03.txt>
> 
>     3.  Generalized MPLS Signaling - CR-LDP Extensions
> 
>            <draft-ietf-mpls-generalized-cr-ldp-03.txt>
> 
>     4.  GMPLS Extensions for SONET and SDH Control
> 
>            <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
> 
> The last call closes May 29, 12 pm GMT.
> 
> -  V2KG (Vijay, Vijay, Kireeti, & George)
> 
> ======================================================================
> George Swallow       Cisco Systems                   (978) 244-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824

Delivery-date: Fri, 25 May 2001 09:32:23 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Guo-Qiang Wang'" <[email-masked]>, "'Lyndon Ong'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>
Cc: "'Eve Varma'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Fri, 25 May 2001 12:23:58 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0E537.19EC4350
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0E537.19EC4350"

------_=_NextPart_001_01C0E537.19EC4350
Content-Type: text/plain;
	charset="iso-8859-1"

That sounds reasonable.
 
Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Guo-Qiang Wang [mailto:[email-masked]]
Sent: Friday, May 25, 2001 9:23 AM
To: 'Lyndon Ong'; Zhi-Wei Lin; John Drake
Cc: 'Eve Varma'; Mannie, Eric; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
tion
 
Hi, 
>From my observation for the past two weeks, it seems to me that we do have
some 
"interworking" problem even within this small group discussion. The issues
are either 
syntactical ("should we put arbitrary concatenation into GMPLS spec"), or
semantically 
("what is proprietary"). We can imagine how hard it will be if we extend
this discussion 
to a large scope. 
Our purpose is to define a "standard" GMPLS which has to be widely accepted
and supported by vendors and carriers. To not jeopardize the last call
process, I will suggest 
you guys separate GMPLS (transport portion) as two drafts: 
  1. Standard draft: 
      This portion spec is based on current ITU/T1X1 transport standard, and
agreed by 
       all you people. This draft can get into last call now without
delaying GMPLS 
       progress. 
   2. Non-standard draft: 
       This is for people who are working on innovation/revolution/evolution
for next 
       generation transport. Eventually it may be merged into GMPLS if can
get 
       industry acceptance. 
Doing so we can avoid endless discussion without getting any significant
progress, 
also we give the implementation flexibility to vendor/carrier. In their PICS
(Protocol 
Implementation Conformation Specification), if they only implement standard
portion, 
they simply reference to GMPLS RFC. If they implement both, they reference
to 
GMPLS RFC and X-draft for interworking purpose. 
  Regards,   
                             
G.Q Wang 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 
-----Original Message----- 
From:   Lyndon Ong [SMTP:[email-masked]] 
Sent:   Friday, May 25, 2001 1:25 AM 
To:     Zhi-Wei Lin; John Drake 
Cc:     'Eve Varma'; Mannie, Eric; Wang, Guo-Qiang [KAN:0V10:EXCH];
[email-masked]; [email-masked]; q11/15; t1x1.5
Subject:        Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation 
Zhi-Wei, 
First of all, I hope that you agree that having this exchange is a good 
indication that this is a "fair and open process".  I'm surprised that this 
should be in question, given that we progress via consensus (OK, "rough" 
consensus) like many other standards bodies. 
Secondly, part of the problem is that I would interpret "proprietary" as 
meaning "exclusive", that is, intending to have exclusive control over some 
technology (close to the dictionary definition).  I believe you interpret 
"proprietary" 
as something that has not been commonly defined in ITU (or other accredited 
bodies). 
Maybe "non-standard" would be a more neutral term. 
Something like the arbitrary concatenation we have been talking about is, 
I think, the latter case - it is not exclusive technology, but it is 
relatively 
new and not everyone has taken advantage of it.  Our goal should be to 
achieve interoperability for such features, not to prohibit them.  Agreeing 
in common on how to identify them in signaling seems like a good step. 
Cheers, 
Lyndon 
 
At 05:25 PM 5/24/2001 -0400, Zhi-Wei Lin wrote: 
>I feel that I should at least try to explain my comments since people 
>may mis-interpret. 
> 
>As I said several emails ago, and have sort of repeated...we can move in 
>any direction as long as we make CLEAR what the method is for 
>evaluating. 
> 
>I did not try to denigrate, nor belittle the work of the numerous 
>authors. In fact I highly respect many of the authors of the documents. 
>Maybe my analogies are too strong, in that case I apologize. But the 
>fact remains that we seem to be looking at this from different angles 
>and thus causing all the discussions. I think the reason is that we all 
>have different backgrounds and different understanding of some basic 
>terms. 
> 
>My proposal is to outline the specific metrics used for including and 
>excluding the features, add the metric as part of the document so that a 
>person picking up the document understands the rationales behind this, 
>and list ALL the assumptions and limitations of the documents so that 
>there is no misunderstanding. 
> 
>For example, are these the metrics for including features????? 
> 
>* There must be at least 2 vendors that support a feature. In that case, 
>we need to quantify or show that this is indeed the case. Making claims 
>without substantiation IMO would not help... 
>* There must be at least one operator asking for the feature. 
>* For each feature identified that are extensions of the standards, do 
>we need to describe what it is, how it functions, what is needed to 
>interoperate, what impacts it has on current networks, does it work with 
>current networks, what is the scope of the feature (network-wide or 
>enterprise only), is there any security considerations (allows malicious 
>users to gain free service), etc. etc... 
> 
>OR maybe the metrics may be: 
> 
>* All features in the main body should conform to standards. 
>* Any other features not part of standards may be described in an 
>appendix, but no codepoints are assigned. Reserve a range of codepoints 
>for proprietary extensions 
> 
> 
>OR any other metrics that may be used. But we HAVE to enumerate this so 
>that the telecom/internet community can look upon this and say, "yes, 
>this was a fair and open process where any vendor or operator can apply 
>the metrics to any feature without any subjective decision being made 
>against any feature"... 
> 
> 
>Zhi 
> 
> 
> 
>John Drake wrote: 
> > 
> > Eve, 
> > 
> > Okay, for the sake of discussion, we'll assume that the last two thirds
of 
> > the e-mail 
> > don't exist and focus on the first third: 
> > 
> > "As for how many vendor is needed for a standard. Again this question 
> > doesn't really apply. We as engineers and the development community has 
> > to study a problem to make sure that it will not unduly impact existing 
> > networks, that what we are looking at should be sound and technically 
> > superior and that it will help provide added value to networks. As these

> > transport capabilities will likely require people of transport expertise

> > to study first, that's what we should do. Let's not get too "trigger 
> > happy" and include something "just because it's there", and then decide 
> > to remove when "standards say no". That like "putting the cart in front 
> > of the horse". 
> > 
> > The way I read this, it says to me that the people involved in working
on 
> > the 
> > draft are unqualifed to be working on it and that none of the work that 
> they 
> > have 
> > done over the past year is of any value, so my earlier comments still 
> > obtain. 
> > 
> > Furthermore, your comments about slippery slope disturb me because they 
> > follow 
> > a pattern of filibustering and dissemination of FUD which seems to be
aimed 
> > at 
> > preventing forward progress. 
> > 
> > Thanks, 
> > 
> > John 
> > 
> > -----Original Message----- 
> > From: Eve Varma [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > Sent: Thursday, May 24, 2001 10:30 AM 
> > To: John Drake 
> > Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked]; 
> > [email-masked]; q11/15; t1x1.5 
> > Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the 
> > concatenation 
> > 
> > Hi all, 
> > 
> > I don't think Zhi had any intent to denigrate other individuals whose 
> > names were on the draft (in fact, several have expressed similar 
> > concerns).  I think the key point was in the earlier part of the 
> > message; as expressed in an earlier message from Juergen Heiles, there's

> > considerable concern that we're descending a slippery slope that could 
> > ultimately have negative impacts. 
> > 
> >                        Cheers, 
> >                             Eve 
> > 
> > John Drake wrote: 
> > > 
> > > I find this message to be very puzzling.  As far as I know, the 
> authors as 
> > a 
> > > group are extremely conversant with the 
> > > subject matter in the draft and the draft represents their best
current 
> > > thinking.  You seem to be trying disparage them because you don't
agree 
> > with 
> > > their solution, and I think that that is extremely unprofessional. 
> > > 
> > > The authors spent a long time working out the details of what is 
> presented 
> > > in the draft, which you airily dismiss with: 
> > > 
> > > "As to how many companies and how many people's names are on the 
> > > contribution. Let's be intelligent adults here. As someone once asked 
> > > me, "if you see a million flies eating feces, would you also eat?" 
> > > (sorry people! it is disgusting but I had to give an extreme analogy).

> > > Sometimes the majority may not be correct. I am not saying I am
correct 
> > > either. It all depends on the background knowledge base and the 
> > > underlying motive of the people..." 
> > > 
> > > "As to how many processes followed, how many meetings held, how many 
> > > conferences given, how many emails exchanged...an idea doesn't get 
> > > better with repetition. As someone once said at some standards meeting

> > > "if an idea stinks, it doesn't matter how many times some idea is 
> > > presented, it still stinks that many times". So the number of times is

> > > not a reason for making a decision." 
> > > 
> > > If you're not happy with the draft, you are perfectly free to remove
your 
> > > name from it, but don't denigrate the other 
> > > authors. 
> > > 
> > > John 
> > > 
> > > 
> > > 
> > > -----Original Message----- 
> > > From: Zhi-Wei Lin [ mailto:[email-masked] <mailto:[email-masked]>
] 
> > > Sent: Wednesday, May 23, 2001 8:38 PM 
> > > To: Mannie, Eric 
> > > Cc: 'Guo-Qiang Wang'; [email-masked]; 
> > > [email-masked]; q11/15; t1x1.5 
> > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation 
> > > 
> > > Hi, 
> > > 
> > > I think your questions cannot be answered either way. Whether features

> > > are needed for one or two vendors is up to each vendor to decide what 
> > > they want. 
> > > 
> > > As for how many vendor is needed for a standard. Again this question 
> > > doesn't really apply. We as engineers and the development community
has 
> > > to study a problem to make sure that it will not unduly impact
existing 
> > > networks, that what we are looking at should be sound and technically 
> > > superior and that it will help provide added value to networks. As
these 
> > > transport capabilities will likely require people of transport
expertise 
> > > to study first, that's what we should do. Let's not get too "trigger 
> > > happy" and include something "just because it's there", and then
decide 
> > > to remove when "standards say no". That like "putting the cart in
front 
> > > of the horse". 
> > > 
> > > As to how many companies and how many people's names are on the 
> > > contribution. Let's be intelligent adults here. As someone once asked 
> > > me, "if you see a million flies eating feces, would you also eat?" 
> > > (sorry people! it is disgusting but I had to give an extreme analogy).

> > > Sometimes the majority may not be correct. I am not saying I am
correct 
> > > either. It all depends on the background knowledge base and the 
> > > underlying motive of the people... 
> > > 
> > > As to how many processes followed, how many meetings held, how many 
> > > conferences given, how many emails exchanged...an idea doesn't get 
> > > better with repetition. As someone once said at some standards meeting

> > > "if an idea stinks, it doesn't matter how many times some idea is 
> > > presented, it still stinks that many times". So the number of times is

> > > not a reason for making a decision. 
> > > 
> > > Let's be technical, let the experts in the right group decide, and we 
> > > should not jump the gun. Let's be adults and let's help make the
telecom 
> > > industry and the standards process a respectable place... 
> > > 
> > > "Mannie, Eric" wrote: 
> > > 
> > > > I don't work for a vendor :-) Who told you that some features are 
> needed 
> > > > only for one or two vendors ? How do you quantify the number of
vendors 
> > > that 
> > > > are needed to have a standard ? We work on a consensus based and
this 
> > > draft 
> > > > has 17 companies on it with 30 people. Usually it is much much less
at 
> > the 
> > > > IETF, you only have a small number of co-authors. I already gave a 
> > summary 
> > > > of the process that we followed, all the meetings that we hold, all
the 
> > > > conference call that we hold, all the e-mails that we exchanged,
etc. 
> > > > 
> > > > You described one model in your e-mail, that's a valid model but 
> this is 
> > > not 
> > > > THE (only) model. There are plenty of other models that can be 
> fulfilled 
> > > > with GMPLS. 
> > > > 
> > > > Kind regards, 
> > > > 
> > > > Eric 
> > > > 

------_=_NextPart_001_01C0E537.19EC4350
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<link rel=3DEdit-Time-Data href=3D"cid:[email-masked]">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the =
concatenation</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:ZapfChancery;
	panose-1:0 0 0 0 0 0 0 0 0 0;
	mso-font-alt:"Monotype Corsiva";
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-format:other;
	mso-font-pitch:variable;
	mso-font-signature:3 0 0 0 1 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:16792199 0 0 0 65791 0;}
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>T=
hat
sounds reasonable.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle18><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><=
![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoAutoSig><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><!--[if supportFields]><font=20
color=3Dblack><span style=3D'color:black'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font><![endif]--><=
font
color=3Dblack face=3DZapfChancery><span =
style=3D'font-family:ZapfChancery;color:black'>Monica
A. Lazer<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>Advanced Transport Technology =
and
Architecture Planning<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><img
src=3D"cid:[email-masked]"
v:src=3D"cid:[email-masked]" v:shapes=3D"_x0000_Mail" =
width=3D0
height=3D0 class=3Dshape =
style=3D'display:none;width:0;height:0'><!--[if gte vml 1]><v:shapetype =

 id=3D"_x0000_t75" coordsize=3D"21600,21600" o:spt=3D"75" =
o:preferrelative=3D"t"=20
 path=3D"m@4@5l@4@11@9@11@9@5xe" filled=3D"f" stroked=3D"f">
 <v:stroke joinstyle=3D"miter"/>
 <v:formulas>
  <v:f eqn=3D"if lineDrawn pixelLineWidth 0"/>
  <v:f eqn=3D"sum @0 1 0"/>
  <v:f eqn=3D"sum 0 0 @1"/>
  <v:f eqn=3D"prod @2 1 2"/>
  <v:f eqn=3D"prod @3 21600 pixelWidth"/>
  <v:f eqn=3D"prod @3 21600 pixelHeight"/>
  <v:f eqn=3D"sum @0 0 1"/>
  <v:f eqn=3D"prod @6 1 2"/>
  <v:f eqn=3D"prod @7 21600 pixelWidth"/>
  <v:f eqn=3D"sum @8 21600 0"/>
  <v:f eqn=3D"prod @7 21600 pixelHeight"/>
  <v:f eqn=3D"sum @10 21600 0"/>
 </v:formulas>
 <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" =
o:connecttype=3D"rect"/>
 <o:lock v:ext=3D"edit" aspectratio=3D"t"/>
</v:shapetype><v:shape id=3D"_x0000_i1025" type=3D"#_x0000_t75" =
style=3D'width:46.5pt;
 height:21.75pt'>
 <v:imagedata src=3D"cid:[email-masked]" o:title=3D""/>
</v:shape><![endif]--><![if !vml]><img width=3D62 height=3D29
src=3D"cid:[email-masked]" =
v:shapes=3D"_x0000_i1025"><![endif]><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>908 234 =
8462<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>[email-masked]<o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><!--[if supportFields]><font color=3Dblack><span=20
style=3D'color:black'><span =
style=3D'mso-element:field-end'></span></span></font><![endif]--><font
color=3Dnavy><span style=3D'color:navy'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle18><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<span
class=3DEmailStyle18><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>=

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Guo-Qiang Wang
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Friday, May 25, =
2001 9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Lyndon Ong'; =
Zhi-Wei Lin;
John Drake<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> 'Eve Varma'; Mannie, =
Eric;
[email-masked]; [email-masked]; q11/15; t1x1.5<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [T1X1.5] =
RE:
[IP-Optical] Re: Proposed text for the concatena tion</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi,</span></font=
><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>From my observation for the past two =
weeks, it
seems to me that we do have some</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&quot;interworking&quot; problem even =
within this
small group discussion. The issues are either</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>syntactical (&quot;should we put =
arbitrary
concatenation into GMPLS spec&quot;), or =
semantically</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>(&quot;what is proprietary&quot;). We can =
imagine
how hard it will be if we extend this discussion</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>to a large scope.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Our purpose is to define a =
&quot;standard&quot;
GMPLS which has to be widely accepted and supported by vendors and =
carriers. To
not jeopardize the last call process, I will suggest =
</span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>you guys =
separate GMPLS
(transport portion) as two drafts:</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp; 1. Standard draft: =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
portion spec
is based on current ITU/T1X1 transport standard, and agreed =
by</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all =
you
people. This draft can get into last call now without delaying =
GMPLS</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
progress.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp; 2. Non-standard =
draft:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
is for
people who are working on innovation/revolution/evolution for =
next</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
generation
transport. Eventually it may be merged into GMPLS if can =
get</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
industry
acceptance.</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Doing so we can avoid endless discussion =
without
getting any significant progress,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>also we give the implementation =
flexibility to
vendor/carrier. In their PICS (Protocol</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Implementation Conformation =
Specification), if they
only implement standard portion,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>they simply reference to GMPLS RFC. If =
they
implement both, they reference to</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>GMPLS RFC and X-draft for interworking =
purpose.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp; Regards,&nbsp;&nbsp; =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblue face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:blue'>G.Q =
Wang</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:blue'>Emerging
Network Technology</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3D"Comic Sans MS"><span
style=3D'font-size:10.0pt;font-family:"Comic Sans =
MS";color:blue'>Nortel Networks</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Tel: (613)765-4195 (ESN =
395-4195)</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>Fax: (613)768-1140</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[email-masked]</span></font><=
font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black'>-----Original
Message-----</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><b><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:
7.5pt;font-family:Arial;color:black;font-weight:bold'>From:&nbsp;&nbsp;<=
/span></font></b><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Lyndon
Ong [SMTP:[email-masked]]</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><b><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:
7.5pt;font-family:Arial;color:black;font-weight:bold'>Sent:&nbsp;&nbsp;<=
/span></font></b><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Friday,
May 25, 2001 1:25 AM</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><b><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:
7.5pt;font-family:Arial;color:black;font-weight:bold'>To:&nbsp;&nbsp;&nb=
sp;&nbsp;</span></font></b><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Zhi-Wei
Lin; John Drake</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><b><font size=3D1 color=3Dblack face=3DArial><span =
style=3D'font-size:
7.5pt;font-family:Arial;color:black;font-weight:bold'>Cc:&nbsp;&nbsp;&nb=
sp;&nbsp;</span></font></b><font
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;color:black'>'Eve
Varma'; Mannie, Eric; Wang, Guo-Qiang [KAN:0V10:EXCH]; =
[email-masked];
[email-masked]; q11/15; t1x1.5</span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><b><font size=3D1 color=3Dblack =
face=3DArial><span
style=3D'font-size:7.5pt;font-family:Arial;color:black;font-weight:bold'=
>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span></font></b><fo=
nt
color=3Dblack><span style=3D'color:black'> </span></font><font size=3D1 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:7.5pt;font-family:Arial;color:black'>Re:
[T1X1.5] RE: [IP-Optical] Re: Proposed text for the =
concatenation</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Zhi-Wei,</span>=
</font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>First of all, =
I hope
that you agree that having this exchange is a good</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>indication that this is a &quot;fair and =
open
process&quot;.&nbsp; I'm surprised that this</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>should be in question, given that we =
progress
via consensus (OK, &quot;rough&quot;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>consensus) like many other standards =
bodies.</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Secondly, part =
of the
problem is that I would interpret &quot;proprietary&quot; =
as</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>meaning &quot;exclusive&quot;, that is,
intending to have exclusive control over some</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>technology (close to the dictionary
definition).&nbsp; I believe you interpret </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&quot;proprietary&quot;</span></font><fon=
t
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>as something that has not been commonly =
defined
in ITU (or other accredited </span></font><font color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>bodies).</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>Maybe &quot;non-standard&quot; would be =
a more
neutral term.</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Something like =
the
arbitrary concatenation we have been talking about =
is,</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>I think, the latter case - it is not =
exclusive
technology, but it is </span></font><font color=3Dblack><span =
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>relatively</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>new and not everyone has taken advantage =
of
it.&nbsp; Our goal should be to</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>achieve interoperability for such =
features, not
to prohibit them.&nbsp; Agreeing</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>in common on how to identify them in =
signaling
seems like a good step.</span></font><font color=3Dblack><span =
style=3D'color:black'>
</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Cheers,</span><=
/font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>Lyndon</span></=
font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p class=3DMsoNormal style=3D'margin-left:1.0in'><font size=3D3 =
color=3Dblack
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

<p style=3D'margin-left:1.0in'><font size=3D2 color=3Dblack =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:black'>At 05:25 PM =
5/24/2001
-0400, Zhi-Wei Lin wrote:</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;I feel that I should at least try to =
explain
my comments since people</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;may =
mis-interpret.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;As I said several emails ago, and =
have sort
of repeated...we can move in</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;any direction as long as we make =
CLEAR what the
method is for</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;evaluating.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;I did not try to denigrate, nor =
belittle the
work of the numerous</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;authors. In fact I highly respect =
many of
the authors of the documents.</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;Maybe my analogies are too strong, =
in that
case I apologize. But the</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;fact remains that we seem to be =
looking at
this from different angles</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;and thus causing all the =
discussions. I
think the reason is that we all</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;have different backgrounds and =
different
understanding of some basic</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;terms.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;My proposal is to outline the =
specific
metrics used for including and</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;excluding the features, add the =
metric as
part of the document so that a</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;person picking up the document =
understands
the rationales behind this,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;and list ALL the assumptions and =
limitations
of the documents so that</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;there is no =
misunderstanding.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;For example, are these the metrics =
for
including features?????</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;* There must be at least 2 vendors =
that
support a feature. In that case,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;we need to quantify or show that =
this is
indeed the case. Making claims</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;without substantiation IMO would not =
help...</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;* There must be at least one =
operator asking
for the feature.</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;* For each feature identified that =
are
extensions of the standards, do</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;we need to describe what it is, how =
it
functions, what is needed to</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;interoperate, what impacts it has on =
current
networks, does it work with</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;current networks, what is the scope =
of the
feature (network-wide or</span></font><font color=3Dblack><span =
style=3D'color:
black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;enterprise only), is there any =
security
considerations (allows malicious</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;users to gain free service), etc. =
etc...</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;OR maybe the metrics may =
be:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;* All features in the main body =
should
conform to standards.</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;* Any other features not part of =
standards
may be described in an</span></font><font color=3Dblack><span =
style=3D'color:black'>
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;appendix, but no codepoints are =
assigned.
Reserve a range of codepoints</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;for proprietary =
extensions</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;OR any other metrics that may be =
used. But
we HAVE to enumerate this so</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;that the telecom/internet community =
can look
upon this and say, &quot;yes,</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;this was a fair and open process =
where any
vendor or operator can apply</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;the metrics to any feature without =
any
subjective decision being made</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;against any =
feature&quot;...</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;Zhi</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;John Drake wrote:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Eve,</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Okay, for the sake of =
discussion,
we'll assume that the last two thirds of</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; the e-mail</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; don't exist and focus on the =
first
third:</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &quot;As for how many vendor =
is needed
for a standard. Again this question</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; doesn't really apply. We as =
engineers
and the development community has</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; to study a problem to make =
sure that
it will not unduly impact existing</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; networks, that what we are =
looking at
should be sound and technically</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; superior and that it will help =
provide
added value to networks. As these</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; transport capabilities will =
likely
require people of transport expertise</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; to study first, that's what we =
should
do. Let's not get too &quot;trigger</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; happy&quot; and include =
something
&quot;just because it's there&quot;, and then decide</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; to remove when &quot;standards =
say
no&quot;. That like &quot;putting the cart in front</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; of the =
horse&quot;.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; The way I read this, it says =
to me
that the people involved in working on</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; draft are unqualifed to be =
working on
it and that none of the work that </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; they</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; have</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; done over the past year is of =
any
value, so my earlier comments still</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; obtain.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Furthermore, your comments =
about
slippery slope disturb me because they</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; follow</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; a pattern of filibustering and
dissemination of FUD which seems to be aimed</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; at</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; preventing forward =
progress.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Thanks,</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; John</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; -----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; From: Eve Varma [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</span></=
font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Sent: Thursday, May 24, 2001 =
10:30 AM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; To: John =
Drake</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Cc: 'Zhi-Wei Lin'; Mannie, =
Eric;
'Guo-Qiang Wang'; [email-masked];</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; =
[email-masked];
q11/15; t1x1.5</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Subject: Re: [T1X1.5] RE: =
[IP-Optical]
Re: Proposed text for the</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; =
concatenation</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; Hi all,</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; I don't think Zhi had any =
intent to
denigrate other individuals whose</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; names were on the draft (in =
fact,
several have expressed similar</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; concerns).&nbsp; I think the =
key point
was in the earlier part of the</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; message; as expressed in an =
earlier
message from Juergen Heiles, there's</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; considerable concern that =
we're descending
a slippery slope that could</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; ultimately have negative =
impacts.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Cheers,</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt;
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;
Eve</span></font><font color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; John Drake =
wrote:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; I find this message to be =
very
puzzling.&nbsp; As far as I know, the </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; authors as</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; a</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; group are extremely =
conversant
with the</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; subject matter in the =
draft and
the draft represents their best current</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; thinking.&nbsp; You seem =
to be
trying disparage them because you don't agree</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; with</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; their solution, and I =
think that
that is extremely unprofessional.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; The authors spent a long =
time
working out the details of what is </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; presented</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; in the draft, which you =
airily
dismiss with:</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &quot;As to how many =
companies
and how many people's names are on the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; contribution. Let's be
intelligent adults here. As someone once asked</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; me, &quot;if you see a =
million
flies eating feces, would you also eat?&quot;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; (sorry people! it is =
disgusting
but I had to give an extreme analogy).</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Sometimes the majority =
may not be
correct. I am not saying I am correct</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; either. It all depends on =
the
background knowledge base and the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; underlying motive of the
people...&quot;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &quot;As to how many =
processes
followed, how many meetings held, how many</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; conferences given, how =
many
emails exchanged...an idea doesn't get</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; better with repetition. =
As
someone once said at some standards meeting</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &quot;if an idea stinks, =
it
doesn't matter how many times some idea is</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; presented, it still =
stinks that
many times&quot;. So the number of times is</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; not a reason for making a
decision.&quot;</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; If you're not happy with =
the
draft, you are perfectly free to remove your</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; name from it, but don't =
denigrate
the other</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; =
authors.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; John</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; -----Original =
Message-----</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; From: Zhi-Wei Lin [<a
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]</span></fo=
nt><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Sent: Wednesday, May 23, =
2001
8:38 PM</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; To: Mannie, =
Eric</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Cc: 'Guo-Qiang Wang';
[email-masked];</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; =
[email-masked];
q11/15; t1x1.5</span></font><font color=3Dblack><span =
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Subject: Re: [IP-Optical] =
Re:
Proposed text for the concatenation</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Hi,</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; I think your questions =
cannot be
answered either way. Whether features</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; are needed for one or two =
vendors
is up to each vendor to decide what</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; they =
want.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; As for how many vendor is =
needed
for a standard. Again this question</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; doesn't really apply. We =
as
engineers and the development community has</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; to study a problem to =
make sure
that it will not unduly impact existing</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; networks, that what we =
are
looking at should be sound and technically</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; superior and that it will =
help
provide added value to networks. As these</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; transport capabilities =
will
likely require people of transport expertise</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; to study first, that's =
what we
should do. Let's not get too &quot;trigger</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; happy&quot; and include =
something
&quot;just because it's there&quot;, and then decide</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; to remove when =
&quot;standards
say no&quot;. That like &quot;putting the cart in =
front</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; of the =
horse&quot;.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; As to how many companies =
and how
many people's names are on the</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; contribution. Let's be
intelligent adults here. As someone once asked</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; me, &quot;if you see a =
million
flies eating feces, would you also eat?&quot;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; (sorry people! it is =
disgusting
but I had to give an extreme analogy).</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Sometimes the majority =
may not be
correct. I am not saying I am correct</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; either. It all depends on =
the
background knowledge base and the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; underlying motive of the
people...</span></font><font color=3Dblack><span style=3D'color:black'> =
<br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; As to how many processes
followed, how many meetings held, how many</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; conferences given, how =
many
emails exchanged...an idea doesn't get</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; better with repetition. =
As
someone once said at some standards meeting</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &quot;if an idea stinks, =
it
doesn't matter how many times some idea is</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; presented, it still =
stinks that
many times&quot;. So the number of times is</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; not a reason for making a =
decision.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; Let's be technical, let =
the
experts in the right group decide, and we</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; should not jump the gun. =
Let's be
adults and let's help make the telecom</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; industry and the =
standards
process a respectable place...</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &quot;Mannie, Eric&quot; =
wrote:</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt;</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; I don't work for a =
vendor
:-) Who told you that some features are </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; needed</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; only for one or two =
vendors
? How do you quantify the number of vendors</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; that</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; are needed to have a
standard ? We work on a consensus based and this</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; draft</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; has 17 companies on =
it with
30 people. Usually it is much much less at</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; the</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; IETF, you only have =
a small
number of co-authors. I already gave a</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; summary</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; of the process that =
we
followed, all the meetings that we hold, all the</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; conference call that =
we
hold, all the e-mails that we exchanged, etc.</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; You described one =
model in
your e-mail, that's a valid model but </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; this is</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; not</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; THE (only) model. =
There are
plenty of other models that can be </span></font><font =
color=3Dblack><span
style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; fulfilled</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; with =
GMPLS.</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; Kind =
regards,</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt;</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt; =
Eric</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:black'>&gt; &gt; &gt; &gt;</span></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font>=
</p>

</div>

</body>

</html>

------_=_NextPart_001_01C0E537.19EC4350--

------_=_NextPart_000_01C0E537.19EC4350
Content-Type: application/octet-stream;
	name="image001.wmz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="image001.wmz"
Content-ID: <[email-masked]>

------_=_NextPart_000_01C0E537.19EC4350
Content-Type: image/gif;
	name="image002.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="image002.gif"
Content-ID: <[email-masked]>

------_=_NextPart_000_01C0E537.19EC4350--

Delivery-date: Fri, 25 May 2001 09:28:51 -0700
Date: Fri, 25 May 2001 18:20:50 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Brungard, Deborah A" <[email-masked]>
CC: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding type

This is a multi-part message in MIME format.
--------------C8067C0D9D561B851EA38B8A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

You concerns on G.709 OTN have been addressed in the corresponding
technology specific document (new version to be published very soon).

In order to make the distinction between the electrical and optical
hierarchy through the corresponding networking layers (i.e. ODUk and
OCh), we defined a G.709 DW (the ODUk layer) and G.709 OCh. While 
taking into account non-standard DW and Lambda (i.e. pre-OTN when
using the ITU/T1 terminology).

Hope this clarifies the situation at least for this specific point.

Regards,
Dimitri.

"Brungard, Deborah A" wrote:
> 
> All,
> 
> (I've changed the subject field to signal a "switch" of topics - and kept
> q11 and t1x15 lists as the mail is related to their subject areas)
> 
> I also had some questions/comments on the LSP encoding types- section 3.1.1-
> 
> can someone explain why different values are used for different versions of
> T1.105 and G.707? The later versions contain updates to include OC-768 and
> new functions e.g. FEC, J0 support of 16-byte in addition to previous 1-byte
> version, etc. One can not assume equipment supports all functions described
> in any of the versions; one can only assume if the function is supported, it
> is supported as defined. Example, equipment "supporting" T1.105 '95 may not
> support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
> "SONET" functionality. One code seems sufficient for SDH/SONET. Any
> "supporting" details/references can be addressed in the technology specific
> documents.
> 
> Similar comment for PDH - E1 services are supported in the U.S. and 45M are
> supported in Europe. One code can be used: PDH.
> 
> For the digital wrapper code, reference is OTN(G.709). OTN is not just the
> digital wrapper - G709 defines a hierarchy: optical and electrical. Reading
> the attached mail, on waveband switching and assigning Lambda as an LSP
> type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
> Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
> functionality for OTN signals - it is different from today's SONET/metro WDM
> equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in the
> OTN technology specific document.
> 
> Probably should include LSP ranges for future items (and proprietary?).
> 
> Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc. SONET),
> OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).
> 
> The G-PID has discrete values for DS1, DS3 whereas only one value for all
> STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
> others supported, and no SDH VC-4. The G-PID seems to be redundant info with
> the technology specific parameters - is there a reason to support this in
> the generalized label request?
> 
> Regards,
> Deborah Brungard
> AT&T
> 
> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 10:25 AM
> To: 'Yuri Landry'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Yuri,
> 
> I've attached a private note I sent to Dimitri regarding waveband switching.
> It was originally put in at the suggestion of NorTel.  For both waveband
> switching and fiber switching, you are dealing with a situation in which you
> are using a standardized control plane to establish a multi-hop LSP with
> proprietary encoding of data.  As I mentioned, this would be accomplished
> using link coloring.
> 
> Personally, I have no problem removing either waveband switching or fiber
> switching, but we know have to accomodate them wrt the control plane, and I
> seriously doubt that there will ever be a completely non-proprietary of
> encoding the data for these types of LSPs.
> 
> Note that I am using 'proprietary' in the exclusive sense.
> 
> Thanks,
> 
> John
> -----Original Message-----
> From: John Drake
> Sent: Wednesday, March 28, 2001 11:15 AM
> To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
> Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> 
> Dimitri.
> 
> It's probably better to think of waveband switching as a special form of
> fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
> Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
> switching case, the fiber between the DWDM system and a port on the PXC
> contains the entire set of lambdas, while in the waveband switching case
> there is a set of fibers between the DWDM system and a set of ports on the
> PXC, each of which contains a separate waveband.
> 
> In either case, the encoding of the signal on the fibers is completely
> proprietary, and it's the job of routing to ensure that a correct path
> through the network is obtained, such that the proprietary encoding is
> maintained end-end.  This would probably be done through link coloring, so
> that you only route across links that support NorTel waveband switching or
> Tellabs waveband switching.
> 
> So I think the signalling stuff is fine.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Yuri Landry [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 7:02 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatena tion
> 
> Hello All,
> 
> So far, our discussions are focusing on the SONET/SDH draft. I'd like to
> re-direct your attention to other drafts. Rob's suggestion should apply to
> other drafts too.
> 
> One example, is the waveband switching and waveband label a standard or
> proprietary? Can author explain to me what exactly they means? How do they
> work? Any other standard reference? There are questions about it but no
> answer yet.
> 
> Regards,
> 
> Yuri.
> 
> >From: "Lazer, Monica A, NNAD" <[email-masked]>
> >To: "'Rob Coltun'" <[email-masked]>, [email-masked],
> >[email-masked], q11/15 <[email-masked]>,   "t1x1.5"
> ><[email-masked]>
> >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena
> >tion
> >Date: Thu, 24 May 2001 18:11:36 -0400
> >
> >
> >Rob, You proposal makes a lot of sense. Having the signaling standard
> >support proprietary transport may jeopardize interoperability. The issue is
> >not about GMPLS supporting non-standard rates, the issue is about putting
> >in
> >formal and very specific support for a proprietary transport solution in a
> >standard document for signaling without taking the transport portion to a
> >standards body. Having formal signaling support for a proprietary
> >concatenation may cause interoperability issues when other vendors have a
> >different solution to the concatenation and while the signaling would
> >indicate the concatenation, the actual transport may not work.   On the
> >other hand we recognize that there may be a need for some interim support
> >for proprietary solutions.
> >
> >
> >Eric,
> >Below I have some additional specific comments for the document GMPLS
> >Extensions for SONET and SDH Control
> >
> >
> >CCT field (3 bits)
> >Since arbitrary contiguous concatenation is not a standard concatenation,
> >it
> >falls within the vendor proprietary set of solutions.
> >
> >So the CCT bits may be used as follows:
> >000    No contiguous concatenation requested
> >001    Standard contiguous concatenation
> >others Vendor specific contiguous concatenation
> >
> >Alternatively, a better solution is to use only 2 bits for this field and
> >use one bit to show whether contiguous concatenation is requested and the
> >second bit to show whether it is standard or non-standard contiguous
> >concatenation.
> >
> >
> >NCC field (16 bits)
> >This information is not sufficient.
> >NCC needs better description than a zero or non-zero number.
> >
> >SDH and SONET Labels
> >
> >Text in this section (Section 3, paragraphs 5 and 6) indicates that the
> >GMPLS proposal limits virtual concatenation to remain within a single
> >(component) link. If I understand this correctly, it means that GMPLS will
> >not allow inverse multiplexing (virtual concatenation) in the transport
> >plane if it requires different component links. This is too limiting.
> >
> >Annex 1 (sent out by Eric Mannie on 5/22)
> >Defines another type of concatenation - Flexible arbitrary contiguous
> >concatenation without describing precisely how it affects the OH bits. This
> >means that it will be impossible to have this type of concatenation in a
> >multi vendor environment based only on the GMPLS signaling. If the
> >transport
> >plane is proprietary, having the option in the signaling message will not
> >fix the interoperability problem between two different vendors supporting
> >their proprietary versions of arbitrary concatenation.
> >
> >Annex 2 (sent out by Eric Mannie on 5/22)
> >Arbitrary contiguous concatenation needs definition work for
> >interoperability.
> >Flexible arbitrary contiguous concatenation may be available today to
> >support contiguous signals, but it is not defined in the current standards.
> >Clear agreements on OH usage are needed between supporting vendors.
> >Maintenance and tracking of the signal needs to be well understood.
> >
> >
> >
> >Monica A. Lazer
> >Advanced Transport Technology and Architecture Planning
> >
> >908 234 8462
> >[email-masked]
> >
> >
> >-----Original Message-----
> >From: Rob Coltun [mailto:[email-masked]]
> >Sent: Thursday, May 24, 2001 7:24 PM
> >To: [email-masked]; [email-masked]; q11/15; t1x1.5
> >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> >concatenation
> >
> >All,
> >     despite the heated arguments I think the discussion is important to
> >have.
> >
> >I suggest that instead of  tagging non/pre-standard items in the current
> >drafts
> >that they be put into a separate Informational document  - this is the
> >cleanest thing to do.
> >We (the IETF) do have a tradition of publishing company proprietary
> >protocols
> >but not as standard track documents.
> >
> >thanks,
> >---rob
> >
> >
> >
> >_______________________________________________
> >IP-Optical mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------C8067C0D9D561B851EA38B8A
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------C8067C0D9D561B851EA38B8A--

Delivery-date: Fri, 25 May 2001 09:06:06 -0700
From: "Brungard, Deborah A" <[email-masked]>
To: "'John Drake'" <[email-masked]>, "'Yuri Landry'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for LSP encoding  type
Date: Fri, 25 May 2001 11:58:23 -0400

All,

(I've changed the subject field to signal a "switch" of topics - and kept
q11 and t1x15 lists as the mail is related to their subject areas)

I also had some questions/comments on the LSP encoding types- section 3.1.1-

can someone explain why different values are used for different versions of
T1.105 and G.707? The later versions contain updates to include OC-768 and
new functions e.g. FEC, J0 support of 16-byte in addition to previous 1-byte
version, etc. One can not assume equipment supports all functions described
in any of the versions; one can only assume if the function is supported, it
is supported as defined. Example, equipment "supporting" T1.105 '95 may not
support J0 or support both 1-byte and 16-byte J0. Also, G.707 includes
"SONET" functionality. One code seems sufficient for SDH/SONET. Any
"supporting" details/references can be addressed in the technology specific
documents.

Similar comment for PDH - E1 services are supported in the U.S. and 45M are
supported in Europe. One code can be used: PDH.

For the digital wrapper code, reference is OTN(G.709). OTN is not just the
digital wrapper - G709 defines a hierarchy: optical and electrical. Reading
the attached mail, on waveband switching and assigning Lambda as an LSP
type, LSPs need to distinguish Lambda LSPs of "undefined" structure and
Lambda LSPs of G.709 signals. G.709 (OTN) defines wavelength connection
functionality for OTN signals - it is different from today's SONET/metro WDM
equipment(referred to as pre-OTN). G.709 Lambdas (OCh) can be covered in the
OTN technology specific document.

Probably should include LSP ranges for future items (and proprietary?).

Suggest the following as LSP types: packet, ethernet, PDH, SDH (inc. SONET),
OTN (G.709), Lambda (pre-OTN), Fiber, xxx (future).

The G-PID has discrete values for DS1, DS3 whereas only one value for all
STSs - a reason? Same for bandwidth encoding - one value for STS-1, no
others supported, and no SDH VC-4. The G-PID seems to be redundant info with
the technology specific parameters - is there a reason to support this in
the generalized label request?

Regards,
Deborah Brungard
AT&T

-----Original Message-----
From: John Drake [mailto:[email-masked]]
Sent: Friday, May 25, 2001 10:25 AM
To: 'Yuri Landry'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

Yuri,

I've attached a private note I sent to Dimitri regarding waveband switching.
It was originally put in at the suggestion of NorTel.  For both waveband
switching and fiber switching, you are dealing with a situation in which you
are using a standardized control plane to establish a multi-hop LSP with
proprietary encoding of data.  As I mentioned, this would be accomplished
using link coloring.

Personally, I have no problem removing either waveband switching or fiber
switching, but we know have to accomodate them wrt the control plane, and I
seriously doubt that there will ever be a completely non-proprietary of
encoding the data for these types of LSPs.

Note that I am using 'proprietary' in the exclusive sense.

Thanks,

John
-----Original Message-----
From: John Drake 
Sent: Wednesday, March 28, 2001 11:15 AM
To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
Subject: RE: Waveband Switching (was Re: GMPLS signaling)

Dimitri.

It's probably better to think of waveband switching as a special form of
fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
switching case, the fiber between the DWDM system and a port on the PXC
contains the entire set of lambdas, while in the waveband switching case
there is a set of fibers between the DWDM system and a set of ports on the
PXC, each of which contains a separate waveband.

In either case, the encoding of the signal on the fibers is completely
proprietary, and it's the job of routing to ensure that a correct path
through the network is obtained, such that the proprietary encoding is
maintained end-end.  This would probably be done through link coloring, so
that you only route across links that support NorTel waveband switching or
Tellabs waveband switching.

So I think the signalling stuff is fine.

Thanks,

John 

-----Original Message-----
From: Yuri Landry [mailto:[email-masked]]
Sent: Friday, May 25, 2001 7:02 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

Hello All,

So far, our discussions are focusing on the SONET/SDH draft. I'd like to 
re-direct your attention to other drafts. Rob's suggestion should apply to 
other drafts too.

One example, is the waveband switching and waveband label a standard or 
proprietary? Can author explain to me what exactly they means? How do they 
work? Any other standard reference? There are questions about it but no 
answer yet.

Regards,

Yuri.

>From: "Lazer, Monica A, NNAD" <[email-masked]>
>To: "'Rob Coltun'" <[email-masked]>, [email-masked],   
>[email-masked], q11/15 <[email-masked]>,   "t1x1.5"  
><[email-masked]>
>Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena 
>tion
>Date: Thu, 24 May 2001 18:11:36 -0400
>
>
>Rob, You proposal makes a lot of sense. Having the signaling standard
>support proprietary transport may jeopardize interoperability. The issue is
>not about GMPLS supporting non-standard rates, the issue is about putting 
>in
>formal and very specific support for a proprietary transport solution in a
>standard document for signaling without taking the transport portion to a
>standards body. Having formal signaling support for a proprietary
>concatenation may cause interoperability issues when other vendors have a
>different solution to the concatenation and while the signaling would
>indicate the concatenation, the actual transport may not work.   On the
>other hand we recognize that there may be a need for some interim support
>for proprietary solutions.
>
>
>Eric,
>Below I have some additional specific comments for the document GMPLS
>Extensions for SONET and SDH Control
>
>
>CCT field (3 bits)
>Since arbitrary contiguous concatenation is not a standard concatenation, 
>it
>falls within the vendor proprietary set of solutions.
>
>So the CCT bits may be used as follows:
>000	No contiguous concatenation requested
>001	Standard contiguous concatenation
>others	Vendor specific contiguous concatenation
>
>Alternatively, a better solution is to use only 2 bits for this field and
>use one bit to show whether contiguous concatenation is requested and the
>second bit to show whether it is standard or non-standard contiguous
>concatenation.
>
>
>NCC field (16 bits)
>This information is not sufficient.
>NCC needs better description than a zero or non-zero number.
>
>SDH and SONET Labels
>
>Text in this section (Section 3, paragraphs 5 and 6) indicates that the
>GMPLS proposal limits virtual concatenation to remain within a single
>(component) link. If I understand this correctly, it means that GMPLS will
>not allow inverse multiplexing (virtual concatenation) in the transport
>plane if it requires different component links. This is too limiting.
>
>Annex 1 (sent out by Eric Mannie on 5/22)
>Defines another type of concatenation - Flexible arbitrary contiguous
>concatenation without describing precisely how it affects the OH bits. This
>means that it will be impossible to have this type of concatenation in a
>multi vendor environment based only on the GMPLS signaling. If the 
>transport
>plane is proprietary, having the option in the signaling message will not
>fix the interoperability problem between two different vendors supporting
>their proprietary versions of arbitrary concatenation.
>
>Annex 2 (sent out by Eric Mannie on 5/22)
>Arbitrary contiguous concatenation needs definition work for
>interoperability.
>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.
>
>
>
>Monica A. Lazer
>Advanced Transport Technology and Architecture Planning
>
>908 234 8462
>[email-masked]
>
>
>-----Original Message-----
>From: Rob Coltun [mailto:[email-masked]]
>Sent: Thursday, May 24, 2001 7:24 PM
>To: [email-masked]; [email-masked]; q11/15; t1x1.5
>Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
>concatenation
>
>All,
>     despite the heated arguments I think the discussion is important to
>have.
>
>I suggest that instead of  tagging non/pre-standard items in the current
>drafts
>that they be put into a separate Informational document  - this is the
>cleanest thing to do.
>We (the IETF) do have a tradition of publishing company proprietary
>protocols
>but not as standard track documents.
>
>thanks,
>---rob
>
>
>
>_______________________________________________
>IP-Optical mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Fri, 25 May 2001 07:30:17 -0700
From: John Drake <[email-masked]>
To: 'Yuri Landry' <[email-masked]>, [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Fri, 25 May 2001 07:25:06 -0700

Yuri,

I've attached a private note I sent to Dimitri regarding waveband switching.
It was originally put in at the suggestion of NorTel.  For both waveband
switching and fiber switching, you are dealing with a situation in which you
are using a standardized control plane to establish a multi-hop LSP with
proprietary encoding of data.  As I mentioned, this would be accomplished
using link coloring.

Personally, I have no problem removing either waveband switching or fiber
switching, but we know have to accomodate them wrt the control plane, and I
seriously doubt that there will ever be a completely non-proprietary of
encoding the data for these types of LSPs.

Note that I am using 'proprietary' in the exclusive sense.

Thanks,

John
-----Original Message-----
From: John Drake 
Sent: Wednesday, March 28, 2001 11:15 AM
To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; [email-masked]
Subject: RE: Waveband Switching (was Re: GMPLS signaling)

Dimitri.

It's probably better to think of waveband switching as a special form of
fiber switching; i.e., it has nothing to do with the SONET/SDH stuff at all.
Suppose the trunk side of a DWDM system is attached to a PXC.  In the fiber
switching case, the fiber between the DWDM system and a port on the PXC
contains the entire set of lambdas, while in the waveband switching case
there is a set of fibers between the DWDM system and a set of ports on the
PXC, each of which contains a separate waveband.

In either case, the encoding of the signal on the fibers is completely
proprietary, and it's the job of routing to ensure that a correct path
through the network is obtained, such that the proprietary encoding is
maintained end-end.  This would probably be done through link coloring, so
that you only route across links that support NorTel waveband switching or
Tellabs waveband switching.

So I think the signalling stuff is fine.

Thanks,

John 

-----Original Message-----
From: Yuri Landry [mailto:[email-masked]]
Sent: Friday, May 25, 2001 7:02 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatena tion

Hello All,

So far, our discussions are focusing on the SONET/SDH draft. I'd like to 
re-direct your attention to other drafts. Rob's suggestion should apply to 
other drafts too.

One example, is the waveband switching and waveband label a standard or 
proprietary? Can author explain to me what exactly they means? How do they 
work? Any other standard reference? There are questions about it but no 
answer yet.

Regards,

Yuri.

>From: "Lazer, Monica A, NNAD" <[email-masked]>
>To: "'Rob Coltun'" <[email-masked]>, [email-masked],   
>[email-masked], q11/15 <[email-masked]>,   "t1x1.5"  
><[email-masked]>
>Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena 
>tion
>Date: Thu, 24 May 2001 18:11:36 -0400
>
>
>Rob, You proposal makes a lot of sense. Having the signaling standard
>support proprietary transport may jeopardize interoperability. The issue is
>not about GMPLS supporting non-standard rates, the issue is about putting 
>in
>formal and very specific support for a proprietary transport solution in a
>standard document for signaling without taking the transport portion to a
>standards body. Having formal signaling support for a proprietary
>concatenation may cause interoperability issues when other vendors have a
>different solution to the concatenation and while the signaling would
>indicate the concatenation, the actual transport may not work.   On the
>other hand we recognize that there may be a need for some interim support
>for proprietary solutions.
>
>
>Eric,
>Below I have some additional specific comments for the document GMPLS
>Extensions for SONET and SDH Control
>
>
>CCT field (3 bits)
>Since arbitrary contiguous concatenation is not a standard concatenation, 
>it
>falls within the vendor proprietary set of solutions.
>
>So the CCT bits may be used as follows:
>000	No contiguous concatenation requested
>001	Standard contiguous concatenation
>others	Vendor specific contiguous concatenation
>
>Alternatively, a better solution is to use only 2 bits for this field and
>use one bit to show whether contiguous concatenation is requested and the
>second bit to show whether it is standard or non-standard contiguous
>concatenation.
>
>
>NCC field (16 bits)
>This information is not sufficient.
>NCC needs better description than a zero or non-zero number.
>
>SDH and SONET Labels
>
>Text in this section (Section 3, paragraphs 5 and 6) indicates that the
>GMPLS proposal limits virtual concatenation to remain within a single
>(component) link. If I understand this correctly, it means that GMPLS will
>not allow inverse multiplexing (virtual concatenation) in the transport
>plane if it requires different component links. This is too limiting.
>
>Annex 1 (sent out by Eric Mannie on 5/22)
>Defines another type of concatenation - Flexible arbitrary contiguous
>concatenation without describing precisely how it affects the OH bits. This
>means that it will be impossible to have this type of concatenation in a
>multi vendor environment based only on the GMPLS signaling. If the 
>transport
>plane is proprietary, having the option in the signaling message will not
>fix the interoperability problem between two different vendors supporting
>their proprietary versions of arbitrary concatenation.
>
>Annex 2 (sent out by Eric Mannie on 5/22)
>Arbitrary contiguous concatenation needs definition work for
>interoperability.
>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.
>
>
>
>Monica A. Lazer
>Advanced Transport Technology and Architecture Planning
>
>908 234 8462
>[email-masked]
>
>
>-----Original Message-----
>From: Rob Coltun [mailto:[email-masked]]
>Sent: Thursday, May 24, 2001 7:24 PM
>To: [email-masked]; [email-masked]; q11/15; t1x1.5
>Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
>concatenation
>
>All,
>     despite the heated arguments I think the discussion is important to
>have.
>
>I suggest that instead of  tagging non/pre-standard items in the current
>drafts
>that they be put into a separate Informational document  - this is the
>cleanest thing to do.
>We (the IETF) do have a tradition of publishing company proprietary
>protocols
>but not as standard track documents.
>
>thanks,
>---rob
>
>
>
>_______________________________________________
>IP-Optical mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 25 May 2001 07:08:05 -0700
From: John Drake <[email-masked]>
To: 'Lyndon Ong' <[email-masked]>, Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>
Cc: 'Eve Varma' <[email-masked]>, "Mannie, Eric" <[email-masked]>, 'Guo-Qiang Wang' <[email-masked]>,  [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Fri, 25 May 2001 07:02:07 -0700

Nice note. I agree

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 10:25 PM
To: Zhi-Wei Lin; John Drake
Cc: 'Eve Varma'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

Zhi-Wei,

First of all, I hope that you agree that having this exchange is a good
indication that this is a "fair and open process".  I'm surprised that this
should be in question, given that we progress via consensus (OK, "rough"
consensus) like many other standards bodies.

Secondly, part of the problem is that I would interpret "proprietary" as
meaning "exclusive", that is, intending to have exclusive control over some
technology (close to the dictionary definition).  I believe you interpret 
"proprietary"
as something that has not been commonly defined in ITU (or other accredited 
bodies).
Maybe "non-standard" would be a more neutral term.

Something like the arbitrary concatenation we have been talking about is,
I think, the latter case - it is not exclusive technology, but it is 
relatively
new and not everyone has taken advantage of it.  Our goal should be to
achieve interoperability for such features, not to prohibit them.  Agreeing
in common on how to identify them in signaling seems like a good step.

Cheers,

Lyndon

At 05:25 PM 5/24/2001 -0400, Zhi-Wei Lin wrote:
>I feel that I should at least try to explain my comments since people
>may mis-interpret.
>
>As I said several emails ago, and have sort of repeated...we can move in
>any direction as long as we make CLEAR what the method is for
>evaluating.
>
>I did not try to denigrate, nor belittle the work of the numerous
>authors. In fact I highly respect many of the authors of the documents.
>Maybe my analogies are too strong, in that case I apologize. But the
>fact remains that we seem to be looking at this from different angles
>and thus causing all the discussions. I think the reason is that we all
>have different backgrounds and different understanding of some basic
>terms.
>
>My proposal is to outline the specific metrics used for including and
>excluding the features, add the metric as part of the document so that a
>person picking up the document understands the rationales behind this,
>and list ALL the assumptions and limitations of the documents so that
>there is no misunderstanding.
>
>For example, are these the metrics for including features?????
>
>* There must be at least 2 vendors that support a feature. In that case,
>we need to quantify or show that this is indeed the case. Making claims
>without substantiation IMO would not help...
>* There must be at least one operator asking for the feature.
>* For each feature identified that are extensions of the standards, do
>we need to describe what it is, how it functions, what is needed to
>interoperate, what impacts it has on current networks, does it work with
>current networks, what is the scope of the feature (network-wide or
>enterprise only), is there any security considerations (allows malicious
>users to gain free service), etc. etc...
>
>OR maybe the metrics may be:
>
>* All features in the main body should conform to standards.
>* Any other features not part of standards may be described in an
>appendix, but no codepoints are assigned. Reserve a range of codepoints
>for proprietary extensions
>
>
>OR any other metrics that may be used. But we HAVE to enumerate this so
>that the telecom/internet community can look upon this and say, "yes,
>this was a fair and open process where any vendor or operator can apply
>the metrics to any feature without any subjective decision being made
>against any feature"...
>
>
>Zhi
>
>
>
>John Drake wrote:
> >
> > Eve,
> >
> > Okay, for the sake of discussion, we'll assume that the last two thirds
of
> > the e-mail
> > don't exist and focus on the first third:
> >
> > "As for how many vendor is needed for a standard. Again this question
> > doesn't really apply. We as engineers and the development community has
> > to study a problem to make sure that it will not unduly impact existing
> > networks, that what we are looking at should be sound and technically
> > superior and that it will help provide added value to networks. As these
> > transport capabilities will likely require people of transport expertise
> > to study first, that's what we should do. Let's not get too "trigger
> > happy" and include something "just because it's there", and then decide
> > to remove when "standards say no". That like "putting the cart in front
> > of the horse".
> >
> > The way I read this, it says to me that the people involved in working
on
> > the
> > draft are unqualifed to be working on it and that none of the work that 
> they
> > have
> > done over the past year is of any value, so my earlier comments still
> > obtain.
> >
> > Furthermore, your comments about slippery slope disturb me because they
> > follow
> > a pattern of filibustering and dissemination of FUD which seems to be
aimed
> > at
> > preventing forward progress.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Eve Varma [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 10:30 AM
> > To: John Drake
> > Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
> > [email-masked]; q11/15; t1x1.5
> > Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatenation
> >
> > Hi all,
> >
> > I don't think Zhi had any intent to denigrate other individuals whose
> > names were on the draft (in fact, several have expressed similar
> > concerns).  I think the key point was in the earlier part of the
> > message; as expressed in an earlier message from Juergen Heiles, there's
> > considerable concern that we're descending a slippery slope that could
> > ultimately have negative impacts.
> >
> >                        Cheers,
> >                             Eve
> >
> > John Drake wrote:
> > >
> > > I find this message to be very puzzling.  As far as I know, the 
> authors as
> > a
> > > group are extremely conversant with the
> > > subject matter in the draft and the draft represents their best
current
> > > thinking.  You seem to be trying disparage them because you don't
agree
> > with
> > > their solution, and I think that that is extremely unprofessional.
> > >
> > > The authors spent a long time working out the details of what is 
> presented
> > > in the draft, which you airily dismiss with:
> > >
> > > "As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am
correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people..."
> > >
> > > "As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision."
> > >
> > > If you're not happy with the draft, you are perfectly free to remove
your
> > > name from it, but don't denigrate the other
> > > authors.
> > >
> > > John
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > Sent: Wednesday, May 23, 2001 8:38 PM
> > > To: Mannie, Eric
> > > Cc: 'Guo-Qiang Wang'; [email-masked];
> > > [email-masked]; q11/15; t1x1.5
> > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > Hi,
> > >
> > > I think your questions cannot be answered either way. Whether features
> > > are needed for one or two vendors is up to each vendor to decide what
> > > they want.
> > >
> > > As for how many vendor is needed for a standard. Again this question
> > > doesn't really apply. We as engineers and the development community
has
> > > to study a problem to make sure that it will not unduly impact
existing
> > > networks, that what we are looking at should be sound and technically
> > > superior and that it will help provide added value to networks. As
these
> > > transport capabilities will likely require people of transport
expertise
> > > to study first, that's what we should do. Let's not get too "trigger
> > > happy" and include something "just because it's there", and then
decide
> > > to remove when "standards say no". That like "putting the cart in
front
> > > of the horse".
> > >
> > > As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am
correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people...
> > >
> > > As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision.
> > >
> > > Let's be technical, let the experts in the right group decide, and we
> > > should not jump the gun. Let's be adults and let's help make the
telecom
> > > industry and the standards process a respectable place...
> > >
> > > "Mannie, Eric" wrote:
> > >
> > > > I don't work for a vendor :-) Who told you that some features are 
> needed
> > > > only for one or two vendors ? How do you quantify the number of
vendors
> > > that
> > > > are needed to have a standard ? We work on a consensus based and
this
> > > draft
> > > > has 17 companies on it with 30 people. Usually it is much much less
at
> > the
> > > > IETF, you only have a small number of co-authors. I already gave a
> > summary
> > > > of the process that we followed, all the meetings that we hold, all
the
> > > > conference call that we hold, all the e-mails that we exchanged,
etc.
> > > >
> > > > You described one model in your e-mail, that's a valid model but 
> this is
> > > not
> > > > THE (only) model. There are plenty of other models that can be 
> fulfilled
> > > > with GMPLS.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >

Delivery-date: Fri, 25 May 2001 07:06:43 -0700
From: John Drake <[email-masked]>
To: 'Rob Coltun' <[email-masked]>, [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Fri, 25 May 2001 07:00:28 -0700

Rob,

Why isn't the proposed disclaimer sufficient?  If you look in the base TE
drafts, for example, there are codepoints defined for use by specific,
named, vendors.  I think the same is also true for BGP.

Thanks,

John

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 6:54 PM
To: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

All,
    despite the heated arguments I think the discussion is important to
have.

I suggest that instead of  tagging non/pre-standard items in the current
drafts
that they be put into a separate Informational document  - this is the
cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary
protocols
but not as standard track documents.

thanks,
---rob

Delivery-date: Fri, 25 May 2001 07:03:59 -0700
From: "Yuri Landry" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Fri, 25 May 2001 14:02:13 -0000

Hello All,

So far, our discussions are focusing on the SONET/SDH draft. I'd like to 
re-direct your attention to other drafts. Rob's suggestion should apply to 
other drafts too.

One example, is the waveband switching and waveband label a standard or 
proprietary? Can author explain to me what exactly they means? How do they 
work? Any other standard reference? There are questions about it but no 
answer yet.

Regards,

Yuri.

>From: "Lazer, Monica A, NNAD" <[email-masked]>
>To: "'Rob Coltun'" <[email-masked]>, [email-masked],   
>[email-masked], q11/15 <[email-masked]>,   "t1x1.5"  
><[email-masked]>
>Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena 
>tion
>Date: Thu, 24 May 2001 18:11:36 -0400
>
>
>Rob, You proposal makes a lot of sense. Having the signaling standard
>support proprietary transport may jeopardize interoperability. The issue is
>not about GMPLS supporting non-standard rates, the issue is about putting 
>in
>formal and very specific support for a proprietary transport solution in a
>standard document for signaling without taking the transport portion to a
>standards body. Having formal signaling support for a proprietary
>concatenation may cause interoperability issues when other vendors have a
>different solution to the concatenation and while the signaling would
>indicate the concatenation, the actual transport may not work.   On the
>other hand we recognize that there may be a need for some interim support
>for proprietary solutions.
>
>
>Eric,
>Below I have some additional specific comments for the document GMPLS
>Extensions for SONET and SDH Control
>
>
>CCT field (3 bits)
>Since arbitrary contiguous concatenation is not a standard concatenation, 
>it
>falls within the vendor proprietary set of solutions.
>
>So the CCT bits may be used as follows:
>000	No contiguous concatenation requested
>001	Standard contiguous concatenation
>others	Vendor specific contiguous concatenation
>
>Alternatively, a better solution is to use only 2 bits for this field and
>use one bit to show whether contiguous concatenation is requested and the
>second bit to show whether it is standard or non-standard contiguous
>concatenation.
>
>
>NCC field (16 bits)
>This information is not sufficient.
>NCC needs better description than a zero or non-zero number.
>
>SDH and SONET Labels
>
>Text in this section (Section 3, paragraphs 5 and 6) indicates that the
>GMPLS proposal limits virtual concatenation to remain within a single
>(component) link. If I understand this correctly, it means that GMPLS will
>not allow inverse multiplexing (virtual concatenation) in the transport
>plane if it requires different component links. This is too limiting.
>
>Annex 1 (sent out by Eric Mannie on 5/22)
>Defines another type of concatenation - Flexible arbitrary contiguous
>concatenation without describing precisely how it affects the OH bits. This
>means that it will be impossible to have this type of concatenation in a
>multi vendor environment based only on the GMPLS signaling. If the 
>transport
>plane is proprietary, having the option in the signaling message will not
>fix the interoperability problem between two different vendors supporting
>their proprietary versions of arbitrary concatenation.
>
>Annex 2 (sent out by Eric Mannie on 5/22)
>Arbitrary contiguous concatenation needs definition work for
>interoperability.
>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.
>
>
>
>Monica A. Lazer
>Advanced Transport Technology and Architecture Planning
>
>908 234 8462
>[email-masked]
>
>
>-----Original Message-----
>From: Rob Coltun [mailto:[email-masked]]
>Sent: Thursday, May 24, 2001 7:24 PM
>To: [email-masked]; [email-masked]; q11/15; t1x1.5
>Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
>concatenation
>
>All,
>     despite the heated arguments I think the discussion is important to
>have.
>
>I suggest that instead of  tagging non/pre-standard items in the current
>drafts
>that they be put into a separate Informational document  - this is the
>cleanest thing to do.
>We (the IETF) do have a tradition of publishing company proprietary
>protocols
>but not as standard track documents.
>
>thanks,
>---rob
>
>
>
>_______________________________________________
>IP-Optical mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 25 May 2001 06:57:53 -0700
From: "Yuri Landry" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Fri, 25 May 2001 13:57:04 -0000

I agree!

>
>Rob, You proposal makes a lot of sense. Having the signaling standard
>support proprietary transport may jeopardize interoperability. The issue is
>not about GMPLS supporting non-standard rates, the issue is about putting 
>in
>formal and very specific support for a proprietary transport solution in a
>standard document for signaling without taking the transport portion to a
>standards body. Having formal signaling support for a proprietary
>concatenation may cause interoperability issues when other vendors have a
>different solution to the concatenation and while the signaling would
>indicate the concatenation, the actual transport may not work.   On the
>other hand we recognize that there may be a need for some interim support
>for proprietary solutions.
>
>
>Eric,
>Below I have some additional specific comments for the document GMPLS
>Extensions for SONET and SDH Control
>
>
>CCT field (3 bits)
>Since arbitrary contiguous concatenation is not a standard concatenation, 
>it
>falls within the vendor proprietary set of solutions.
>
>So the CCT bits may be used as follows:
>000	No contiguous concatenation requested
>001	Standard contiguous concatenation
>others	Vendor specific contiguous concatenation
>
>Alternatively, a better solution is to use only 2 bits for this field and
>use one bit to show whether contiguous concatenation is requested and the
>second bit to show whether it is standard or non-standard contiguous
>concatenation.
>
>
>NCC field (16 bits)
>This information is not sufficient.
>NCC needs better description than a zero or non-zero number.
>
>SDH and SONET Labels
>
>Text in this section (Section 3, paragraphs 5 and 6) indicates that the
>GMPLS proposal limits virtual concatenation to remain within a single
>(component) link. If I understand this correctly, it means that GMPLS will
>not allow inverse multiplexing (virtual concatenation) in the transport
>plane if it requires different component links. This is too limiting.
>
>Annex 1 (sent out by Eric Mannie on 5/22)
>Defines another type of concatenation - Flexible arbitrary contiguous
>concatenation without describing precisely how it affects the OH bits. This
>means that it will be impossible to have this type of concatenation in a
>multi vendor environment based only on the GMPLS signaling. If the 
>transport
>plane is proprietary, having the option in the signaling message will not
>fix the interoperability problem between two different vendors supporting
>their proprietary versions of arbitrary concatenation.
>
>Annex 2 (sent out by Eric Mannie on 5/22)
>Arbitrary contiguous concatenation needs definition work for
>interoperability.
>Flexible arbitrary contiguous concatenation may be available today to
>support contiguous signals, but it is not defined in the current standards.
>Clear agreements on OH usage are needed between supporting vendors.
>Maintenance and tracking of the signal needs to be well understood.
>
>
>
>Monica A. Lazer
>Advanced Transport Technology and Architecture Planning
>
>908 234 8462
>[email-masked]
>
>
>-----Original Message-----
>From: Rob Coltun [mailto:[email-masked]]
>Sent: Thursday, May 24, 2001 7:24 PM
>To: [email-masked]; [email-masked]; q11/15; t1x1.5
>Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
>concatenation
>
>All,
>     despite the heated arguments I think the discussion is important to
>have.
>
>I suggest that instead of  tagging non/pre-standard items in the current
>drafts
>that they be put into a separate Informational document  - this is the
>cleanest thing to do.
>We (the IETF) do have a tradition of publishing company proprietary
>protocols
>but not as standard track documents.
>
>thanks,
>---rob
>
>
>
>_______________________________________________
>IP-Optical mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/ip-optical
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 25 May 2001 06:35:52 -0700
Date: Fri, 25 May 2001 09:34:36 -0400
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatenation

Good point.

-- A protocol should provide mechanisms to support company proprietary
extensions. For example, opaque LSA, opaque TLV etc. 
-- But proprietary content shouldn't be treated/presented the same as
standardized materials on standard track document.

Thanks,

Yangguang

Rob Coltun wrote:
> 
> All,
>     despite the heated arguments I think the discussion is important to have.
> 
> I suggest that instead of  tagging non/pre-standard items in the current drafts
> that they be put into a separate Informational document  - this is the cleanest thing to do.
> We (the IETF) do have a tradition of publishing company proprietary protocols
> but not as standard track documents.
> 
> thanks,
> ---rob
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Fri, 25 May 2001 04:01:08 -0700
Date: Fri, 25 May 2001 12:44:13 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Lyndon Ong <[email-masked]>
CC: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, "'Eve Varma'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Guo-Qiang Wang'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for theconcatenation

This is a multi-part message in MIME format.
--------------F71AA06D79D8AB457CB42DCB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Lyndon and Zhi,

I think as well as that "non-standard" is more neutral than 
"proprietary" the latter means that features appearing as 
"sub-features" or give the impression of exclusivity for the
definition and approval of "real features". 

FACC and ACC are good examples today - the only problem related
with these features are "acceptance" by official bodies and 
"interoperability" (signalling vs. transport) even if the proposed
text (see Eric's mail) solve many questions some refinement are 
probably needed. I thought we were in the right direction to 
achieve common understanding at least from the signalling point 
of view with this hotly discussed document. I hope this will 
continue and we will go from a rough consensus to a clear consensus.

- Dimitri.

Lyndon Ong wrote:
> 
> Zhi-Wei,
> 
> First of all, I hope that you agree that having this exchange is a good
> indication that this is a "fair and open process".  I'm surprised that this
> should be in question, given that we progress via consensus (OK, "rough"
> consensus) like many other standards bodies.
> 
> Secondly, part of the problem is that I would interpret "proprietary" as
> meaning "exclusive", that is, intending to have exclusive control over some
> technology (close to the dictionary definition).  I believe you interpret
> "proprietary"
> as something that has not been commonly defined in ITU (or other accredited
> bodies).
> Maybe "non-standard" would be a more neutral term.
> 
> Something like the arbitrary concatenation we have been talking about is,
> I think, the latter case - it is not exclusive technology, but it is
> relatively
> new and not everyone has taken advantage of it.  Our goal should be to
> achieve interoperability for such features, not to prohibit them.  Agreeing
> in common on how to identify them in signaling seems like a good step.
> 
> Cheers,
> 
> Lyndon
> 
> At 05:25 PM 5/24/2001 -0400, Zhi-Wei Lin wrote:
> >I feel that I should at least try to explain my comments since people
> >may mis-interpret.
> >
> >As I said several emails ago, and have sort of repeated...we can move in
> >any direction as long as we make CLEAR what the method is for
> >evaluating.
> >
> >I did not try to denigrate, nor belittle the work of the numerous
> >authors. In fact I highly respect many of the authors of the documents.
> >Maybe my analogies are too strong, in that case I apologize. But the
> >fact remains that we seem to be looking at this from different angles
> >and thus causing all the discussions. I think the reason is that we all
> >have different backgrounds and different understanding of some basic
> >terms.
> >
> >My proposal is to outline the specific metrics used for including and
> >excluding the features, add the metric as part of the document so that a
> >person picking up the document understands the rationales behind this,
> >and list ALL the assumptions and limitations of the documents so that
> >there is no misunderstanding.
> >
> >For example, are these the metrics for including features?????
> >
> >* There must be at least 2 vendors that support a feature. In that case,
> >we need to quantify or show that this is indeed the case. Making claims
> >without substantiation IMO would not help...
> >* There must be at least one operator asking for the feature.
> >* For each feature identified that are extensions of the standards, do
> >we need to describe what it is, how it functions, what is needed to
> >interoperate, what impacts it has on current networks, does it work with
> >current networks, what is the scope of the feature (network-wide or
> >enterprise only), is there any security considerations (allows malicious
> >users to gain free service), etc. etc...
> >
> >OR maybe the metrics may be:
> >
> >* All features in the main body should conform to standards.
> >* Any other features not part of standards may be described in an
> >appendix, but no codepoints are assigned. Reserve a range of codepoints
> >for proprietary extensions
> >
> >
> >OR any other metrics that may be used. But we HAVE to enumerate this so
> >that the telecom/internet community can look upon this and say, "yes,
> >this was a fair and open process where any vendor or operator can apply
> >the metrics to any feature without any subjective decision being made
> >against any feature"...
> >
> >
> >Zhi
> >
> >
> >
> >John Drake wrote:
> > >
> > > Eve,
> > >
> > > Okay, for the sake of discussion, we'll assume that the last two thirds of
> > > the e-mail
> > > don't exist and focus on the first third:
> > >
> > > "As for how many vendor is needed for a standard. Again this question
> > > doesn't really apply. We as engineers and the development community has
> > > to study a problem to make sure that it will not unduly impact existing
> > > networks, that what we are looking at should be sound and technically
> > > superior and that it will help provide added value to networks. As these
> > > transport capabilities will likely require people of transport expertise
> > > to study first, that's what we should do. Let's not get too "trigger
> > > happy" and include something "just because it's there", and then decide
> > > to remove when "standards say no". That like "putting the cart in front
> > > of the horse".
> > >
> > > The way I read this, it says to me that the people involved in working on
> > > the
> > > draft are unqualifed to be working on it and that none of the work that
> > they
> > > have
> > > done over the past year is of any value, so my earlier comments still
> > > obtain.
> > >
> > > Furthermore, your comments about slippery slope disturb me because they
> > > follow
> > > a pattern of filibustering and dissemination of FUD which seems to be aimed
> > > at
> > > preventing forward progress.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Eve Varma [mailto:[email-masked]]
> > > Sent: Thursday, May 24, 2001 10:30 AM
> > > To: John Drake
> > > Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
> > > [email-masked]; q11/15; t1x1.5
> > > Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > concatenation
> > >
> > > Hi all,
> > >
> > > I don't think Zhi had any intent to denigrate other individuals whose
> > > names were on the draft (in fact, several have expressed similar
> > > concerns).  I think the key point was in the earlier part of the
> > > message; as expressed in an earlier message from Juergen Heiles, there's
> > > considerable concern that we're descending a slippery slope that could
> > > ultimately have negative impacts.
> > >
> > >                        Cheers,
> > >                             Eve
> > >
> > > John Drake wrote:
> > > >
> > > > I find this message to be very puzzling.  As far as I know, the
> > authors as
> > > a
> > > > group are extremely conversant with the
> > > > subject matter in the draft and the draft represents their best current
> > > > thinking.  You seem to be trying disparage them because you don't agree
> > > with
> > > > their solution, and I think that that is extremely unprofessional.
> > > >
> > > > The authors spent a long time working out the details of what is
> > presented
> > > > in the draft, which you airily dismiss with:
> > > >
> > > > "As to how many companies and how many people's names are on the
> > > > contribution. Let's be intelligent adults here. As someone once asked
> > > > me, "if you see a million flies eating feces, would you also eat?"
> > > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > > Sometimes the majority may not be correct. I am not saying I am correct
> > > > either. It all depends on the background knowledge base and the
> > > > underlying motive of the people..."
> > > >
> > > > "As to how many processes followed, how many meetings held, how many
> > > > conferences given, how many emails exchanged...an idea doesn't get
> > > > better with repetition. As someone once said at some standards meeting
> > > > "if an idea stinks, it doesn't matter how many times some idea is
> > > > presented, it still stinks that many times". So the number of times is
> > > > not a reason for making a decision."
> > > >
> > > > If you're not happy with the draft, you are perfectly free to remove your
> > > > name from it, but don't denigrate the other
> > > > authors.
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > > Sent: Wednesday, May 23, 2001 8:38 PM
> > > > To: Mannie, Eric
> > > > Cc: 'Guo-Qiang Wang'; [email-masked];
> > > > [email-masked]; q11/15; t1x1.5
> > > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> > > >
> > > > Hi,
> > > >
> > > > I think your questions cannot be answered either way. Whether features
> > > > are needed for one or two vendors is up to each vendor to decide what
> > > > they want.
> > > >
> > > > As for how many vendor is needed for a standard. Again this question
> > > > doesn't really apply. We as engineers and the development community has
> > > > to study a problem to make sure that it will not unduly impact existing
> > > > networks, that what we are looking at should be sound and technically
> > > > superior and that it will help provide added value to networks. As these
> > > > transport capabilities will likely require people of transport expertise
> > > > to study first, that's what we should do. Let's not get too "trigger
> > > > happy" and include something "just because it's there", and then decide
> > > > to remove when "standards say no". That like "putting the cart in front
> > > > of the horse".
> > > >
> > > > As to how many companies and how many people's names are on the
> > > > contribution. Let's be intelligent adults here. As someone once asked
> > > > me, "if you see a million flies eating feces, would you also eat?"
> > > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > > Sometimes the majority may not be correct. I am not saying I am correct
> > > > either. It all depends on the background knowledge base and the
> > > > underlying motive of the people...
> > > >
> > > > As to how many processes followed, how many meetings held, how many
> > > > conferences given, how many emails exchanged...an idea doesn't get
> > > > better with repetition. As someone once said at some standards meeting
> > > > "if an idea stinks, it doesn't matter how many times some idea is
> > > > presented, it still stinks that many times". So the number of times is
> > > > not a reason for making a decision.
> > > >
> > > > Let's be technical, let the experts in the right group decide, and we
> > > > should not jump the gun. Let's be adults and let's help make the telecom
> > > > industry and the standards process a respectable place...
> > > >
> > > > "Mannie, Eric" wrote:
> > > >
> > > > > I don't work for a vendor :-) Who told you that some features are
> > needed
> > > > > only for one or two vendors ? How do you quantify the number of vendors
> > > > that
> > > > > are needed to have a standard ? We work on a consensus based and this
> > > > draft
> > > > > has 17 companies on it with 30 people. Usually it is much much less at
> > > the
> > > > > IETF, you only have a small number of co-authors. I already gave a
> > > summary
> > > > > of the process that we followed, all the meetings that we hold, all the
> > > > > conference call that we hold, all the e-mails that we exchanged, etc.
> > > > >
> > > > > You described one model in your e-mail, that's a valid model but
> > this is
> > > > not
> > > > > THE (only) model. There are plenty of other models that can be
> > fulfilled
> > > > > with GMPLS.
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Eric
> > > > >
--------------F71AA06D79D8AB457CB42DCB
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------F71AA06D79D8AB457CB42DCB--

Delivery-date: Thu, 24 May 2001 22:28:10 -0700
Date: Thu, 24 May 2001 22:25:28 -0700
To: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>
From: Lyndon Ong <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatenation
Cc: "'Eve Varma'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Guo-Qiang Wang'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>

Zhi-Wei,

First of all, I hope that you agree that having this exchange is a good
indication that this is a "fair and open process".  I'm surprised that this
should be in question, given that we progress via consensus (OK, "rough"
consensus) like many other standards bodies.

Secondly, part of the problem is that I would interpret "proprietary" as
meaning "exclusive", that is, intending to have exclusive control over some
technology (close to the dictionary definition).  I believe you interpret 
"proprietary"
as something that has not been commonly defined in ITU (or other accredited 
bodies).
Maybe "non-standard" would be a more neutral term.

Something like the arbitrary concatenation we have been talking about is,
I think, the latter case - it is not exclusive technology, but it is 
relatively
new and not everyone has taken advantage of it.  Our goal should be to
achieve interoperability for such features, not to prohibit them.  Agreeing
in common on how to identify them in signaling seems like a good step.

Cheers,

Lyndon

At 05:25 PM 5/24/2001 -0400, Zhi-Wei Lin wrote:
>I feel that I should at least try to explain my comments since people
>may mis-interpret.
>
>As I said several emails ago, and have sort of repeated...we can move in
>any direction as long as we make CLEAR what the method is for
>evaluating.
>
>I did not try to denigrate, nor belittle the work of the numerous
>authors. In fact I highly respect many of the authors of the documents.
>Maybe my analogies are too strong, in that case I apologize. But the
>fact remains that we seem to be looking at this from different angles
>and thus causing all the discussions. I think the reason is that we all
>have different backgrounds and different understanding of some basic
>terms.
>
>My proposal is to outline the specific metrics used for including and
>excluding the features, add the metric as part of the document so that a
>person picking up the document understands the rationales behind this,
>and list ALL the assumptions and limitations of the documents so that
>there is no misunderstanding.
>
>For example, are these the metrics for including features?????
>
>* There must be at least 2 vendors that support a feature. In that case,
>we need to quantify or show that this is indeed the case. Making claims
>without substantiation IMO would not help...
>* There must be at least one operator asking for the feature.
>* For each feature identified that are extensions of the standards, do
>we need to describe what it is, how it functions, what is needed to
>interoperate, what impacts it has on current networks, does it work with
>current networks, what is the scope of the feature (network-wide or
>enterprise only), is there any security considerations (allows malicious
>users to gain free service), etc. etc...
>
>OR maybe the metrics may be:
>
>* All features in the main body should conform to standards.
>* Any other features not part of standards may be described in an
>appendix, but no codepoints are assigned. Reserve a range of codepoints
>for proprietary extensions
>
>
>OR any other metrics that may be used. But we HAVE to enumerate this so
>that the telecom/internet community can look upon this and say, "yes,
>this was a fair and open process where any vendor or operator can apply
>the metrics to any feature without any subjective decision being made
>against any feature"...
>
>
>Zhi
>
>
>
>John Drake wrote:
> >
> > Eve,
> >
> > Okay, for the sake of discussion, we'll assume that the last two thirds of
> > the e-mail
> > don't exist and focus on the first third:
> >
> > "As for how many vendor is needed for a standard. Again this question
> > doesn't really apply. We as engineers and the development community has
> > to study a problem to make sure that it will not unduly impact existing
> > networks, that what we are looking at should be sound and technically
> > superior and that it will help provide added value to networks. As these
> > transport capabilities will likely require people of transport expertise
> > to study first, that's what we should do. Let's not get too "trigger
> > happy" and include something "just because it's there", and then decide
> > to remove when "standards say no". That like "putting the cart in front
> > of the horse".
> >
> > The way I read this, it says to me that the people involved in working on
> > the
> > draft are unqualifed to be working on it and that none of the work that 
> they
> > have
> > done over the past year is of any value, so my earlier comments still
> > obtain.
> >
> > Furthermore, your comments about slippery slope disturb me because they
> > follow
> > a pattern of filibustering and dissemination of FUD which seems to be aimed
> > at
> > preventing forward progress.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Eve Varma [mailto:[email-masked]]
> > Sent: Thursday, May 24, 2001 10:30 AM
> > To: John Drake
> > Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
> > [email-masked]; q11/15; t1x1.5
> > Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatenation
> >
> > Hi all,
> >
> > I don't think Zhi had any intent to denigrate other individuals whose
> > names were on the draft (in fact, several have expressed similar
> > concerns).  I think the key point was in the earlier part of the
> > message; as expressed in an earlier message from Juergen Heiles, there's
> > considerable concern that we're descending a slippery slope that could
> > ultimately have negative impacts.
> >
> >                        Cheers,
> >                             Eve
> >
> > John Drake wrote:
> > >
> > > I find this message to be very puzzling.  As far as I know, the 
> authors as
> > a
> > > group are extremely conversant with the
> > > subject matter in the draft and the draft represents their best current
> > > thinking.  You seem to be trying disparage them because you don't agree
> > with
> > > their solution, and I think that that is extremely unprofessional.
> > >
> > > The authors spent a long time working out the details of what is 
> presented
> > > in the draft, which you airily dismiss with:
> > >
> > > "As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people..."
> > >
> > > "As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision."
> > >
> > > If you're not happy with the draft, you are perfectly free to remove your
> > > name from it, but don't denigrate the other
> > > authors.
> > >
> > > John
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:[email-masked]]
> > > Sent: Wednesday, May 23, 2001 8:38 PM
> > > To: Mannie, Eric
> > > Cc: 'Guo-Qiang Wang'; [email-masked];
> > > [email-masked]; q11/15; t1x1.5
> > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > Hi,
> > >
> > > I think your questions cannot be answered either way. Whether features
> > > are needed for one or two vendors is up to each vendor to decide what
> > > they want.
> > >
> > > As for how many vendor is needed for a standard. Again this question
> > > doesn't really apply. We as engineers and the development community has
> > > to study a problem to make sure that it will not unduly impact existing
> > > networks, that what we are looking at should be sound and technically
> > > superior and that it will help provide added value to networks. As these
> > > transport capabilities will likely require people of transport expertise
> > > to study first, that's what we should do. Let's not get too "trigger
> > > happy" and include something "just because it's there", and then decide
> > > to remove when "standards say no". That like "putting the cart in front
> > > of the horse".
> > >
> > > As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people...
> > >
> > > As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision.
> > >
> > > Let's be technical, let the experts in the right group decide, and we
> > > should not jump the gun. Let's be adults and let's help make the telecom
> > > industry and the standards process a respectable place...
> > >
> > > "Mannie, Eric" wrote:
> > >
> > > > I don't work for a vendor :-) Who told you that some features are 
> needed
> > > > only for one or two vendors ? How do you quantify the number of vendors
> > > that
> > > > are needed to have a standard ? We work on a consensus based and this
> > > draft
> > > > has 17 companies on it with 30 people. Usually it is much much less at
> > the
> > > > IETF, you only have a small number of co-authors. I already gave a
> > summary
> > > > of the process that we followed, all the meetings that we hold, all the
> > > > conference call that we hold, all the e-mails that we exchanged, etc.
> > > >
> > > > You described one model in your e-mail, that's a valid model but 
> this is
> > > not
> > > > THE (only) model. There are plenty of other models that can be 
> fulfilled
> > > > with GMPLS.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >

Delivery-date: Thu, 24 May 2001 17:29:32 -0700
From: Steve West <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked], 'Eric Gray' <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Thu, 24 May 2001 17:21:35 -0700

Greg, Eric:

How can compliance with a signaled state be claimed if the behavior of the
SONET/SDH equipment under that signaling state is not defined ?

Steve

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 4:17 PM
To: Mannie, Eric; 'Stephen Trowbridge'
Cc: [email-masked]; [email-masked]; 'Eric Gray';
[email-masked]'; [email-masked]'; [email-masked]'
Subject: RE: Proposed text for the concatenation

Very good summary Eric. Like yourself, I'm not sure what's wrong with the
signaling protocol including industry practices even if they are not covered
by existing standards.  In some cases the extensions are perhaps too minor
in scope or too controversial to warrant extension of ITU/ANSI standards.
The "arbitrary contiguous concatenation" and the "flexible arbitrary
concatenation" examples are cases in point.  In both cases we are just
talking about an optional loosening of specified constraints. 

I didn't realize that others already supported "arbitrary contiguous
concatenation". You probably have a better view into the wide range of SDH
products than I.  I think your proposed text is good.  I'd be happy to work
with yourself and others in bringing these items into ITU/ANSI/ETSI or
wherever, but I don't think that the GMPLS SDH/SONET draft needs to wait on
such an effort, i.e., folks are implementing these specs now and
demonstrating interoperability.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, May 21, 2001 8:15 PM
To: 'Stephen Trowbridge'
Cc: [email-masked]; [email-masked]; 'Eric Gray';
[email-masked]'; Bernstein, Greg; [email-masked]';
[email-masked]'
Subject: RE: Proposed text for the concatenation

Hello Stephen,

>I think this goes against earlier email that says T1X1 and ITU-T
>are responsible for specification of SONET/SDH. There are two
>standardized forms of concatenation. Your proposal includes only
>one of the standardized forms and two that are, for the moment,
>proprietary. If we accept that SONET/SDH is the responsibility
>of T1X1/ITU-T...the other concatenation proposals must go to
>T1X1/ITU-T before they can be considered standardized.

Transparency and contiguous arbitrary concatenation were done in the current
draft with the significant participation of ITU-T experts that regularly
attend and participate to ITU-T meetings (several of them working for your
company by the way). We reached a consensus for the current draft between a
significant number of people working on different sides, all were SDH/SONET
experts. The most active co-authors even hold an half-day editing session in
parallel with the last OIF meeting in Paris. See the explanations hereafter.

We should stop the debate ITU-T against IETF, my company is member of both
and the folks that work on GMPLS to control SDH/SONET since one year and a
half are SDH/SONET experts !

We gave some explanations in our document to better describe what we are
speaking about, it has *nothing* to do with the way to implement it. Anybody
is free to describe what he/she is talking about. We gave our explanation of
a few interesting SDH/SONET behaviours in order to be sure that people will
understand what we are talking about.

Moreover, it is not because something is not defined in an SDH standard that
it doesn't work or doesn't exist, specially if this doesn't require any
change to the standards ! Note that there is a life outside of the G.707
standard.

Sending flames to mailing lists without trying to understand how it works is
confusing for everybody.

In that context, one should make the difference between:

1) SDH/SONET features that need an additional standard to be able to
interoperate:
----------------------------------------------------------------------------
------

In that case this is NOT at all in the scope of the IETF of course. I never
heard anybody at the IETF proposing to do SDH/SONET standards, it does not
make sense. The IETF management was *very* clear about that. It is well
understood and agreed. There is non reason to come back to this point
constantly, and there is no reason to use it as an argument each time we
speak about SDH/SONET at the IETF !

2) SDH/SONET features that don't need any new SDH/SONET standard:
-----------------------------------------------------------------

Let's speak about the three features that are disturbing a *few* folks.

About arbitrary contiguous concatenation:
----------------------------------------

Arbitrary contiguous concatenation (as described it in the proposed text)
don't need any standard, it is just a way to use SDH/SONET. It is already
implemented since a while by many manufacturers in legacy equipment's. In
that case there is NO reason why we should not define features to control it
in the GMPLS signaling. It is not because it is not described in G.707 that
you cannot do it, or that it doesn't work. What do you want to standardize,
a written permission to do it maybe ?

About transparency:
-------------------

Transparency at the GMPLS UNI does NOT require any SDH/SONET standard
because it is NOT implemented at the UNI, it is 100% about signaling. We
never said that GMPLS MUST be used at both the UNI and NNI. The NNI could be
in a proprietary cloud of a single manufacturer. So, there is NO reason to
remove it from the GMPLS signaling.

If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
at the NNI between two manufacturers needs an agreement to interoperate.
This agreement can be achieved in very different ways: through the use of a
standard, an implementation agreement made by a forum, or an implementation
agreement between two manufacturers (e.g. at the request of an operator).

ITU-T is not the only standardization body that produced SDH standards, ETSI
also made SDH standards that were published as ETSI standards. T1X1 is not
the only body with ITU-T that can work on SDH, ETSI is there as well. The
OIF is also publishing standards, and at the last OIF there was a session
dedicated to transparency. We can expect to see more contributions at the
next OIF meeting. Some contributions could also be presented to T1X1.
Anyway, that's not the business of IETF and has nothing to do with
transparency in the GMPLS signaling at the UNI.

About flexible arbitrary contiguous concatenation:
--------------------------------------------------

What is the additional standard that we need to support flexible arbitrary
contiguous concatenation. Could someone describe what should be standardized
and why two implementations could not interoperate ?

The GMPLS signaling gives the type, the number, the order, and the position
of all components. Flexible arbitrary contiguous concatenation in GMPLS is
only an indication send to the downstream node that it could use this
feature. The upstream node doesn't request it, it simply says to the
downstream node that it supports it. The downstream node can either decide
to ignore it and use a standard contiguous concatenation, or an arbitrary
contiguous concatenation; or it could refuse the connection request. This is
a local optimization to deal with local external fragmentation of the
multiplex that will happen if you route very dynamic demands. Traditional
ITU-T folks don't understand the interest since they don't think in terms of
dynamic circuit establishment.

There is NO interoperability issue between nodes that implement it and nodes
that doesn't implement it. Again, a written permission to do it doesn't need
to be written in a standard.

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Friday, May 18, 2001 11:06 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,
I think this goes against earlier email that says T1X1 and ITU-T
are responsible for specification of SONET/SDH. There are two
standardized forms of concatenation. Your proposal includes only
one of the standardized forms and two that are, for the moment,
proprietary. If we accept that SONET/SDH is the responsibility
of T1X1/ITU-T, then for the moment I think the options can only
be:
- No concatenation
- Standard Contiguous concatenation
- Standard Virtual concatenation
- (all others are, for the moment proprietary) vendor specific
  concatenation types
The other concatenation proposals must go to T1X1/ITU-T before
they can be considered standardized.
Regards,
Steve Trowbridge

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> I am pleased to see so many people discussing so much on these mailing
> lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> would like to make some progress.
> 
> Please, carefully read the following text that clarifies the contiguous
> concatenation part of the draft and that introduces one simple new
> concatenation type.
> 
> "This field indicates the type of SONET/SDH contiguous concatenation to
> apply on the Elementary Signal. It is set to zero to indicate that no
> contiguous concatenation is requested (default value). The values are
> defined in the following table:
> 
>        Bits   Contiguous Concatenation Type
>       -----   ----------------------------------
>        000     No contiguous concatenation requested
>        001     Standard contiguous concatenation
>        010     Arbitrary contiguous concatenation
>        011     Flexible arbitrary contiguous concatenation
>       others   Vendor specific concatenation types
> 
> Standard contiguous concatenation refers to the contiguous concatenation
as
> it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> concatenation relaxes the limitations of these standards in terms of the
> location where a contiguous signal can start, and in terms of the number
of
> concatenated VC's/SPE's that can compose this signal.
> 
> Flexible arbitrary contiguous concatenation is an optimisation of the
> arbitrary contiguous concatenation that allows to "inverse multiplex" a
> contiguously concatenated signal on a per multiplex section/line basis. In
> order to be effectively used, an upstream node must indicate that its
> supports this feature to its immediate downstream node, using the CCT
field.
> The downstream node can in that case use that feature and return a list of
> labels, one for each element of the "inverse multiplex"; instead of one
> single label indicating the beginning of the contiguous signal.
> 
> The three types of contiguous concatenation defined here before defines
> indeed a hierarchy of flexibility in the contiguous concatenation. If
> selected, the flexible arbitrary contiguous concatenation, indicates that
> any of the three types of contiguous concatenation can be chosen by the
> downstream node. It is up to the downstream node to choose the one that it
> wants to use. The upstream node, when receiving the labels from the
> downstream node, may accept or refuse what was proposed."
> 
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important
is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
> 
> Take your time to read the text and to answer, it is 10PM in my time zone
> and I will leave my office. I'll be back on Monday morning to read your
> answers.
> 
> Many thanks to all of you and have a nice week-end.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
> 
>

Delivery-date: Thu, 24 May 2001 17:23:12 -0700
From: John Drake <[email-masked]>
To: "'Tarapore, Percy S'" <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Thu, 24 May 2001 17:18:16 -0700

Percy,

There has been work on protocols for path restoration in mesh networks by a
number of
people.  However, at the last IETF Kireeti and Vijay clearly indicated that
this work,
while interesting, wouldn't be allowed to progress in advance of a
restoration requirements
draft from the TE group.

Thanks,

John

-----Original Message-----
From: Tarapore, Percy S [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 11:55 AM
To: Ash, Gerald R (Jerry); [email-masked]; [email-masked]
Subject: RE: GMPLS Last Calls

There is a significant issue related to the absence of restoration in the
signaling draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt). Very specifically, Section 7 of this draft deals with the case
involving protection information for link protection. While link protection
schemes may be desirable for fast recovery related to high priority LSP's,
more cost-effective shared mesh restoration schemes would be preferred for
the majority of traffic from a Service Provider's perspective. This
observation is supported by the fact that many vendors are currently
developing proprietary schemes for shared mesh restoration. Hence, in
addition to the protection information, GMPLS signaling needs to reflect a
minimum set of information/attributes required for shared mesh restoration
without jeopardizing vendor proprietary solutions.

The need for multiple types of restoration capabilities is well documented
in the OIF/UNI I-D
http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
xt as follows:

" Multiple types of facilities available for restoration are needed
   within the network. The following options should be considered for
   allocation of facilities to support restoration of failed
   connections:
   - Dedicated restoration capacity
   - Shared restoration capacity. This allows the network to ensure
     high quality service for customers, while still managing its
     physical resources efficiently.
   - Un-restorable
   - Pre-emptable"

The OIF/UNI I-D supports a range of different restoration schemes through
the use of service level as a connection attribute. This attribute is
defined as follows:

" an integer attribute that indicates a class of service. A carrier may
specify a range of different classes of service (e.g. gold, silver, bronze)
with predefined characteristics (e.g. restoration plans). The pre-defined
service types correspond to different types of network restoration (e.g. no
restoration, 1+1 protection), connection set-up and hold priorities,
reversion strategies for the connection after failures have been repaired,
and retention strategies."

It is therefore important that GMPLS be extended to be able to support such
restoration schemes.

Percy S. Tarapore
AT&T Labs

-----Original Message-----
From: Ash, Gerald R (Jerry) 
Sent: Thursday, May 24, 2001 2:20 PM
To: [email-masked]; [email-masked]
Cc: Ash, Gerald R (Jerry)
Subject: RE: GMPLS Last Calls

Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
draft:

"Eve - Had hoped that CCAMP formation and expression of requirements would
enable us to do more with architecture than reverse architect proposed
solution. Think we should also look at carrier requirements and look for
discrepancies with architecture. 
Curtis - requirements of carriers not being addressed?
Eve - happy to discuss on mailing list in absence of time"

There are still no documented service provider (SP) requirements driving the
proposed GMPLS protocol extensions.  This is inconsistent with the current
initiatives to provide SP requirements prior to protocol extensions being
accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
MPLS/DiffServ TE, multi-area TE, etc.  

Here is a sample of SP requirements that are not being addressed (other
requirements from our perspective are forthcoming):

1. Restoration requirements, particularly in support of mesh restoration,
need to be supported by GMPLS.  For example, Section 7 of the Generalized
Signaling I-D
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt) 
primarily discusses link protection, restoration capabilities are largely
missing and need to be included.

2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
should be clearly identified in the text and referenced in the GMPLS I-Ds,
e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707 [Reference
G.707] is supported by the Generalized Label Request."

As per Eve's comment at IETF-50, SPs are encouraged to post their
requirements to the list.  It would also help if more SPs were invited to
co-author the GMPLS drafts, to help ensure that SP requirements are more
adequately reflected and addressed.

Jerry Ash
AT&T Labs

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Monday, May 14, 2001 1:52 PM
To: [email-masked]; [email-masked]
Subject: GMPLS Last Calls

This message initiates a last call on four GMPLS drafts.  The last
call is being issued jointly in the MPLS and CCAMP workgroups.

The drafts are:

    1.  Generalized MPLS - Signaling Functional Description

           <draft-ietf-mpls-generalized-signaling-04.txt>

    2.  Generalized MPLS Signaling - RSVP-TE Extensions

           <draft-ietf-mpls-generalized-rsvp-te-03.txt>

    3.  Generalized MPLS Signaling - CR-LDP Extensions

           <draft-ietf-mpls-generalized-cr-ldp-03.txt>

    4.  GMPLS Extensions for SONET and SDH Control

           <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>

The last call closes May 29, 12 pm GMT.

-  V2KG (Vijay, Vijay, Kireeti, & George)

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Thu, 24 May 2001 17:18:27 -0700
From: "Ash, Gerald R (Jerry)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked], "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: RE: GMPLS Last Calls 
Date: Thu, 24 May 2001 20:16:56 -0400

Vishal,
You're on target.
Comments below.
Jerry Ash

> I think what he meant was that more service providers should be involved
in
> the discussions for various GMPLS features.

correct, as I mentioned, SPs have been formally asked for their
*requirements*, but not on the GMPLS extensions

> The current drafts are, in fact, weighted
> very heavily in favor of contributors who come from the vendor community,
> with one, perhaps two, exceptions.

correct

> I believe it would be very useful to get some SP input to ensure that
> their operational needs are met and that they can transition to using this
> work, since they, after all, are the ones who will use the protocols.

right, that's the point Tom and Yakov seem to have missed.

Delivery-date: Thu, 24 May 2001 16:56:45 -0700
From: Vishal Sharma <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
To: "'Thomas D. Nadeau'" <[email-masked]>, Yakov Rekhter <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: GMPLS Last Calls 
Date: Thu, 24 May 2001 17:19:29 -0700

Tom, Yakov,

I agree with you. Although, in all fairness to Gerry, I don't think by
"invited" he meant literally that people should be called in to put
their names on drafts (any drafts, not just GMPLS ones) simply because they
happen to be working for a service provider.
I think what he meant was that more service providers should be involved in
the discussions for various GMPLS features.

I think the point Gerry raised is a good one, and this can always be done
via the MPLS and CCAMP lists. (The current drafts are, in fact, weighted
very heavily in favor of contributors who come from the vendor community,
with one, perhaps two, exceptions.)

Service providers can, however,  certainly provide their inputs over the list 
and
initiate constructive discussion about features
of GMPLS signaling that they would like included in the current signaling 
drafts
(and features of routing that they would like to see in forthcoming routing
drafts). I believe it would be very useful to get some SP input to ensure that
their operational needs are met and that they can transition to using this
work, since they, after all, are the ones who will use
the protocols.

-Vishal

On Thursday, May 24, 2001 12:15 PM, Thomas D. Nadeau [SMTP:[email-masked]] 
wrote:
>
> > > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > > requirements to the list.  It would also help if more SPs were invited to
> > > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > > adequately reflected and addressed.
> >
> >If someone has anything *substantial* to contribute to the GMPLS
> >drafts, such person should be invited to become a co-author. This
> >is *irrespective* of whether such person works for a SP or not. On
> >the other hand, just because a person works for a SP, doesn't mean
> >such a person should be invited to become a co-author.
>
>          Yakov is precisely correct. The addition
> of (co)authors to drafts has all to do with their
> (generally significant) input to the drafts (and
> perhaps editing of the actual documents) regardless
> of corporate affiliation. It is not about being
> invited to put their names on the drafts just
> for advertising purposes.
>
>          --Tom

Delivery-date: Thu, 24 May 2001 16:25:27 -0700
From: John Drake <[email-masked]>
To: 'Paul Bonenfant' <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: 'Guo-Qiang Wang' <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Thu, 24 May 2001 16:19:05 -0700

"Further, I'll add that any claims to the effect that this will somehow
entice vendors
to rush to include their "unique" features in the document, fall into the
category of FUD."

I agree completely.  The large group that has been working on the draft over
the past year
or so has NOT been falling over themselves adding proprietary bells and
whistles.  Rather
the feature set has been pretty much static over the lifetime of the
document.

Thanks,

John   

-----Original Message-----
From: Paul Bonenfant [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 9:50 AM
To: 'Zhi-Wei Lin'; Mannie, Eric
Cc: 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Zhi,

Apologies in advance, it may seem like I'm picking on
you, but I'm not.  Honest.

I'm one of the N-30 (where N = the sum of [non-overlapping
subscribers to the ccamp, ip-optical, q11/15, and t1x1.5 
email exploders]) observers here, and I note that you are 
listed as an author of the draft.  

With all due respect, it seems a bit odd for the authors
to be debating the issue of what does/does-not belong in 
the draft with such vigor, over so many public email 
exploders, in response to a last call on the draft. How 
did the signaling for provisioning all of these features 
make it into the draft in the first place? What "metric" 
was used (in reference to another thread)?  IMO these 
_are_ fair questions. 

As an observer, it seems to me that all was well until it 
was recognized that one of the included features happened 
to be one that was once proposed in, but not supported by, 
T1X1 and/or ITU-T.  Oops.  Begin dilemma -- remove only
this feature, or all non/pre-standard features from the
draft?  Discussion ensues -- no end in sight. 

Well, perhaps we should discuss the "utility of a standard" 
metric.  I doubt (just a hunch here) that GMPLS-SONET/SDH 
is being developed solely for use in legacy equipment.  I
also doubt that carriers requesting "new" features will be 
pleased with a GMPLS-SONET/SDH draft that addresses none
of them. 

For what it's worth, I'll repeat that I support the proposal
to "tag" non/pre-standard items as such, and proceed with 
the draft in its current form.  Further, I'll add that any
claims to the effect that this will somehow entice vendors
to rush to include their "unique" features in the document,
fall into the category of FUD. 
  
Regards,

Paul

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 11:38 PM
To: Mannie, Eric
Cc: 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

I think your questions cannot be answered either way. Whether features
are needed for one or two vendors is up to each vendor to decide what
they want. 

As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people...

As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision. 

Let's be technical, let the experts in the right group decide, and we
should not jump the gun. Let's be adults and let's help make the telecom
industry and the standards process a respectable place...

"Mannie, Eric" wrote:

> I don't work for a vendor :-) Who told you that some features are needed
> only for one or two vendors ? How do you quantify the number of vendors
that
> are needed to have a standard ? We work on a consensus based and this
draft
> has 17 companies on it with 30 people. Usually it is much much less at the
> IETF, you only have a small number of co-authors. I already gave a summary
> of the process that we followed, all the meetings that we hold, all the
> conference call that we hold, all the e-mails that we exchanged, etc.
> 
> You described one model in your e-mail, that's a valid model but this is
not
> THE (only) model. There are plenty of other models that can be fulfilled
> with GMPLS.
> 
> Kind regards,
> 
> Eric
>

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Thu, 24 May 2001 16:18:57 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked], 'Eric Gray' <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Thu, 24 May 2001 16:16:51 -0700

Very good summary Eric. Like yourself, I'm not sure what's wrong with the
signaling protocol including industry practices even if they are not covered
by existing standards.  In some cases the extensions are perhaps too minor
in scope or too controversial to warrant extension of ITU/ANSI standards.
The "arbitrary contiguous concatenation" and the "flexible arbitrary
concatenation" examples are cases in point.  In both cases we are just
talking about an optional loosening of specified constraints. 

I didn't realize that others already supported "arbitrary contiguous
concatenation". You probably have a better view into the wide range of SDH
products than I.  I think your proposed text is good.  I'd be happy to work
with yourself and others in bringing these items into ITU/ANSI/ETSI or
wherever, but I don't think that the GMPLS SDH/SONET draft needs to wait on
such an effort, i.e., folks are implementing these specs now and
demonstrating interoperability.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Monday, May 21, 2001 8:15 PM
To: 'Stephen Trowbridge'
Cc: [email-masked]; [email-masked]; 'Eric Gray';
[email-masked]'; Bernstein, Greg; [email-masked]';
[email-masked]'
Subject: RE: Proposed text for the concatenation

Hello Stephen,

>I think this goes against earlier email that says T1X1 and ITU-T
>are responsible for specification of SONET/SDH. There are two
>standardized forms of concatenation. Your proposal includes only
>one of the standardized forms and two that are, for the moment,
>proprietary. If we accept that SONET/SDH is the responsibility
>of T1X1/ITU-T...the other concatenation proposals must go to
>T1X1/ITU-T before they can be considered standardized.

Transparency and contiguous arbitrary concatenation were done in the current
draft with the significant participation of ITU-T experts that regularly
attend and participate to ITU-T meetings (several of them working for your
company by the way). We reached a consensus for the current draft between a
significant number of people working on different sides, all were SDH/SONET
experts. The most active co-authors even hold an half-day editing session in
parallel with the last OIF meeting in Paris. See the explanations hereafter.

We should stop the debate ITU-T against IETF, my company is member of both
and the folks that work on GMPLS to control SDH/SONET since one year and a
half are SDH/SONET experts !

We gave some explanations in our document to better describe what we are
speaking about, it has *nothing* to do with the way to implement it. Anybody
is free to describe what he/she is talking about. We gave our explanation of
a few interesting SDH/SONET behaviours in order to be sure that people will
understand what we are talking about.

Moreover, it is not because something is not defined in an SDH standard that
it doesn't work or doesn't exist, specially if this doesn't require any
change to the standards ! Note that there is a life outside of the G.707
standard.

Sending flames to mailing lists without trying to understand how it works is
confusing for everybody.

In that context, one should make the difference between:

1) SDH/SONET features that need an additional standard to be able to
interoperate:
----------------------------------------------------------------------------
------

In that case this is NOT at all in the scope of the IETF of course. I never
heard anybody at the IETF proposing to do SDH/SONET standards, it does not
make sense. The IETF management was *very* clear about that. It is well
understood and agreed. There is non reason to come back to this point
constantly, and there is no reason to use it as an argument each time we
speak about SDH/SONET at the IETF !

2) SDH/SONET features that don't need any new SDH/SONET standard:
-----------------------------------------------------------------

Let's speak about the three features that are disturbing a *few* folks.

About arbitrary contiguous concatenation:
----------------------------------------

Arbitrary contiguous concatenation (as described it in the proposed text)
don't need any standard, it is just a way to use SDH/SONET. It is already
implemented since a while by many manufacturers in legacy equipment's. In
that case there is NO reason why we should not define features to control it
in the GMPLS signaling. It is not because it is not described in G.707 that
you cannot do it, or that it doesn't work. What do you want to standardize,
a written permission to do it maybe ?

About transparency:
-------------------

Transparency at the GMPLS UNI does NOT require any SDH/SONET standard
because it is NOT implemented at the UNI, it is 100% about signaling. We
never said that GMPLS MUST be used at both the UNI and NNI. The NNI could be
in a proprietary cloud of a single manufacturer. So, there is NO reason to
remove it from the GMPLS signaling.

If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
at the NNI between two manufacturers needs an agreement to interoperate.
This agreement can be achieved in very different ways: through the use of a
standard, an implementation agreement made by a forum, or an implementation
agreement between two manufacturers (e.g. at the request of an operator).

ITU-T is not the only standardization body that produced SDH standards, ETSI
also made SDH standards that were published as ETSI standards. T1X1 is not
the only body with ITU-T that can work on SDH, ETSI is there as well. The
OIF is also publishing standards, and at the last OIF there was a session
dedicated to transparency. We can expect to see more contributions at the
next OIF meeting. Some contributions could also be presented to T1X1.
Anyway, that's not the business of IETF and has nothing to do with
transparency in the GMPLS signaling at the UNI.

About flexible arbitrary contiguous concatenation:
--------------------------------------------------

What is the additional standard that we need to support flexible arbitrary
contiguous concatenation. Could someone describe what should be standardized
and why two implementations could not interoperate ?

The GMPLS signaling gives the type, the number, the order, and the position
of all components. Flexible arbitrary contiguous concatenation in GMPLS is
only an indication send to the downstream node that it could use this
feature. The upstream node doesn't request it, it simply says to the
downstream node that it supports it. The downstream node can either decide
to ignore it and use a standard contiguous concatenation, or an arbitrary
contiguous concatenation; or it could refuse the connection request. This is
a local optimization to deal with local external fragmentation of the
multiplex that will happen if you route very dynamic demands. Traditional
ITU-T folks don't understand the interest since they don't think in terms of
dynamic circuit establishment.

There is NO interoperability issue between nodes that implement it and nodes
that doesn't implement it. Again, a written permission to do it doesn't need
to be written in a standard.

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Friday, May 18, 2001 11:06 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,
I think this goes against earlier email that says T1X1 and ITU-T
are responsible for specification of SONET/SDH. There are two
standardized forms of concatenation. Your proposal includes only
one of the standardized forms and two that are, for the moment,
proprietary. If we accept that SONET/SDH is the responsibility
of T1X1/ITU-T, then for the moment I think the options can only
be:
- No concatenation
- Standard Contiguous concatenation
- Standard Virtual concatenation
- (all others are, for the moment proprietary) vendor specific
  concatenation types
The other concatenation proposals must go to T1X1/ITU-T before
they can be considered standardized.
Regards,
Steve Trowbridge

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> I am pleased to see so many people discussing so much on these mailing
> lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> would like to make some progress.
> 
> Please, carefully read the following text that clarifies the contiguous
> concatenation part of the draft and that introduces one simple new
> concatenation type.
> 
> "This field indicates the type of SONET/SDH contiguous concatenation to
> apply on the Elementary Signal. It is set to zero to indicate that no
> contiguous concatenation is requested (default value). The values are
> defined in the following table:
> 
>        Bits   Contiguous Concatenation Type
>       -----   ----------------------------------
>        000     No contiguous concatenation requested
>        001     Standard contiguous concatenation
>        010     Arbitrary contiguous concatenation
>        011     Flexible arbitrary contiguous concatenation
>       others   Vendor specific concatenation types
> 
> Standard contiguous concatenation refers to the contiguous concatenation
as
> it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> concatenation relaxes the limitations of these standards in terms of the
> location where a contiguous signal can start, and in terms of the number
of
> concatenated VC's/SPE's that can compose this signal.
> 
> Flexible arbitrary contiguous concatenation is an optimisation of the
> arbitrary contiguous concatenation that allows to "inverse multiplex" a
> contiguously concatenated signal on a per multiplex section/line basis. In
> order to be effectively used, an upstream node must indicate that its
> supports this feature to its immediate downstream node, using the CCT
field.
> The downstream node can in that case use that feature and return a list of
> labels, one for each element of the "inverse multiplex"; instead of one
> single label indicating the beginning of the contiguous signal.
> 
> The three types of contiguous concatenation defined here before defines
> indeed a hierarchy of flexibility in the contiguous concatenation. If
> selected, the flexible arbitrary contiguous concatenation, indicates that
> any of the three types of contiguous concatenation can be chosen by the
> downstream node. It is up to the downstream node to choose the one that it
> wants to use. The upstream node, when receiving the labels from the
> downstream node, may accept or refuse what was proposed."
> 
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important
is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
> 
> Take your time to read the text and to answer, it is 10PM in my time zone
> and I will leave my office. I'll be back on Monday morning to read your
> answers.
> 
> Many thanks to all of you and have a nice week-end.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
> 
>

Delivery-date: Thu, 24 May 2001 15:53:52 -0700
Date: Thu, 24 May 2001 18:54:10 -0700
From: Rob Coltun <[email-masked]>
To: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

All,
    despite the heated arguments I think the discussion is important to have.

I suggest that instead of  tagging non/pre-standard items in the current drafts
that they be put into a separate Informational document  - this is the cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary protocols
but not as standard track documents.

thanks,
---rob

Delivery-date: Thu, 24 May 2001 15:14:03 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Rob Coltun'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Thu, 24 May 2001 18:11:36 -0400

Rob, You proposal makes a lot of sense. Having the signaling standard
support proprietary transport may jeopardize interoperability. The issue is
not about GMPLS supporting non-standard rates, the issue is about putting in
formal and very specific support for a proprietary transport solution in a
standard document for signaling without taking the transport portion to a
standards body. Having formal signaling support for a proprietary
concatenation may cause interoperability issues when other vendors have a
different solution to the concatenation and while the signaling would
indicate the concatenation, the actual transport may not work.   On the
other hand we recognize that there may be a need for some interim support
for proprietary solutions.

Eric,
Below I have some additional specific comments for the document GMPLS
Extensions for SONET and SDH Control

CCT field (3 bits)
Since arbitrary contiguous concatenation is not a standard concatenation, it
falls within the vendor proprietary set of solutions.

So the CCT bits may be used as follows:
000	No contiguous concatenation requested
001	Standard contiguous concatenation
others	Vendor specific contiguous concatenation

Alternatively, a better solution is to use only 2 bits for this field and
use one bit to show whether contiguous concatenation is requested and the
second bit to show whether it is standard or non-standard contiguous
concatenation.

NCC field (16 bits)
This information is not sufficient. 
NCC needs better description than a zero or non-zero number.

SDH and SONET Labels

Text in this section (Section 3, paragraphs 5 and 6) indicates that the
GMPLS proposal limits virtual concatenation to remain within a single
(component) link. If I understand this correctly, it means that GMPLS will
not allow inverse multiplexing (virtual concatenation) in the transport
plane if it requires different component links. This is too limiting.

Annex 1 (sent out by Eric Mannie on 5/22)
Defines another type of concatenation - Flexible arbitrary contiguous
concatenation without describing precisely how it affects the OH bits. This
means that it will be impossible to have this type of concatenation in a
multi vendor environment based only on the GMPLS signaling. If the transport
plane is proprietary, having the option in the signaling message will not
fix the interoperability problem between two different vendors supporting
their proprietary versions of arbitrary concatenation.

Annex 2 (sent out by Eric Mannie on 5/22)
Arbitrary contiguous concatenation needs definition work for
interoperability.
Flexible arbitrary contiguous concatenation may be available today to
support contiguous signals, but it is not defined in the current standards.
Clear agreements on OH usage are needed between supporting vendors.
Maintenance and tracking of the signal needs to be well understood.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Rob Coltun [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 7:24 PM
To: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

All,
    despite the heated arguments I think the discussion is important to
have.

I suggest that instead of  tagging non/pre-standard items in the current
drafts
that they be put into a separate Informational document  - this is the
cleanest thing to do.
We (the IETF) do have a tradition of publishing company proprietary
protocols
but not as standard track documents.

thanks,
---rob

_______________________________________________
IP-Optical mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Thu, 24 May 2001 14:27:47 -0700
Date: Thu, 24 May 2001 17:25:43 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Eve Varma'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, "'Guo-Qiang Wang'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatenation

I feel that I should at least try to explain my comments since people
may mis-interpret. 

As I said several emails ago, and have sort of repeated...we can move in
any direction as long as we make CLEAR what the method is for
evaluating. 

I did not try to denigrate, nor belittle the work of the numerous
authors. In fact I highly respect many of the authors of the documents.
Maybe my analogies are too strong, in that case I apologize. But the
fact remains that we seem to be looking at this from different angles
and thus causing all the discussions. I think the reason is that we all
have different backgrounds and different understanding of some basic
terms. 

My proposal is to outline the specific metrics used for including and
excluding the features, add the metric as part of the document so that a
person picking up the document understands the rationales behind this,
and list ALL the assumptions and limitations of the documents so that
there is no misunderstanding.

For example, are these the metrics for including features?????

* There must be at least 2 vendors that support a feature. In that case,
we need to quantify or show that this is indeed the case. Making claims
without substantiation IMO would not help...
* There must be at least one operator asking for the feature. 
* For each feature identified that are extensions of the standards, do
we need to describe what it is, how it functions, what is needed to
interoperate, what impacts it has on current networks, does it work with
current networks, what is the scope of the feature (network-wide or
enterprise only), is there any security considerations (allows malicious
users to gain free service), etc. etc...

OR maybe the metrics may be:

* All features in the main body should conform to standards.
* Any other features not part of standards may be described in an
appendix, but no codepoints are assigned. Reserve a range of codepoints
for proprietary extensions

OR any other metrics that may be used. But we HAVE to enumerate this so
that the telecom/internet community can look upon this and say, "yes,
this was a fair and open process where any vendor or operator can apply
the metrics to any feature without any subjective decision being made
against any feature"...

Zhi

John Drake wrote:
> 
> Eve,
> 
> Okay, for the sake of discussion, we'll assume that the last two thirds of
> the e-mail
> don't exist and focus on the first third:
> 
> "As for how many vendor is needed for a standard. Again this question
> doesn't really apply. We as engineers and the development community has
> to study a problem to make sure that it will not unduly impact existing
> networks, that what we are looking at should be sound and technically
> superior and that it will help provide added value to networks. As these
> transport capabilities will likely require people of transport expertise
> to study first, that's what we should do. Let's not get too "trigger
> happy" and include something "just because it's there", and then decide
> to remove when "standards say no". That like "putting the cart in front
> of the horse".
> 
> The way I read this, it says to me that the people involved in working on
> the
> draft are unqualifed to be working on it and that none of the work that they
> have
> done over the past year is of any value, so my earlier comments still
> obtain.
> 
> Furthermore, your comments about slippery slope disturb me because they
> follow
> a pattern of filibustering and dissemination of FUD which seems to be aimed
> at
> preventing forward progress.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Eve Varma [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 10:30 AM
> To: John Drake
> Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
> [email-masked]; q11/15; t1x1.5
> Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> concatenation
> 
> Hi all,
> 
> I don't think Zhi had any intent to denigrate other individuals whose
> names were on the draft (in fact, several have expressed similar
> concerns).  I think the key point was in the earlier part of the
> message; as expressed in an earlier message from Juergen Heiles, there's
> considerable concern that we're descending a slippery slope that could
> ultimately have negative impacts.
> 
>                        Cheers,
>                             Eve
> 
> John Drake wrote:
> >
> > I find this message to be very puzzling.  As far as I know, the authors as
> a
> > group are extremely conversant with the
> > subject matter in the draft and the draft represents their best current
> > thinking.  You seem to be trying disparage them because you don't agree
> with
> > their solution, and I think that that is extremely unprofessional.
> >
> > The authors spent a long time working out the details of what is presented
> > in the draft, which you airily dismiss with:
> >
> > "As to how many companies and how many people's names are on the
> > contribution. Let's be intelligent adults here. As someone once asked
> > me, "if you see a million flies eating feces, would you also eat?"
> > (sorry people! it is disgusting but I had to give an extreme analogy).
> > Sometimes the majority may not be correct. I am not saying I am correct
> > either. It all depends on the background knowledge base and the
> > underlying motive of the people..."
> >
> > "As to how many processes followed, how many meetings held, how many
> > conferences given, how many emails exchanged...an idea doesn't get
> > better with repetition. As someone once said at some standards meeting
> > "if an idea stinks, it doesn't matter how many times some idea is
> > presented, it still stinks that many times". So the number of times is
> > not a reason for making a decision."
> >
> > If you're not happy with the draft, you are perfectly free to remove your
> > name from it, but don't denigrate the other
> > authors.
> >
> > John
> >
> >
> >
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 8:38 PM
> > To: Mannie, Eric
> > Cc: 'Guo-Qiang Wang'; [email-masked];
> > [email-masked]; q11/15; t1x1.5
> > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> >
> > Hi,
> >
> > I think your questions cannot be answered either way. Whether features
> > are needed for one or two vendors is up to each vendor to decide what
> > they want.
> >
> > As for how many vendor is needed for a standard. Again this question
> > doesn't really apply. We as engineers and the development community has
> > to study a problem to make sure that it will not unduly impact existing
> > networks, that what we are looking at should be sound and technically
> > superior and that it will help provide added value to networks. As these
> > transport capabilities will likely require people of transport expertise
> > to study first, that's what we should do. Let's not get too "trigger
> > happy" and include something "just because it's there", and then decide
> > to remove when "standards say no". That like "putting the cart in front
> > of the horse".
> >
> > As to how many companies and how many people's names are on the
> > contribution. Let's be intelligent adults here. As someone once asked
> > me, "if you see a million flies eating feces, would you also eat?"
> > (sorry people! it is disgusting but I had to give an extreme analogy).
> > Sometimes the majority may not be correct. I am not saying I am correct
> > either. It all depends on the background knowledge base and the
> > underlying motive of the people...
> >
> > As to how many processes followed, how many meetings held, how many
> > conferences given, how many emails exchanged...an idea doesn't get
> > better with repetition. As someone once said at some standards meeting
> > "if an idea stinks, it doesn't matter how many times some idea is
> > presented, it still stinks that many times". So the number of times is
> > not a reason for making a decision.
> >
> > Let's be technical, let the experts in the right group decide, and we
> > should not jump the gun. Let's be adults and let's help make the telecom
> > industry and the standards process a respectable place...
> >
> > "Mannie, Eric" wrote:
> >
> > > I don't work for a vendor :-) Who told you that some features are needed
> > > only for one or two vendors ? How do you quantify the number of vendors
> > that
> > > are needed to have a standard ? We work on a consensus based and this
> > draft
> > > has 17 companies on it with 30 people. Usually it is much much less at
> the
> > > IETF, you only have a small number of co-authors. I already gave a
> summary
> > > of the process that we followed, all the meetings that we hold, all the
> > > conference call that we hold, all the e-mails that we exchanged, etc.
> > >
> > > You described one model in your e-mail, that's a valid model but this is
> > not
> > > THE (only) model. There are plenty of other models that can be fulfilled
> > > with GMPLS.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >

Delivery-date: Thu, 24 May 2001 12:31:18 -0700
From: Paul Bonenfant <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: 'Guo-Qiang Wang' <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Thu, 24 May 2001 12:49:51 -0400

Zhi,

Apologies in advance, it may seem like I'm picking on
you, but I'm not.  Honest.

I'm one of the N-30 (where N = the sum of [non-overlapping
subscribers to the ccamp, ip-optical, q11/15, and t1x1.5 
email exploders]) observers here, and I note that you are 
listed as an author of the draft.  

With all due respect, it seems a bit odd for the authors
to be debating the issue of what does/does-not belong in 
the draft with such vigor, over so many public email 
exploders, in response to a last call on the draft. How 
did the signaling for provisioning all of these features 
make it into the draft in the first place? What "metric" 
was used (in reference to another thread)?  IMO these 
_are_ fair questions. 

As an observer, it seems to me that all was well until it 
was recognized that one of the included features happened 
to be one that was once proposed in, but not supported by, 
T1X1 and/or ITU-T.  Oops.  Begin dilemma -- remove only
this feature, or all non/pre-standard features from the
draft?  Discussion ensues -- no end in sight. 

Well, perhaps we should discuss the "utility of a standard" 
metric.  I doubt (just a hunch here) that GMPLS-SONET/SDH 
is being developed solely for use in legacy equipment.  I
also doubt that carriers requesting "new" features will be 
pleased with a GMPLS-SONET/SDH draft that addresses none
of them. 

For what it's worth, I'll repeat that I support the proposal
to "tag" non/pre-standard items as such, and proceed with 
the draft in its current form.  Further, I'll add that any
claims to the effect that this will somehow entice vendors
to rush to include their "unique" features in the document,
fall into the category of FUD. 
  
Regards,

Paul

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 11:38 PM
To: Mannie, Eric
Cc: 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

I think your questions cannot be answered either way. Whether features
are needed for one or two vendors is up to each vendor to decide what
they want. 

As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people...

As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision. 

Let's be technical, let the experts in the right group decide, and we
should not jump the gun. Let's be adults and let's help make the telecom
industry and the standards process a respectable place...

"Mannie, Eric" wrote:

> I don't work for a vendor :-) Who told you that some features are needed
> only for one or two vendors ? How do you quantify the number of vendors
that
> are needed to have a standard ? We work on a consensus based and this
draft
> has 17 companies on it with 30 people. Usually it is much much less at the
> IETF, you only have a small number of co-authors. I already gave a summary
> of the process that we followed, all the meetings that we hold, all the
> conference call that we hold, all the e-mails that we exchanged, etc.
> 
> You described one model in your e-mail, that's a valid model but this is
not
> THE (only) model. There are plenty of other models that can be fulfilled
> with GMPLS.
> 
> Kind regards,
> 
> Eric
>

Delivery-date: Thu, 24 May 2001 12:14:54 -0700
Date: Thu, 24 May 2001 15:15:13 -0400
To: Yakov Rekhter <[email-masked]>, "Ash, Gerald R (Jerry)" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: GMPLS Last Calls 
Cc: [email-masked], [email-masked]

> > As per Eve's comment at IETF-50, SPs are encouraged to post their
> > requirements to the list.  It would also help if more SPs were invited to
> > co-author the GMPLS drafts, to help ensure that SP requirements are more
> > adequately reflected and addressed.
>
>If someone has anything *substantial* to contribute to the GMPLS
>drafts, such person should be invited to become a co-author. This
>is *irrespective* of whether such person works for a SP or not. On
>the other hand, just because a person works for a SP, doesn't mean
>such a person should be invited to become a co-author.

         Yakov is precisely correct. The addition
of (co)authors to drafts has all to do with their
(generally significant) input to the drafts (and
perhaps editing of the actual documents) regardless
of corporate affiliation. It is not about being
invited to put their names on the drafts just
for advertising purposes.

         --Tom

Delivery-date: Thu, 24 May 2001 11:55:41 -0700
From: "Tarapore, Percy S" <[email-masked]>
To: "Ash, Gerald R (Jerry)" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls
Date: Thu, 24 May 2001 14:54:37 -0400

There is a significant issue related to the absence of restoration in the
signaling draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt). Very specifically, Section 7 of this draft deals with the case
involving protection information for link protection. While link protection
schemes may be desirable for fast recovery related to high priority LSP's,
more cost-effective shared mesh restoration schemes would be preferred for
the majority of traffic from a Service Provider's perspective. This
observation is supported by the fact that many vendors are currently
developing proprietary schemes for shared mesh restoration. Hence, in
addition to the protection information, GMPLS signaling needs to reflect a
minimum set of information/attributes required for shared mesh restoration
without jeopardizing vendor proprietary solutions.

The need for multiple types of restoration capabilities is well documented
in the OIF/UNI I-D
http://search.ietf.org/internet-drafts/draft-many-carrier-framework-uni-00.t
xt as follows:

" Multiple types of facilities available for restoration are needed
   within the network. The following options should be considered for
   allocation of facilities to support restoration of failed
   connections:
   - Dedicated restoration capacity
   - Shared restoration capacity. This allows the network to ensure
     high quality service for customers, while still managing its
     physical resources efficiently.
   - Un-restorable
   - Pre-emptable"

The OIF/UNI I-D supports a range of different restoration schemes through
the use of service level as a connection attribute. This attribute is
defined as follows:

" an integer attribute that indicates a class of service. A carrier may
specify a range of different classes of service (e.g. gold, silver, bronze)
with predefined characteristics (e.g. restoration plans). The pre-defined
service types correspond to different types of network restoration (e.g. no
restoration, 1+1 protection), connection set-up and hold priorities,
reversion strategies for the connection after failures have been repaired,
and retention strategies."

It is therefore important that GMPLS be extended to be able to support such
restoration schemes.

Percy S. Tarapore
AT&T Labs

-----Original Message-----
From: Ash, Gerald R (Jerry) 
Sent: Thursday, May 24, 2001 2:20 PM
To: [email-masked]; [email-masked]
Cc: Ash, Gerald R (Jerry)
Subject: RE: GMPLS Last Calls

Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
draft:

"Eve - Had hoped that CCAMP formation and expression of requirements would
enable us to do more with architecture than reverse architect proposed
solution. Think we should also look at carrier requirements and look for
discrepancies with architecture. 
Curtis - requirements of carriers not being addressed?
Eve - happy to discuss on mailing list in absence of time"

There are still no documented service provider (SP) requirements driving the
proposed GMPLS protocol extensions.  This is inconsistent with the current
initiatives to provide SP requirements prior to protocol extensions being
accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
MPLS/DiffServ TE, multi-area TE, etc.  

Here is a sample of SP requirements that are not being addressed (other
requirements from our perspective are forthcoming):

1. Restoration requirements, particularly in support of mesh restoration,
need to be supported by GMPLS.  For example, Section 7 of the Generalized
Signaling I-D
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt) 
primarily discusses link protection, restoration capabilities are largely
missing and need to be included.

2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
should be clearly identified in the text and referenced in the GMPLS I-Ds,
e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707 [Reference
G.707] is supported by the Generalized Label Request."

As per Eve's comment at IETF-50, SPs are encouraged to post their
requirements to the list.  It would also help if more SPs were invited to
co-author the GMPLS drafts, to help ensure that SP requirements are more
adequately reflected and addressed.

Jerry Ash
AT&T Labs

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Monday, May 14, 2001 1:52 PM
To: [email-masked]; [email-masked]
Subject: GMPLS Last Calls

This message initiates a last call on four GMPLS drafts.  The last
call is being issued jointly in the MPLS and CCAMP workgroups.

The drafts are:

    1.  Generalized MPLS - Signaling Functional Description

           <draft-ietf-mpls-generalized-signaling-04.txt>

    2.  Generalized MPLS Signaling - RSVP-TE Extensions

           <draft-ietf-mpls-generalized-rsvp-te-03.txt>

    3.  Generalized MPLS Signaling - CR-LDP Extensions

           <draft-ietf-mpls-generalized-cr-ldp-03.txt>

    4.  GMPLS Extensions for SONET and SDH Control

           <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>

The last call closes May 29, 12 pm GMT.

-  V2KG (Vijay, Vijay, Kireeti, & George)

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Thu, 24 May 2001 11:53:10 -0700
To: "Ash, Gerald R (Jerry)" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: GMPLS Last Calls 
Date: Thu, 24 May 2001 11:51:43 -0700
From: Yakov Rekhter <[email-masked]>

Jerry,

[clipped...]
 
> As per Eve's comment at IETF-50, SPs are encouraged to post their
> requirements to the list.  It would also help if more SPs were invited to
> co-author the GMPLS drafts, to help ensure that SP requirements are more
> adequately reflected and addressed.

If someone has anything *substantial* to contribute to the GMPLS
drafts, such person should be invited to become a co-author. This
is *irrespective* of whether such person works for a SP or not. On
the other hand, just because a person works for a SP, doesn't mean
such a person should be invited to become a co-author.

Yakov.

Delivery-date: Thu, 24 May 2001 11:21:26 -0700
From: "Ash, Gerald R (Jerry)" <[email-masked]>
To: [email-masked], [email-masked]
Cc: "Ash, Gerald R (Jerry)" <[email-masked]>
Subject: RE: GMPLS Last Calls
Date: Thu, 24 May 2001 14:20:28 -0400

Quoting from the CCAMP/IETF-50 meeting minutes re the GMPLS Architecture
draft:

"Eve - Had hoped that CCAMP formation and expression of requirements would
enable us to do more with architecture than reverse architect proposed
solution. Think we should also look at carrier requirements and look for
discrepancies with architecture. 
Curtis - requirements of carriers not being addressed?
Eve - happy to discuss on mailing list in absence of time"

There are still no documented service provider (SP) requirements driving the
proposed GMPLS protocol extensions.  This is inconsistent with the current
initiatives to provide SP requirements prior to protocol extensions being
accepted, such as for protection/restoration, network hierarchy, MPLS OAM,
MPLS/DiffServ TE, multi-area TE, etc.  

Here is a sample of SP requirements that are not being addressed (other
requirements from our perspective are forthcoming):

1. Restoration requirements, particularly in support of mesh restoration,
need to be supported by GMPLS.  For example, Section 7 of the Generalized
Signaling I-D
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-0
4.txt) 
primarily discusses link protection, restoration capabilities are largely
missing and need to be included.

2. Standards explicitly supported by GMPLS, such as G.707, G.709, etc.,
should be clearly identified in the text and referenced in the GMPLS I-Ds,
e.g., in Section 3.1 of the Generalized Signaling I-D, add "G.707 [Reference
G.707] is supported by the Generalized Label Request."

As per Eve's comment at IETF-50, SPs are encouraged to post their
requirements to the list.  It would also help if more SPs were invited to
co-author the GMPLS drafts, to help ensure that SP requirements are more
adequately reflected and addressed.

Jerry Ash
AT&T Labs

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Monday, May 14, 2001 1:52 PM
To: [email-masked]; [email-masked]
Subject: GMPLS Last Calls

This message initiates a last call on four GMPLS drafts.  The last
call is being issued jointly in the MPLS and CCAMP workgroups.

The drafts are:

    1.  Generalized MPLS - Signaling Functional Description

           <draft-ietf-mpls-generalized-signaling-04.txt>

    2.  Generalized MPLS Signaling - RSVP-TE Extensions

           <draft-ietf-mpls-generalized-rsvp-te-03.txt>

    3.  Generalized MPLS Signaling - CR-LDP Extensions

           <draft-ietf-mpls-generalized-cr-ldp-03.txt>

    4.  GMPLS Extensions for SONET and SDH Control

           <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>

The last call closes May 29, 12 pm GMT.

-  V2KG (Vijay, Vijay, Kireeti, & George)

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Thu, 24 May 2001 11:03:13 -0700
From: John Drake <[email-masked]>
To: 'Eve Varma' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, "Mannie, Eric" <[email-masked]>, 'Guo-Qiang Wang' <[email-masked]>,  [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatena tion
Date: Thu, 24 May 2001 10:55:51 -0700

Eve,

Okay, for the sake of discussion, we'll assume that the last two thirds of
the e-mail
don't exist and focus on the first third:

"As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

The way I read this, it says to me that the people involved in working on
the
draft are unqualifed to be working on it and that none of the work that they
have
done over the past year is of any value, so my earlier comments still
obtain.

Furthermore, your comments about slippery slope disturb me because they
follow
a pattern of filibustering and dissemination of FUD which seems to be aimed
at
preventing forward progress.

Thanks,

John

-----Original Message-----
From: Eve Varma [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 10:30 AM
To: John Drake
Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
concatenation

Hi all,

I don't think Zhi had any intent to denigrate other individuals whose
names were on the draft (in fact, several have expressed similar
concerns).  I think the key point was in the earlier part of the
message; as expressed in an earlier message from Juergen Heiles, there's
considerable concern that we're descending a slippery slope that could
ultimately have negative impacts.

                       Cheers,
                            Eve

John Drake wrote:
> 
> I find this message to be very puzzling.  As far as I know, the authors as
a
> group are extremely conversant with the
> subject matter in the draft and the draft represents their best current
> thinking.  You seem to be trying disparage them because you don't agree
with
> their solution, and I think that that is extremely unprofessional.
> 
> The authors spent a long time working out the details of what is presented
> in the draft, which you airily dismiss with:
> 
> "As to how many companies and how many people's names are on the
> contribution. Let's be intelligent adults here. As someone once asked
> me, "if you see a million flies eating feces, would you also eat?"
> (sorry people! it is disgusting but I had to give an extreme analogy).
> Sometimes the majority may not be correct. I am not saying I am correct
> either. It all depends on the background knowledge base and the
> underlying motive of the people..."
> 
> "As to how many processes followed, how many meetings held, how many
> conferences given, how many emails exchanged...an idea doesn't get
> better with repetition. As someone once said at some standards meeting
> "if an idea stinks, it doesn't matter how many times some idea is
> presented, it still stinks that many times". So the number of times is
> not a reason for making a decision."
> 
> If you're not happy with the draft, you are perfectly free to remove your
> name from it, but don't denigrate the other
> authors.
> 
> John
> 
> 
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 8:38 PM
> To: Mannie, Eric
> Cc: 'Guo-Qiang Wang'; [email-masked];
> [email-masked]; q11/15; t1x1.5
> Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> 
> Hi,
> 
> I think your questions cannot be answered either way. Whether features
> are needed for one or two vendors is up to each vendor to decide what
> they want.
> 
> As for how many vendor is needed for a standard. Again this question
> doesn't really apply. We as engineers and the development community has
> to study a problem to make sure that it will not unduly impact existing
> networks, that what we are looking at should be sound and technically
> superior and that it will help provide added value to networks. As these
> transport capabilities will likely require people of transport expertise
> to study first, that's what we should do. Let's not get too "trigger
> happy" and include something "just because it's there", and then decide
> to remove when "standards say no". That like "putting the cart in front
> of the horse".
> 
> As to how many companies and how many people's names are on the
> contribution. Let's be intelligent adults here. As someone once asked
> me, "if you see a million flies eating feces, would you also eat?"
> (sorry people! it is disgusting but I had to give an extreme analogy).
> Sometimes the majority may not be correct. I am not saying I am correct
> either. It all depends on the background knowledge base and the
> underlying motive of the people...
> 
> As to how many processes followed, how many meetings held, how many
> conferences given, how many emails exchanged...an idea doesn't get
> better with repetition. As someone once said at some standards meeting
> "if an idea stinks, it doesn't matter how many times some idea is
> presented, it still stinks that many times". So the number of times is
> not a reason for making a decision.
> 
> Let's be technical, let the experts in the right group decide, and we
> should not jump the gun. Let's be adults and let's help make the telecom
> industry and the standards process a respectable place...
> 
> "Mannie, Eric" wrote:
> 
> > I don't work for a vendor :-) Who told you that some features are needed
> > only for one or two vendors ? How do you quantify the number of vendors
> that
> > are needed to have a standard ? We work on a consensus based and this
> draft
> > has 17 companies on it with 30 people. Usually it is much much less at
the
> > IETF, you only have a small number of co-authors. I already gave a
summary
> > of the process that we followed, all the meetings that we hold, all the
> > conference call that we hold, all the e-mails that we exchanged, etc.
> >
> > You described one model in your e-mail, that's a valid model but this is
> not
> > THE (only) model. There are plenty of other models that can be fulfilled
> > with GMPLS.
> >
> > Kind regards,
> >
> > Eric
> >

Delivery-date: Thu, 24 May 2001 09:45:26 -0700
From: John Drake <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: 'Guo-Qiang Wang' <[email-masked]>, [email-masked],  [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Thu, 24 May 2001 09:39:57 -0700

I find this message to be very puzzling.  As far as I know, the authors as a
group are extremely conversant with the
subject matter in the draft and the draft represents their best current
thinking.  You seem to be trying disparage them because you don't agree with
their solution, and I think that that is extremely unprofessional. 

The authors spent a long time working out the details of what is presented
in the draft, which you airily dismiss with:

"As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people..."

"As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision."

If you're not happy with the draft, you are perfectly free to remove your
name from it, but don't denigrate the other
authors.

John 

-----Original Message-----
From: Zhi-Wei Lin [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:38 PM
To: Mannie, Eric
Cc: 'Guo-Qiang Wang'; [email-masked];
[email-masked]; q11/15; t1x1.5
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

I think your questions cannot be answered either way. Whether features
are needed for one or two vendors is up to each vendor to decide what
they want. 

As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people...

As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision. 

Let's be technical, let the experts in the right group decide, and we
should not jump the gun. Let's be adults and let's help make the telecom
industry and the standards process a respectable place...

"Mannie, Eric" wrote:

> I don't work for a vendor :-) Who told you that some features are needed
> only for one or two vendors ? How do you quantify the number of vendors
that
> are needed to have a standard ? We work on a consensus based and this
draft
> has 17 companies on it with 30 people. Usually it is much much less at the
> IETF, you only have a small number of co-authors. I already gave a summary
> of the process that we followed, all the meetings that we hold, all the
> conference call that we hold, all the e-mails that we exchanged, etc.
> 
> You described one model in your e-mail, that's a valid model but this is
not
> THE (only) model. There are plenty of other models that can be fulfilled
> with GMPLS.
> 
> Kind regards,
> 
> Eric
>

Delivery-date: Thu, 24 May 2001 08:47:23 -0700
From: "Kullberg, Alan" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, 'Kireeti Kompella' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Thu, 24 May 2001 11:44:13 -0400

The following paragraph is from section 3 of
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt.

  When hierarchical SDH/SONET LSPs are used, an LSP with a given
   bandwidth can be used to tunnel lower order LSPs.  The higher
   order SDH/SONET LSP behaves as a virtual link with a given
   bandwidth (e.g. VC-3), it may also be used as a Forwarding
   Adjacency. A lower order SDH/SONET LSP can be established through
   that higher order LSP. Since a label is local to a (virtual) link,
   the highest part of that label is non-significant and is set to
   zero.

The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
defined for TDM Switch Capable.  In order to support the hierarchy in the
above paragraph, TDM Switch Capable would need to be split into multiple
values, one for each level of the SDH/SONET multiplexing structure.

What do you think?

Alan

Delivery-date: Thu, 24 May 2001 08:47:16 -0700
Date: Thu, 24 May 2001 17:42:53 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Grant W. Cyboron" <[email-masked]>
CC: Zhi-Wei Lin <[email-masked]>, John Drake <[email-masked]>, "Lazer, Monica A, NNAD" <[email-masked]>, Heiles Juergen <[email-masked]>, "Mannie, Eric" <[email-masked]>, "Fong, Man Wing" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------8FE6A6BE36B5E41D73F03BE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Grant et al,

I think the statement you add should be commented by carriers
and providers as well since related to the "applicability" of this 
features within "operational networks". It would be interesting if 
Monica, Eric Mannie and others could raise their opinion on this 
issue as well.

Many thanks,
Dimitri.

"Grant W. Cyboron" wrote:
> 
> I have been following this thread for the past several days but have not
> added anything to it because I have been inactive in standards for the
> past 4 years. Prior to that I contributed to T1X1.5 and chaired it from
> 1991 to 1995. I think that to be complete your footnote would actually
> have to read (I carried on with your capital letters although I do not
> think they are really necessary):
> 
> "Some of the features described in this specification are not defined
> either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and
> 2000) OR IN ANY OTHER APPROVED DOCUMENT COMING FROM STANDARDIZATION
> BODIES DEALING WITH SONET/SDH. THEREFORE ONE SHOULD ONLY EXPECT THEM TO
> BE OPERABLE IN A NETWORK CONTAINING A SINGLE VENDOR'S EQUIPMENT OR
> THROUGH NEGOTIATIONS BETWEEN NETWORK OPERATORS AND THEIR VENDORS. THEY
> WILL NOT BE OPERABLE BETWEEN ADMINISTRATIVE DOMAINS."
> 
> Grant Cyboron
> 
> |-----Original Message-----
> |From: Dimitri Papadimitriou [mailto:[email-masked]]
> |Sent: Thursday, May 24, 2001 6:27 AM
> |To: Zhi-Wei Lin
> |Cc: John Drake; 'Lazer, Monica A, NNAD'; 'Heiles Juergen'; 'Mannie,
> |Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan';
> [email-masked]; [email-masked]; t1x1.5; q11/15
> |Subject: Re: [T1X1.5] RE: Proposed text for the concatenation
> |
> |
> |Dear all,
> |
> |So we could add the following text to the proposed sentence (in
> |capital letters) - see previous e-mail - :
> |
> |"Some of the features described in this specification are not defined
> |either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and
> |2000) OR IN ANY OTHER APPROVED DOCUMENT COMING FROM STANDARDIZATION
> |BODIES DEALING WITH SONET/SDH."
> |
> |If this applies for the corresponding feature then the footnote could
> |be aligned with this text as well.
> |
> |Kind regards,
> |Dimitri.
> |
> |Zhi-Wei Lin wrote:
> |>
> |> Hi John,
> |>
> |> Yes, The signalling can be compliant to GMPLS. But what
> |would that mean
> |> for compliance of the transport network?
> |>
> |> As I mentioned a while back, interworking is needed in two levels,
> |> signalling interworking AND transport interworking.
> |>
> |> Signalling interworking can be fairly easy I think. Transport
> |> interworking would be hard, because of all the physical layer aspects
> |> that needs to be considered. If we're not familiar with what these
> |> aspects are, then I guess we cannot and should not be making
> |decisions
> |> and let the experts do it...
> |>
> |> As for "multiple standards bodies", yes there are more than one
> |> standards bodies working on this, but they all work TOGETHER
> |and align
> |> with each other, and the folks working on this are experts
> |in the area
> |> who's been in the industry for MANY years. ANSI document specifies
> |> SONET. So does Telcordia GRs. ITU Recommendation specifies
> |SDH. So does
> |> ETSI specs.
> |>
> |> Zhi
> |>
> |> John Drake wrote:
> |> >
> |> > Monica,
> |> >
> |> > When you say standards compliant, which standards bodies are you
> |> > considering?  I.e., from one of Eric's
> |> > notes I got the impression that there were actually
> |multiple bodies that had
> |> > defined SONET/SDH features.
> |> > Further, we could indicate that implementations of GMPLS
> |signalling are are
> |> > GMPLS compliant - see 'self
> |> > defining term' in the index of Knuth vol 1.
> |> >
> |> > Thanks,
> |> >
> |> > John
> |> >
> |> > -----Original Message-----
> |> > From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> |> > Sent: Wednesday, May 23, 2001 1:42 PM
> |> > To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
> |> > Greg'; 'Bala Rajagopalan'
> |> > Cc: [email-masked]; [email-masked];
> |t1x1.5; q11/15
> |> > Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> |> >
> |> > From an operator's perspective, it is essential to clearly
> |flag the features
> |> > that are standards compliant from those, which deviate
> |from existing
> |> > standards, even when they are improvements to the
> |standards. The reason for
> |> > this is rooted in the need to have the ability to identify
> |all the relevant
> |> > issues when inter-working network elements from multiple
> |vendors in the same
> |> > networks, while taking advantage of new non-standard features.
> |> >
> |> > Monica A. Lazer
> |> > Advanced Transport Technology and Architecture Planning
> |> >
> |> > 908 234 8462
> |> > [email-masked]
> |> >
> |> > -----Original Message-----
> |> > From: Heiles Juergen [mailto:[email-masked]]
> |> > Sent: Wednesday, May 23, 2001 8:57 AM
> |> > To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg';
> |'Bala Rajagopalan'
> |> > Cc: [email-masked]; [email-masked];
> |t1x1.5; q11/15
> |> > Subject: [T1X1.5] RE: Proposed text for the concatenation
> |> >
> |> > The concatenation waves are going high here on the mailing list.
> |> > I attended the Paris editing session and didn't complain about the
> |> > proprietary solutions.
> |> > However the ongoing discussion showed me several points:
> |> > - When we start to introduce one proprietary solution we
> |open the document
> |> > for any proprietary solution, where will we stop (I want
> |B3 transparency and
> |> > I over connection setup for containers (without POH)? Do
> |we really want to
> |> > define the signaling support for single, two, three vendor
> |solutions. I
> |> > would leave this to the vendors. They implemented a
> |proprietary transport
> |> > plane solution so they can also define their proprietary
> |control plane
> |> > solution. If we have a broader interest in the feature we
> |should look at the
> |> > application and consider if it should be standardized both
> |for the transport
> |> > plane and the control plane.
> |> > - Remember that we define the control in order to support
> |the transport
> |> > plane and not vice versa. A stand alone transport plane
> |makes sense (and has
> |> > been in use for years), a stand alone control plane
> |doesn't. Interworking at
> |> > the control plane doesn't help much if the transport plane doesn't
> |> > interwork. So it should be a common standardization
> |activity both in the
> |> > control and in the transport plane.
> |> > - If we define something proprietary we need information
> |about the feature,
> |> > we cannot do it with guesses.
> |> > - We also have to be careful with proprietary features as
> |we don't know what
> |> > implications they have on the transport plane, they might
> |exclude each
> |> > other. That can happen as we focus only on the control
> |plane and don't care
> |> > about the implications at the transport plane. We can
> |generate a real mess.
> |> > - I don't want to restrict new ideas and developments.
> |Actually you cannot
> |> > kill a good solution that fits network needs by blocking
> |it from a standard.
> |> > If someone builds it and shows its advantages operators
> |will start to ask
> |> > for it.
> |> >
> |> > Now coming to Erics new proposed section:
> |> > In my view the proposal makes it even worse. Just say this
> |is a standard
> |> > feature and this is a proprietary feature. Don't start to
> |explain how we can
> |> > come form a proprietary  feature to interworking or a
> |standard. And don't
> |> > start to explain how the feature could be implemented. It
> |will bring you
> |> > into more trouble. This is a control plane document, nothing more.
> |> >
> |> > Arbitrary contiguous concatenation:
> |> > What are the relaxed limitations. Either say nothing or
> |define it in detail,
> |> > but the later is not the task of this document.
> |> >
> |> > Transparency:
> |> > RS and MS transparency is a standard feature, while transparency of
> |> > individual overhead bytes is not. You have to distinguish
> |between the two.
> |> > Transparency of individual bytes is an critical issue. You
> |violate the
> |> > layers and can screw up your whole management. In addition
> |it is not real
> |> > transparency what is needed, it is functional
> |transparency. For example for
> |> > B2. Or for the DCC bytes you might allow byte slips. But
> |what implications
> |> > has this on the DCN? It is easy to define a feature for
> |the control plane
> |> > and don't care about the transport plane implications.
> |> > Although you are a strong supporter of transparency, you
> |were very fast in
> |> > dropping the already included B2 transparency. Because it
> |is not a straight
> |> > forward solution? Requires some awkward processing? And
> |some people don't
> |> > understand how it works? That might be also true for other features
> |> > (flexible arbitrary concatenation). So why include one and
> |not the other?
> |> >
> |> > Flexible arbitrary contiguous concatenation:
> |> > You started to describe a implementation. You have a
> |certain solution in
> |> > your mind. I think about a completely different approach.
> |We both don't know
> |> > it exactly, we just guess. Is this a good base to achieve
> |interoperability.
> |> > One problem I see has to do with the AUG7STS Group signal
> |type, another
> |> > proprietary feature. The AUG/STS group signal type provides some
> |> > transparency concerning the underlying VC-3/4/4-Xc
> |structure. However as
> |> > pointer processing for the individual VCs is still
> |required in case of
> |> > multiplexing the network elements have to detect the VC-N
> |structure by
> |> > themselves using the pointer information (valid pointer,
> |concatenation
> |> > indication). But this doesn't work with flexible arbitrary
> |contiguous
> |> > concatenation, at least with the solution I have in mind.
> |Additional
> |> > information on the VCs that belong together is needed
> |in-band (SOH?) if
> |> > automatic detection should be supported. If it is not
> |supported it cannot be
> |> > part of a AUG/STS group signal type while all other types
> |of concatenation
> |> > can be. If it is supported you might not need a label set.
> |A label for the
> |> > first time slot is enough. The network element detects
> |which other belong to
> |> > the group. So from the currently available informatio!
> |> > !
> |> > !
> |> > n it is difficult to tell if the control plane support is correct.
> |> > One other question. The Sonet/SDH GMPLS document says that virtual
> |> > concatenation can be used with any contiguous
> |concatenation. Although with
> |> > flexible arbitrary contiguous concatenation as both
> |require a label set?
> |> >
> |> > Coming back to the AUG/STS group and TUG. I missed it in
> |your new proposed
> |> > section. It is a proprietary feature.
> |> > Dimitri mentioned that AUG-X is defined in G.707 but not
> |supported in G.783.
> |> > It should be noted that AUG/TUG are not and were never
> |intended to be
> |> > networking entities. They were introduced as internal
> |signal structures in
> |> > order to better describe the SDH multiplex process.
> |VC-11/12/2/3/4, MS and
> |> > RS are the networking entities.
> |> > A AUG/STS group or TUG provides some transparency
> |concerning the underlying
> |> > VC-N structure. IF you multiplex the signal you still have
> |to do pointer
> |> > processing for the individual VCs. As a AUG/STS group or
> |TUG has no overhead
> |> > of its own, any supervision has to be performed on the
> |individual VCs. So
> |> > what will it buy us ?(ok, ok better not to ask the
> |question, some one
> |> > supports it and has its good reasons to do so as it is the
> |case for any of
> |> > the above features)
> |> >
> |> > Regards
> |> >
> |> >         Juergen
> |> >
> |> > > -----Original Message-----
> |> > > From: Mannie, Eric [SMTP:[email-masked]]
> |> > > Sent: Tuesday, May 22, 2001 9:22 PM
> |> > > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> |> > > Cc:   [email-masked];
> [email-masked]; t1x1.5; q11/15
> |> > > Subject:      RE: Proposed text for the concatenation
> |> > >
> |> > > Hello Man Wing, Bala and All,
> |> > >
> |> > > >I think Eric's proposed text gives a very good coverage
> |on all cases
> |> > >
> |> > > Thanks :-)
> |> > >
> |> > > >and all we need is indicating which field is ... optional
> |> > >
> |> > > Indeed everything is already optional in the draft
> |except the signal type
> |> > of
> |> > > course:
> |> > >
> |> > >   - CCT: set to zero to say no contiguous concatenation
> |requested (default
> |> > > value)
> |> > >   - NCC: set to zero when CCT is set to zero (default value)
> |> > >   - NVC: set to zero to say no virtual concatenation
> |(default value).
> |> > >   - Multiplier: set to one if one instance (default value).
> |> > >   - transparency: set to zero to say don't care (default value).
> |> > >
> |> > > So there is no issue there, I will add a specific
> |paragraph to re-enforce
> |> > > it.
> |> > >
> |> > > In addition, when a downstream node receives an
> |"incoming request" he can
> |> > > decide to accept it or to refuse it depending of what is
> |requested,
> |> > > depending of the CAC process, depending of the customer
> |profile, depending
> |> > > of the capabilities that it supports, etc.
> |> > >
> |> > > The draft doesn't indicate what must be implemented of course.
> |> > >
> |> > > >and all we need is indicating which field is standard....
> |> > >
> |> > > Ok, I agree. Let's indicate in the draft the features
> |that are not
> |> > > standardized in G.707 and T1.105, i.e. arbitrary
> |concatenation, flexible
> |> > > concatenation, and transparency. Is there another one ?
> |All the signal
> |> > types
> |> > > have an equivalent definition in the standards.
> |> > >
> |> > > --- proposed new section:
> |> > >
> |> > > X. Relationship with SDH and SONET standards
> |> > >
> |> > > Some of the features described in this specification are
> |not defined
> |> > neither
> |> > > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996
> |and 2000).
> |> > However,
> |> > > these features are useful and implemented in many
> |equipment's. All these
> |> > > features are optional but can be controlled using this
> |specification.>
> |> > >
> |> > > These features are: arbitrary contiguous concatenation,
> |flexible arbitrary
> |> > > contiguous concatenation and transparency. They have
> |been > described in
> |> > the
> |> > > relevant sections of this specification.
> |> > >
> |> > > Arbitrary contiguous concatenation does not need any
> |additional standard
> |> > to
> |> > > interoperate. It simply relaxes some limitations specified in the
> |> > > corresponding AINSI and ITU-T standards.
> |> > >
> |> > > Transparency does not need any standard at the UNI since
> |it is only
> |> > > implemented in the data plane at the NNI. This can be
> |requested using the
> |> > > signaling at the UNI, independently of its
> |implementation at the NNI.
> |> > > Interoperability between multiple manufacturers at the
> |NNI can be achieved
> |> > > in different ways: through the use of a standard, an
> |implementation
> |> > > agreement made by a forum, or an implementation
> |agreement between two
> |> > > manufacturers (e.g. at the request of an operator).
> |> > >
> |> > > Flexible arbitrary contiguous concatenation just need a
> |very simple and
> |> > > obvious agreement to interoperate between multiple
> |manufacturers. Again
> |> > this
> |> > > can be achieved in different ways: through the use of a
> |standard, an
> |> > > implementation agreement made by a forum, or an
> |implementation agreement
> |> > > between two manufacturers (e.g. at the request of an
> |operator). A simple
> |> > > agreement could for instance simply indicate where is
> |copied the original
> |> > > path overhead when "inverse multiplexing" locally a contiguously
> |> > > concatenated signal (e.g. in the first VC/SPE POH). ---
> |I am not sure at
> |> > all
> |> > > about this paragraph, ideas are welcome, please help !
> |> > >
> |> > > ---------- End of text
> |> > >
> |> > > Agreed ? Comments ?
> |> > >
> |> > > Comments from our ITU-T folks are welcome (really :-)
> |> > >
> |> > > Kind regards,
> |> > >
> |> > > Eric
> |> > >
> |> > > -----Original Message-----
> |> > > From: Fong, Man Wing [mailto:[email-masked]]
> |> > > Sent: Tuesday, May 22, 2001 5:15 PM
> |> > > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> |> > > Cc: [email-masked]; [email-masked]
> |> > > Subject: RE: Proposed text for the concatenation
> |> > >
> |> > >
> |> > > Very good point, Greg. If I remember correctly, the initial email
> |> > initiated
> |> > > such a great discussion was someone asked about whether
> |it was worth
> |> > > investing development effort on arbitrary concatenation.
> |The bottom line
> |> > is
> |> > > if there is an appearing business case for the feature,
> |then you will
> |> > > support it. As some of you (vendors) already indicated
> |that your systems
> |> > > support AC because there are operators using and asking
> |for this feature.
> |> > > There might be a lot of vendors and users supporting
> |this or might be just
> |> > a
> |> > > few, but the fact is there are someone supporting it.
> |When defining new
> |> > > protocols, I agree that we should consider and cover all
> |cases, as long as
> |> > > any non-standard fields are optional.
> |> > > I think Eric's proposed text gives a very good coverage
> |on all cases and
> |> > all
> |> > > we need is indicating which field is non-standard and optional.
> |> > >
> |> > > Man Wing
> |> > >
> |> > >
> |
--------------8FE6A6BE36B5E41D73F03BE5
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------8FE6A6BE36B5E41D73F03BE5--

Delivery-date: Thu, 24 May 2001 03:31:42 -0700
Date: Thu, 24 May 2001 12:26:33 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Zhi-Wei Lin <[email-masked]>
CC: John Drake <[email-masked]>, "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------C6C9DAFCB8E09E40D2483723
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear all,

So we could add the following text to the proposed sentence (in 
capital letters) - see previous e-mail - :

"Some of the features described in this specification are not defined
either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and 
2000) OR IN ANY OTHER APPROVED DOCUMENT COMING FROM STANDARDIZATION 
BODIES DEALING WITH SONET/SDH." 

If this applies for the corresponding feature then the footnote could
be aligned with this text as well.

Kind regards,
Dimitri.

Zhi-Wei Lin wrote:
> 
> Hi John,
> 
> Yes, The signalling can be compliant to GMPLS. But what would that mean
> for compliance of the transport network?
> 
> As I mentioned a while back, interworking is needed in two levels,
> signalling interworking AND transport interworking.
> 
> Signalling interworking can be fairly easy I think. Transport
> interworking would be hard, because of all the physical layer aspects
> that needs to be considered. If we're not familiar with what these
> aspects are, then I guess we cannot and should not be making decisions
> and let the experts do it...
> 
> As for "multiple standards bodies", yes there are more than one
> standards bodies working on this, but they all work TOGETHER and align
> with each other, and the folks working on this are experts in the area
> who's been in the industry for MANY years. ANSI document specifies
> SONET. So does Telcordia GRs. ITU Recommendation specifies SDH. So does
> ETSI specs.
> 
> Zhi
> 
> John Drake wrote:
> >
> > Monica,
> >
> > When you say standards compliant, which standards bodies are you
> > considering?  I.e., from one of Eric's
> > notes I got the impression that there were actually multiple bodies that had
> > defined SONET/SDH features.
> > Further, we could indicate that implementations of GMPLS signalling are are
> > GMPLS compliant - see 'self
> > defining term' in the index of Knuth vol 1.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 1:42 PM
> > To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
> > Greg'; 'Bala Rajagopalan'
> > Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> >
> > From an operator's perspective, it is essential to clearly flag the features
> > that are standards compliant from those, which deviate from existing
> > standards, even when they are improvements to the standards. The reason for
> > this is rooted in the need to have the ability to identify all the relevant
> > issues when inter-working network elements from multiple vendors in the same
> > networks, while taking advantage of new non-standard features.
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > [email-masked]
> >
> > -----Original Message-----
> > From: Heiles Juergen [mailto:[email-masked]]
> > Sent: Wednesday, May 23, 2001 8:57 AM
> > To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject: [T1X1.5] RE: Proposed text for the concatenation
> >
> > The concatenation waves are going high here on the mailing list.
> > I attended the Paris editing session and didn't complain about the
> > proprietary solutions.
> > However the ongoing discussion showed me several points:
> > - When we start to introduce one proprietary solution we open the document
> > for any proprietary solution, where will we stop (I want B3 transparency and
> > I over connection setup for containers (without POH)? Do we really want to
> > define the signaling support for single, two, three vendor solutions. I
> > would leave this to the vendors. They implemented a proprietary transport
> > plane solution so they can also define their proprietary control plane
> > solution. If we have a broader interest in the feature we should look at the
> > application and consider if it should be standardized both for the transport
> > plane and the control plane.
> > - Remember that we define the control in order to support the transport
> > plane and not vice versa. A stand alone transport plane makes sense (and has
> > been in use for years), a stand alone control plane doesn't. Interworking at
> > the control plane doesn't help much if the transport plane doesn't
> > interwork. So it should be a common standardization activity both in the
> > control and in the transport plane.
> > - If we define something proprietary we need information about the feature,
> > we cannot do it with guesses.
> > - We also have to be careful with proprietary features as we don't know what
> > implications they have on the transport plane, they might exclude each
> > other. That can happen as we focus only on the control plane and don't care
> > about the implications at the transport plane. We can generate a real mess.
> > - I don't want to restrict new ideas and developments. Actually you cannot
> > kill a good solution that fits network needs by blocking it from a standard.
> > If someone builds it and shows its advantages operators will start to ask
> > for it.
> >
> > Now coming to Erics new proposed section:
> > In my view the proposal makes it even worse. Just say this is a standard
> > feature and this is a proprietary feature. Don't start to explain how we can
> > come form a proprietary  feature to interworking or a standard. And don't
> > start to explain how the feature could be implemented. It will bring you
> > into more trouble. This is a control plane document, nothing more.
> >
> > Arbitrary contiguous concatenation:
> > What are the relaxed limitations. Either say nothing or define it in detail,
> > but the later is not the task of this document.
> >
> > Transparency:
> > RS and MS transparency is a standard feature, while transparency of
> > individual overhead bytes is not. You have to distinguish between the two.
> > Transparency of individual bytes is an critical issue. You violate the
> > layers and can screw up your whole management. In addition it is not real
> > transparency what is needed, it is functional transparency. For example for
> > B2. Or for the DCC bytes you might allow byte slips. But what implications
> > has this on the DCN? It is easy to define a feature for the control plane
> > and don't care about the transport plane implications.
> > Although you are a strong supporter of transparency, you were very fast in
> > dropping the already included B2 transparency. Because it is not a straight
> > forward solution? Requires some awkward processing? And some people don't
> > understand how it works? That might be also true for other features
> > (flexible arbitrary concatenation). So why include one and not the other?
> >
> > Flexible arbitrary contiguous concatenation:
> > You started to describe a implementation. You have a certain solution in
> > your mind. I think about a completely different approach. We both don't know
> > it exactly, we just guess. Is this a good base to achieve interoperability.
> > One problem I see has to do with the AUG7STS Group signal type, another
> > proprietary feature. The AUG/STS group signal type provides some
> > transparency concerning the underlying VC-3/4/4-Xc structure. However as
> > pointer processing for the individual VCs is still required in case of
> > multiplexing the network elements have to detect the VC-N structure by
> > themselves using the pointer information (valid pointer, concatenation
> > indication). But this doesn't work with flexible arbitrary contiguous
> > concatenation, at least with the solution I have in mind. Additional
> > information on the VCs that belong together is needed in-band (SOH?) if
> > automatic detection should be supported. If it is not supported it cannot be
> > part of a AUG/STS group signal type while all other types of concatenation
> > can be. If it is supported you might not need a label set. A label for the
> > first time slot is enough. The network element detects which other belong to
> > the group. So from the currently available informatio!
> > !
> > !
> > n it is difficult to tell if the control plane support is correct.
> > One other question. The Sonet/SDH GMPLS document says that virtual
> > concatenation can be used with any contiguous concatenation. Although with
> > flexible arbitrary contiguous concatenation as both require a label set?
> >
> > Coming back to the AUG/STS group and TUG. I missed it in your new proposed
> > section. It is a proprietary feature.
> > Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
> > It should be noted that AUG/TUG are not and were never intended to be
> > networking entities. They were introduced as internal signal structures in
> > order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
> > RS are the networking entities.
> > A AUG/STS group or TUG provides some transparency concerning the underlying
> > VC-N structure. IF you multiplex the signal you still have to do pointer
> > processing for the individual VCs. As a AUG/STS group or TUG has no overhead
> > of its own, any supervision has to be performed on the individual VCs. So
> > what will it buy us ?(ok, ok better not to ask the question, some one
> > supports it and has its good reasons to do so as it is the case for any of
> > the above features)
> >
> > Regards
> >
> >         Juergen
> >
> > > -----Original Message-----
> > > From: Mannie, Eric [SMTP:[email-masked]]
> > > Sent: Tuesday, May 22, 2001 9:22 PM
> > > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > > Subject:      RE: Proposed text for the concatenation
> > >
> > > Hello Man Wing, Bala and All,
> > >
> > > >I think Eric's proposed text gives a very good coverage on all cases
> > >
> > > Thanks :-)
> > >
> > > >and all we need is indicating which field is ... optional
> > >
> > > Indeed everything is already optional in the draft except the signal type
> > of
> > > course:
> > >
> > >   - CCT: set to zero to say no contiguous concatenation requested (default
> > > value)
> > >   - NCC: set to zero when CCT is set to zero (default value)
> > >   - NVC: set to zero to say no virtual concatenation (default value).
> > >   - Multiplier: set to one if one instance (default value).
> > >   - transparency: set to zero to say don't care (default value).
> > >
> > > So there is no issue there, I will add a specific paragraph to re-enforce
> > > it.
> > >
> > > In addition, when a downstream node receives an "incoming request" he can
> > > decide to accept it or to refuse it depending of what is requested,
> > > depending of the CAC process, depending of the customer profile, depending
> > > of the capabilities that it supports, etc.
> > >
> > > The draft doesn't indicate what must be implemented of course.
> > >
> > > >and all we need is indicating which field is standard....
> > >
> > > Ok, I agree. Let's indicate in the draft the features that are not
> > > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > > concatenation, and transparency. Is there another one ? All the signal
> > types
> > > have an equivalent definition in the standards.
> > >
> > > --- proposed new section:
> > >
> > > X. Relationship with SDH and SONET standards
> > >
> > > Some of the features described in this specification are not defined
> > neither
> > > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
> > However,
> > > these features are useful and implemented in many equipment's. All these
> > > features are optional but can be controlled using this specification.>
> > >
> > > These features are: arbitrary contiguous concatenation, flexible arbitrary
> > > contiguous concatenation and transparency. They have been > described in
> > the
> > > relevant sections of this specification.
> > >
> > > Arbitrary contiguous concatenation does not need any additional standard
> > to
> > > interoperate. It simply relaxes some limitations specified in the
> > > corresponding AINSI and ITU-T standards.
> > >
> > > Transparency does not need any standard at the UNI since it is only
> > > implemented in the data plane at the NNI. This can be requested using the
> > > signaling at the UNI, independently of its implementation at the NNI.
> > > Interoperability between multiple manufacturers at the NNI can be achieved
> > > in different ways: through the use of a standard, an implementation
> > > agreement made by a forum, or an implementation agreement between two
> > > manufacturers (e.g. at the request of an operator).
> > >
> > > Flexible arbitrary contiguous concatenation just need a very simple and
> > > obvious agreement to interoperate between multiple manufacturers. Again
> > this
> > > can be achieved in different ways: through the use of a standard, an
> > > implementation agreement made by a forum, or an implementation agreement
> > > between two manufacturers (e.g. at the request of an operator). A simple
> > > agreement could for instance simply indicate where is copied the original
> > > path overhead when "inverse multiplexing" locally a contiguously
> > > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
> > all
> > > about this paragraph, ideas are welcome, please help !
> > >
> > > ---------- End of text
> > >
> > > Agreed ? Comments ?
> > >
> > > Comments from our ITU-T folks are welcome (really :-)
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > -----Original Message-----
> > > From: Fong, Man Wing [mailto:[email-masked]]
> > > Sent: Tuesday, May 22, 2001 5:15 PM
> > > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: Proposed text for the concatenation
> > >
> > >
> > > Very good point, Greg. If I remember correctly, the initial email
> > initiated
> > > such a great discussion was someone asked about whether it was worth
> > > investing development effort on arbitrary concatenation. The bottom line
> > is
> > > if there is an appearing business case for the feature, then you will
> > > support it. As some of you (vendors) already indicated that your systems
> > > support AC because there are operators using and asking for this feature.
> > > There might be a lot of vendors and users supporting this or might be just
> > a
> > > few, but the fact is there are someone supporting it. When defining new
> > > protocols, I agree that we should consider and cover all cases, as long as
> > > any non-standard fields are optional.
> > > I think Eric's proposed text gives a very good coverage on all cases and
> > all
> > > we need is indicating which field is non-standard and optional.
> > >
> > > Man Wing
> > >
> > >
--------------C6C9DAFCB8E09E40D2483723
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------C6C9DAFCB8E09E40D2483723--

Delivery-date: Wed, 23 May 2001 20:46:48 -0700
Date: Wed, 23 May 2001 23:46:43 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: Proposed text for the concatenation

Hi John,

Yes, The signalling can be compliant to GMPLS. But what would that mean
for compliance of the transport network? 

As I mentioned a while back, interworking is needed in two levels,
signalling interworking AND transport interworking. 

Signalling interworking can be fairly easy I think. Transport
interworking would be hard, because of all the physical layer aspects
that needs to be considered. If we're not familiar with what these
aspects are, then I guess we cannot and should not be making decisions
and let the experts do it...

As for "multiple standards bodies", yes there are more than one
standards bodies working on this, but they all work TOGETHER and align
with each other, and the folks working on this are experts in the area
who's been in the industry for MANY years. ANSI document specifies
SONET. So does Telcordia GRs. ITU Recommendation specifies SDH. So does
ETSI specs. 

Zhi

John Drake wrote:
> 
> Monica,
> 
> When you say standards compliant, which standards bodies are you
> considering?  I.e., from one of Eric's
> notes I got the impression that there were actually multiple bodies that had
> defined SONET/SDH features.
> Further, we could indicate that implementations of GMPLS signalling are are
> GMPLS compliant - see 'self
> defining term' in the index of Knuth vol 1.
> 
> Thanks,
> 
> John
> 
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 1:42 PM
> To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
> Greg'; 'Bala Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> 
> From an operator's perspective, it is essential to clearly flag the features
> that are standards compliant from those, which deviate from existing
> standards, even when they are improvements to the standards. The reason for
> this is rooted in the need to have the ability to identify all the relevant
> issues when inter-working network elements from multiple vendors in the same
> networks, while taking advantage of new non-standard features.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 8:57 AM
> To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: [T1X1.5] RE: Proposed text for the concatenation
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the document
> for any proprietary solution, where will we stop (I want B3 transparency and
> I over connection setup for containers (without POH)? Do we really want to
> define the signaling support for single, two, three vendor solutions. I
> would leave this to the vendors. They implemented a proprietary transport
> plane solution so they can also define their proprietary control plane
> solution. If we have a broader interest in the feature we should look at the
> application and consider if it should be standardized both for the transport
> plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and has
> been in use for years), a stand alone control plane doesn't. Interworking at
> the control plane doesn't help much if the transport plane doesn't
> interwork. So it should be a common standardization activity both in the
> control and in the transport plane.
> - If we define something proprietary we need information about the feature,
> we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know what
> implications they have on the transport plane, they might exclude each
> other. That can happen as we focus only on the control plane and don't care
> about the implications at the transport plane. We can generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you cannot
> kill a good solution that fits network needs by blocking it from a standard.
> If someone builds it and shows its advantages operators will start to ask
> for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we can
> come form a proprietary  feature to interworking or a standard. And don't
> start to explain how the feature could be implemented. It will bring you
> into more trouble. This is a control plane document, nothing more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in detail,
> but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not real
> transparency what is needed, it is functional transparency. For example for
> B2. Or for the DCC bytes you might allow byte slips. But what implications
> has this on the DCN? It is easy to define a feature for the control plane
> and don't care about the transport plane implications.
> Although you are a strong supporter of transparency, you were very fast in
> dropping the already included B2 transparency. Because it is not a straight
> forward solution? Requires some awkward processing? And some people don't
> understand how it works? That might be also true for other features
> (flexible arbitrary concatenation). So why include one and not the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't know
> it exactly, we just guess. Is this a good base to achieve interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it cannot be
> part of a AUG/STS group signal type while all other types of concatenation
> can be. If it is supported you might not need a label set. A label for the
> first time slot is enough. The network element detects which other belong to
> the group. So from the currently available informatio!
> !
> !
> n it is difficult to tell if the control plane support is correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although with
> flexible arbitrary contiguous concatenation as both require a label set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new proposed
> section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
> It should be noted that AUG/TUG are not and were never intended to be
> networking entities. They were introduced as internal signal structures in
> order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
> RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the underlying
> VC-N structure. IF you multiplex the signal you still have to do pointer
> processing for the individual VCs. As a AUG/STS group or TUG has no overhead
> of its own, any supervision has to be performed on the individual VCs. So
> what will it buy us ?(ok, ok better not to ask the question, some one
> supports it and has its good reasons to do so as it is the case for any of
> the above features)
> 
> Regards
> 
>         Juergen
> 
> > -----Original Message-----
> > From: Mannie, Eric [SMTP:[email-masked]]
> > Sent: Tuesday, May 22, 2001 9:22 PM
> > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject:      RE: Proposed text for the concatenation
> >
> > Hello Man Wing, Bala and All,
> >
> > >I think Eric's proposed text gives a very good coverage on all cases
> >
> > Thanks :-)
> >
> > >and all we need is indicating which field is ... optional
> >
> > Indeed everything is already optional in the draft except the signal type
> of
> > course:
> >
> >   - CCT: set to zero to say no contiguous concatenation requested (default
> > value)
> >   - NCC: set to zero when CCT is set to zero (default value)
> >   - NVC: set to zero to say no virtual concatenation (default value).
> >   - Multiplier: set to one if one instance (default value).
> >   - transparency: set to zero to say don't care (default value).
> >
> > So there is no issue there, I will add a specific paragraph to re-enforce
> > it.
> >
> > In addition, when a downstream node receives an "incoming request" he can
> > decide to accept it or to refuse it depending of what is requested,
> > depending of the CAC process, depending of the customer profile, depending
> > of the capabilities that it supports, etc.
> >
> > The draft doesn't indicate what must be implemented of course.
> >
> > >and all we need is indicating which field is standard....
> >
> > Ok, I agree. Let's indicate in the draft the features that are not
> > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > concatenation, and transparency. Is there another one ? All the signal
> types
> > have an equivalent definition in the standards.
> >
> > --- proposed new section:
> >
> > X. Relationship with SDH and SONET standards
> >
> > Some of the features described in this specification are not defined
> neither
> > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
> However,
> > these features are useful and implemented in many equipment's. All these
> > features are optional but can be controlled using this specification.>
> >
> > These features are: arbitrary contiguous concatenation, flexible arbitrary
> > contiguous concatenation and transparency. They have been > described in
> the
> > relevant sections of this specification.
> >
> > Arbitrary contiguous concatenation does not need any additional standard
> to
> > interoperate. It simply relaxes some limitations specified in the
> > corresponding AINSI and ITU-T standards.
> >
> > Transparency does not need any standard at the UNI since it is only
> > implemented in the data plane at the NNI. This can be requested using the
> > signaling at the UNI, independently of its implementation at the NNI.
> > Interoperability between multiple manufacturers at the NNI can be achieved
> > in different ways: through the use of a standard, an implementation
> > agreement made by a forum, or an implementation agreement between two
> > manufacturers (e.g. at the request of an operator).
> >
> > Flexible arbitrary contiguous concatenation just need a very simple and
> > obvious agreement to interoperate between multiple manufacturers. Again
> this
> > can be achieved in different ways: through the use of a standard, an
> > implementation agreement made by a forum, or an implementation agreement
> > between two manufacturers (e.g. at the request of an operator). A simple
> > agreement could for instance simply indicate where is copied the original
> > path overhead when "inverse multiplexing" locally a contiguously
> > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
> all
> > about this paragraph, ideas are welcome, please help !
> >
> > ---------- End of text
> >
> > Agreed ? Comments ?
> >
> > Comments from our ITU-T folks are welcome (really :-)
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 5:15 PM
> > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Proposed text for the concatenation
> >
> >
> > Very good point, Greg. If I remember correctly, the initial email
> initiated
> > such a great discussion was someone asked about whether it was worth
> > investing development effort on arbitrary concatenation. The bottom line
> is
> > if there is an appearing business case for the feature, then you will
> > support it. As some of you (vendors) already indicated that your systems
> > support AC because there are operators using and asking for this feature.
> > There might be a lot of vendors and users supporting this or might be just
> a
> > few, but the fact is there are someone supporting it. When defining new
> > protocols, I agree that we should consider and cover all cases, as long as
> > any non-standard fields are optional.
> > I think Eric's proposed text gives a very good coverage on all cases and
> all
> > we need is indicating which field is non-standard and optional.
> >
> > Man Wing
> >
> >

Delivery-date: Wed, 23 May 2001 20:40:53 -0700
Date: Wed, 23 May 2001 23:40:47 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Heiles Juergen'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: Proposed text for the concatenation

HI Eric,

As long as we define the evaluation metric for how/why each feature gets
into the document.

After we make that decision, then we can add footnotes to say why they
were added.

So, what is the metric for deciding? I'm sure there are many vendors who
are reading this waiting to add their "unique" features to the document
as well...

Zhi

"Mannie, Eric" wrote:
> 
> Hello Monica,
> 
> I fully agree with you and with the comments made by Dimitri, Lyndon and
> Bala. The idea of the footnote to flag the features is a good consensus.
> 
> Is that ok for Juergen, Maarten and the others ?
> 
> Thanks,
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Lazer, Monica A, NNAD [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 10:42 PM
> To: 'Heiles Juergen'; Mannie, Eric; 'Fong, Man Wing'; 'Bernstein, Greg';
> 'Bala Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> 
> From an operator's perspective, it is essential to clearly flag the features
> that are standards compliant from those, which deviate from existing
> standards, even when they are improvements to the standards. The reason for
> this is rooted in the need to have the ability to identify all the relevant
> issues when inter-working network elements from multiple vendors in the same
> networks, while taking advantage of new non-standard features.
> 
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
> 
> 908 234 8462
> [email-masked]
> 
> -----Original Message-----
> From: Heiles Juergen [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 8:57 AM
> To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: [T1X1.5] RE: Proposed text for the concatenation
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the
> proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the document
> for any proprietary solution, where will we stop (I want B3 transparency and
> I over connection setup for containers (without POH)? Do we really want to
> define the signaling support for single, two, three vendor solutions. I
> would leave this to the vendors. They implemented a proprietary transport
> plane solution so they can also define their proprietary control plane
> solution. If we have a broader interest in the feature we should look at the
> application and consider if it should be standardized both for the transport
> plane and the control plane.
> - Remember that we define the control in order to support the transport
> plane and not vice versa. A stand alone transport plane makes sense (and has
> been in use for years), a stand alone control plane doesn't. Interworking at
> the control plane doesn't help much if the transport plane doesn't
> interwork. So it should be a common standardization activity both in the
> control and in the transport plane.
> - If we define something proprietary we need information about the feature,
> we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know what
> implications they have on the transport plane, they might exclude each
> other. That can happen as we focus only on the control plane and don't care
> about the implications at the transport plane. We can generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you cannot
> kill a good solution that fits network needs by blocking it from a standard.
> If someone builds it and shows its advantages operators will start to ask
> for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard
> feature and this is a proprietary feature. Don't start to explain how we can
> come form a proprietary  feature to interworking or a standard. And don't
> start to explain how the feature could be implemented. It will bring you
> into more trouble. This is a control plane document, nothing more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in detail,
> but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of
> individual overhead bytes is not. You have to distinguish between the two.
> Transparency of individual bytes is an critical issue. You violate the
> layers and can screw up your whole management. In addition it is not real
> transparency what is needed, it is functional transparency. For example for
> B2. Or for the DCC bytes you might allow byte slips. But what implications
> has this on the DCN? It is easy to define a feature for the control plane
> and don't care about the transport plane implications.
> Although you are a strong supporter of transparency, you were very fast in
> dropping the already included B2 transparency. Because it is not a straight
> forward solution? Requires some awkward processing? And some people don't
> understand how it works? That might be also true for other features
> (flexible arbitrary concatenation). So why include one and not the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in
> your mind. I think about a completely different approach. We both don't know
> it exactly, we just guess. Is this a good base to achieve interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another
> proprietary feature. The AUG/STS group signal type provides some
> transparency concerning the underlying VC-3/4/4-Xc structure. However as
> pointer processing for the individual VCs is still required in case of
> multiplexing the network elements have to detect the VC-N structure by
> themselves using the pointer information (valid pointer, concatenation
> indication). But this doesn't work with flexible arbitrary contiguous
> concatenation, at least with the solution I have in mind. Additional
> information on the VCs that belong together is needed in-band (SOH?) if
> automatic detection should be supported. If it is not supported it cannot be
> part of a AUG/STS group signal type while all other types of concatenation
> can be. If it is supported you might not need a label set. A label for the
> first time slot is enough. The network element detects which other belong to
> the group. So from the currently available informatio!
> !
> !
> n it is difficult to tell if the control plane support is correct.
> One other question. The Sonet/SDH GMPLS document says that virtual
> concatenation can be used with any contiguous concatenation. Although with
> flexible arbitrary contiguous concatenation as both require a label set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new proposed
> section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
> It should be noted that AUG/TUG are not and were never intended to be
> networking entities. They were introduced as internal signal structures in
> order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
> RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the underlying
> VC-N structure. IF you multiplex the signal you still have to do pointer
> processing for the individual VCs. As a AUG/STS group or TUG has no overhead
> of its own, any supervision has to be performed on the individual VCs. So
> what will it buy us ?(ok, ok better not to ask the question, some one
> supports it and has its good reasons to do so as it is the case for any of
> the above features)
> 
> Regards
> 
>         Juergen
> 
> > -----Original Message-----
> > From: Mannie, Eric [SMTP:[email-masked]]
> > Sent: Tuesday, May 22, 2001 9:22 PM
> > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject:      RE: Proposed text for the concatenation
> >
> > Hello Man Wing, Bala and All,
> >
> > >I think Eric's proposed text gives a very good coverage on all cases
> >
> > Thanks :-)
> >
> > >and all we need is indicating which field is ... optional
> >
> > Indeed everything is already optional in the draft except the signal type
> of
> > course:
> >
> >   - CCT: set to zero to say no contiguous concatenation requested (default
> > value)
> >   - NCC: set to zero when CCT is set to zero (default value)
> >   - NVC: set to zero to say no virtual concatenation (default value).
> >   - Multiplier: set to one if one instance (default value).
> >   - transparency: set to zero to say don't care (default value).
> >
> > So there is no issue there, I will add a specific paragraph to re-enforce
> > it.
> >
> > In addition, when a downstream node receives an "incoming request" he can
> > decide to accept it or to refuse it depending of what is requested,
> > depending of the CAC process, depending of the customer profile, depending
> > of the capabilities that it supports, etc.
> >
> > The draft doesn't indicate what must be implemented of course.
> >
> > >and all we need is indicating which field is standard....
> >
> > Ok, I agree. Let's indicate in the draft the features that are not
> > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > concatenation, and transparency. Is there another one ? All the signal
> types
> > have an equivalent definition in the standards.
> >
> > --- proposed new section:
> >
> > X. Relationship with SDH and SONET standards
> >
> > Some of the features described in this specification are not defined
> neither
> > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
> However,
> > these features are useful and implemented in many equipment's. All these
> > features are optional but can be controlled using this specification.>
> >
> > These features are: arbitrary contiguous concatenation, flexible arbitrary
> > contiguous concatenation and transparency. They have been > described in
> the
> > relevant sections of this specification.
> >
> > Arbitrary contiguous concatenation does not need any additional standard
> to
> > interoperate. It simply relaxes some limitations specified in the
> > corresponding AINSI and ITU-T standards.
> >
> > Transparency does not need any standard at the UNI since it is only
> > implemented in the data plane at the NNI. This can be requested using the
> > signaling at the UNI, independently of its implementation at the NNI.
> > Interoperability between multiple manufacturers at the NNI can be achieved
> > in different ways: through the use of a standard, an implementation
> > agreement made by a forum, or an implementation agreement between two
> > manufacturers (e.g. at the request of an operator).
> >
> > Flexible arbitrary contiguous concatenation just need a very simple and
> > obvious agreement to interoperate between multiple manufacturers. Again
> this
> > can be achieved in different ways: through the use of a standard, an
> > implementation agreement made by a forum, or an implementation agreement
> > between two manufacturers (e.g. at the request of an operator). A simple
> > agreement could for instance simply indicate where is copied the original
> > path overhead when "inverse multiplexing" locally a contiguously
> > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
> all
> > about this paragraph, ideas are welcome, please help !
> >
> > ---------- End of text
> >
> > Agreed ? Comments ?
> >
> > Comments from our ITU-T folks are welcome (really :-)
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 5:15 PM
> > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Proposed text for the concatenation
> >
> >
> > Very good point, Greg. If I remember correctly, the initial email
> initiated
> > such a great discussion was someone asked about whether it was worth
> > investing development effort on arbitrary concatenation. The bottom line
> is
> > if there is an appearing business case for the feature, then you will
> > support it. As some of you (vendors) already indicated that your systems
> > support AC because there are operators using and asking for this feature.
> > There might be a lot of vendors and users supporting this or might be just
> a
> > few, but the fact is there are someone supporting it. When defining new
> > protocols, I agree that we should consider and cover all cases, as long as
> > any non-standard fields are optional.
> > I think Eric's proposed text gives a very good coverage on all cases and
> all
> > we need is indicating which field is non-standard and optional.
> >
> > Man Wing
> >
> >

Delivery-date: Wed, 23 May 2001 20:38:03 -0700
Date: Wed, 23 May 2001 23:37:39 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Guo-Qiang Wang'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

I think your questions cannot be answered either way. Whether features
are needed for one or two vendors is up to each vendor to decide what
they want. 

As for how many vendor is needed for a standard. Again this question
doesn't really apply. We as engineers and the development community has
to study a problem to make sure that it will not unduly impact existing
networks, that what we are looking at should be sound and technically
superior and that it will help provide added value to networks. As these
transport capabilities will likely require people of transport expertise
to study first, that's what we should do. Let's not get too "trigger
happy" and include something "just because it's there", and then decide
to remove when "standards say no". That like "putting the cart in front
of the horse".

As to how many companies and how many people's names are on the
contribution. Let's be intelligent adults here. As someone once asked
me, "if you see a million flies eating feces, would you also eat?"
(sorry people! it is disgusting but I had to give an extreme analogy).
Sometimes the majority may not be correct. I am not saying I am correct
either. It all depends on the background knowledge base and the
underlying motive of the people...

As to how many processes followed, how many meetings held, how many
conferences given, how many emails exchanged...an idea doesn't get
better with repetition. As someone once said at some standards meeting
"if an idea stinks, it doesn't matter how many times some idea is
presented, it still stinks that many times". So the number of times is
not a reason for making a decision. 

Let's be technical, let the experts in the right group decide, and we
should not jump the gun. Let's be adults and let's help make the telecom
industry and the standards process a respectable place...

"Mannie, Eric" wrote:

> I don't work for a vendor :-) Who told you that some features are needed
> only for one or two vendors ? How do you quantify the number of vendors that
> are needed to have a standard ? We work on a consensus based and this draft
> has 17 companies on it with 30 people. Usually it is much much less at the
> IETF, you only have a small number of co-authors. I already gave a summary
> of the process that we followed, all the meetings that we hold, all the
> conference call that we hold, all the e-mails that we exchanged, etc.
> 
> You described one model in your e-mail, that's a valid model but this is not
> THE (only) model. There are plenty of other models that can be fulfilled
> with GMPLS.
> 
> Kind regards,
> 
> Eric
>

Delivery-date: Wed, 23 May 2001 20:19:26 -0700
Date: Wed, 23 May 2001 23:18:54 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: "'Guo-Qiang Wang'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Hi,

A few general comments...

Seems we all have different ideas about what "proprietary" means and
what "standard" means. I hear two things:

Proprietary #1 -- if more than two vendors implement, then it is not
proprietary. Then what is it? Standard?

Proprietary #2 -- any extensions or differences from that which is
specified by a standards body. This includes features that may be
supported by 99% of the vendors, but is still proprietary if not
introduced and standardized by the standards body.

The other thing I see in the discussion is...some features may belong in
the document while others may not.

==> What is the criteria that we are using in evaluating which feature
gets into the document, and which feature stays out? There are many
vendors in the industry. I am fairly certain that each vendor will have
a "unique" capability that their box can support. Some of these features
may be VERY similar amongst a set of vendors. If we open up to the
proprietary #1 definition, I am sure that there are many additional
features that will need to be added. 

Let's be democratic...define what evaluation metric is used, then let's
compare features and allow ALL vendors the opportunity to prove to meet
the metric...

or decide only standards-based capability is supported, but mention that
control plane can always be extended to support proprietary
extensions...

Zhi

"Mannie, Eric" wrote:
> 
> Hello Guo-Qiang,
> 
> I would like again to clarify a few important points:
> 
> - we are doing signaling and not an implementation profile, not a data plane
> specification.
> - ****almost all the features are optional****.
> - put the field to zero to say: "no way, I don't want to hear about that".
> - the fact that a feature is in the signaling does not mean that it must be
> implemented.
> - you can claim to be compliant with the draft without implementing some
> features.
> - a basic signaling implementation that allows *only* to open a VC-4 circuit
> is compliant.
> - you can ignore what you don't want to implement or just pick up what you
> want.
> - GMPLS is a toolbox, we don't say which tools to use, it is up to you to
> decide.
> 
> We don't try to restrict the draft to only the features that are implemented
> or implementable by *all* the manufacturers because this is an endless
> discussion and that's exactly what is happening now.
> 
> Some features that we want to control are not standardized by the ITU-T, but
> they exist, they are implemented by manufacturers, they are asked by
> operators. They will not disappear because a few folks don't want to hear
> about them.
> 
> We are speaking about "we would like to have a screwdriver in the toolbox",
> the guys that only use hammers say "we don't want to see screwdrivers in the
> toolbox" we just use nails. Let's be open and fair and let's the guys that
> like screws the right to use them (that's called democracy).
> 
> Why are some people so afraid by having signaling features that they don't
> have to support. Why would you like to prevent others to do what they want
> and need if it does not impact you.
> 
> We are not trying to find the minimum set of features that everybody agreed
> on, we don't want neither to incorporate everything. We want to have a
> sufficiently large set of features that can allow to implement a powerful
> new kind of behavior for SDH/SONET.
> 
> GMPLS supports your "public/private optical NNI", and *in addition* what you
> call a proprietary NNI. Why are you so disturbed by the fact that it does
> more than *you* need ?
> 
> As you said "purpose of GMPLS is to define an open protocol platform", what
> is your definition of "open" in that context ?
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Guo-Qiang Wang [mailto:[email-masked]]
> Sent: Wednesday, May 23, 2001 4:31 PM
> To: 'Maarten Vissers'; Dimitri Papadimitriou
> Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
> Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
> 
> Maarten,
>   I agree with your opinion not putting proprietary stuff into GMPLS. The
> purpose
> of GMPLS is to define an open protocol platform to support public/private
> optical NNI
> signaling, NOT proprietary NNI. From interworking perspective, the openness
> of
> signaling interface has to be consistent with transport interface.
>   It does not exclude that someone wants piggyback the proprietary over
> GMPLS.
> It is O.K as long as they keep this in their cloud and nobody really care
> what
> they have inside. But it is not a GMPLS, whatever you call it.
>   There is no need to introduce proprietary into GMPLS.
>   Regards,
> G.Q Wang
> Emerging Network Technology
> Nortel Networks
> Tel: (613)765-4195 (ESN 395-4195)
> Fax: (613)768-1140
> [email-masked]
> -----Original Message-----
> From:   Maarten Vissers [SMTP:[email-masked]]
> Sent:   Tuesday, May 22, 2001 6:34 AM
> To:     Dimitri Papadimitriou
> Cc:     [email-masked]; [email-masked]; q11/15; t1x1.5
> Subject:        [IP-Optical] Re: Proposed text for the concatenation
> Dimitri, Eric,
> When one or two vendors or one or two operators would like to support a
> particular feature in their equipment/network, it doesn't imply that
> there is general agreement to add such feature in to the standard. Only
> those features for which interworking is agreed end up in the standard.
> Some of the others may find its way into an informative annex/appendix
> in the standard, clearly marked as such to stress that you can not
> expect network support for this feature, nor interworking. Many other
> features do not make it at all into the standard in the absence of
> sufficient support; those are completely rejected.
> This process is present in any standards body as far as I can see,
> including the IETF. Many proposals in IETF are rejected, like in other
> standards bodies.
> At this moment we argue about features to be supported by the control
> plane for the automatic switched optical network (consisting of
> SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the
> ITU-T and T1X1.5 are responsible. Any issues are to be addressed by
> these standards bodies.
> Those organisations not being a member of ITU-T can address their issue
> in T1X1.5, and if support is obtained members of T1X1.5 being also a
> member of ITU-T can/will then forward this issue to ITU-T for world wide
> consideration.
> For the case a new feature (idea) is developed for the transport plane,
> any organisation (vendor, operator) can contribute this to ITU-T and/or
> T1X1.5 to seek support, and to make it part of the standard. If this
> isn't done, the feature seems to be unimportant for standardisation (and
> thus interworking). For this case, there is no rationale to add control
> plane functionality for this feature to the transport plane's control
> plane specification; standard transport plane UNIs and NNIs are not
> supporting this feature, so why would the associated standard control
> plane UNI/NNI support it.
> This doesn't imply that the feature is not developed; the feature is
> developed as a proprietary extension of the transport plane, control
> plane and management plane standards. Many vendors and operators offer,
> require and operate proprietary features today, and (most likely) will
> continue to do so in the future.
> 
> The IETF is extending the control plane definitions of MPLS with optical
> network specific constructs to be able to use this extended control
> plane specification as part of the automatic swithced optical network.
> As part of this work, vendors have requested control plane extensions to
> support their proprietary transport plane features. In order to do so,
> these proprietary transport plane features had to be defined to some
> level of detail in the control plane specification... otherwise nobody
> understood what was controlled. And what a marvelous interactions we
> have seen in the last few weeks on these transport plane specifications
> of concatenation, transparency and adaptive pointer processing modes
> (AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are
> all but control plane issues; these are transport plane issues and are
> outside the charter of GMPLS (and IETF).
> As all standards bodies progress their work by means of received
> contributions, it is peculiar to read in messages from people active
> within the IP standard body (i.e. IETF) that the transport plane
> standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to
> the needs of the transport plane. Where were their contributions to the
> transport plane standards bodies ...?
> And the following message from IETF to ITU-T will no doubt be received
> with open arms :-( : "i propose here to postpone the edition of this
> G.783 document in order to include the needed changes in order to
> synchronize the ITU-T specification with the last GMPLS SDH/Sonet
> document version (Ed. Eric Mannie) which has demonstrated that current
> ITU-T standards clearly don't cover some specific functions like
> flexible ACC". WOW... can we ever be more respectful and friendly...?
> 
> Regards,
> Maarten << File: Card for Maarten Vissers >>

Delivery-date: Wed, 23 May 2001 16:58:09 -0700
From: John Drake <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Heiles Juergen' <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>,  'Bala Rajagopalan' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
Date: Wed, 23 May 2001 16:51:55 -0700

Monica,

When you say standards compliant, which standards bodies are you
considering?  I.e., from one of Eric's
notes I got the impression that there were actually multiple bodies that had
defined SONET/SDH features.
Further, we could indicate that implementations of GMPLS signalling are are
GMPLS compliant - see 'self
defining term' in the index of Knuth vol 1.

Thanks,

John

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 1:42 PM
To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

Delivery-date: Wed, 23 May 2001 16:54:50 -0700
From: John Drake <[email-masked]>
To: 'Harry Mantakos' <[email-masked]>, John Drake <[email-masked]>
Cc: 'Adam Shepherd' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Timing of the upstream data path establishment 
Date: Wed, 23 May 2001 16:48:31 -0700

Harry,

I'm sorry, but I didn't realize that the admonition about not forwarding the
Path before the reverse
path had been configured had been added to the draft.  I think it's a
mistake and should be removed.

As Adrian points out, we discussed the issue many times and decided that it
wasn't worth worrying
about, since the devices we're talking about had a configuration latency
comparable to per hop
message processing latency;  i.e., O(msecs).  Moreover, as Adrian further
points out, many people that
are aware of the admonition ignore it.

If the egress device is really worried about when it can start transmitting,
it can always request
a Resv Confirm.

Thanks,

John

-----Original Message-----
From: Harry Mantakos [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 12:12 PM
To: John Drake
Cc: 'Adam Shepherd'; [email-masked]; [email-masked]
Subject: Re: Timing of the upstream data path establishment 

>I don't think that this is an issue.  Suggested label allows a node to
begin
>to establish the forward direction as it progresses the Path message.
Since
>it controls the labels in the reverse direction, it can also begin to
>establish the reverse direction concurrently.

As I understand it, suggested label allows a single node to do
whatever hardware preparation is required for the upstream and
downstream data flows in parallel, but this preparation is
still necessarily done at each node in the path sequentially.
If it takes 'T' time to prep hardware for a single direction at a
single node, and there are 'N' nodes, you're looking at something
on the order of TN to establish the LSP. In the absence of suggested
label, you'd be looking at something like 2TN.

The suggested "3-way handshake" allows "preparation" to be done
at all nodes in the path in parallel. The circuit establishment
time can be reduced to something on the order of T (assuming suggested
label was chosen).
-harry

Delivery-date: Wed, 23 May 2001 16:33:19 -0700
From: John Drake <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, 'Guo-Qiang Wang' <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 23 May 2001 16:27:46 -0700

Eric,

A very nice note.

Thanks,

John

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 11:17 AM
To: 'Guo-Qiang Wang'
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Hello Guo-Qiang,

I would like again to clarify a few important points:

- we are doing signaling and not an implementation profile, not a data plane
specification.
- ****almost all the features are optional****.
- put the field to zero to say: "no way, I don't want to hear about that".
- the fact that a feature is in the signaling does not mean that it must be
implemented.
- you can claim to be compliant with the draft without implementing some
features.
- a basic signaling implementation that allows *only* to open a VC-4 circuit
is compliant.
- you can ignore what you don't want to implement or just pick up what you
want.
- GMPLS is a toolbox, we don't say which tools to use, it is up to you to
decide.

We don't try to restrict the draft to only the features that are implemented
or implementable by *all* the manufacturers because this is an endless
discussion and that's exactly what is happening now. 

Some features that we want to control are not standardized by the ITU-T, but
they exist, they are implemented by manufacturers, they are asked by
operators. They will not disappear because a few folks don't want to hear
about them.

We are speaking about "we would like to have a screwdriver in the toolbox",
the guys that only use hammers say "we don't want to see screwdrivers in the
toolbox" we just use nails. Let's be open and fair and let's the guys that
like screws the right to use them (that's called democracy).

Why are some people so afraid by having signaling features that they don't
have to support. Why would you like to prevent others to do what they want
and need if it does not impact you.

We are not trying to find the minimum set of features that everybody agreed
on, we don't want neither to incorporate everything. We want to have a
sufficiently large set of features that can allow to implement a powerful
new kind of behavior for SDH/SONET.

GMPLS supports your "public/private optical NNI", and *in addition* what you
call a proprietary NNI. Why are you so disturbed by the fact that it does
more than *you* need ?

As you said "purpose of GMPLS is to define an open protocol platform", what
is your definition of "open" in that context ?

Kind regards,

Eric

-----Original Message-----
From: Guo-Qiang Wang [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 4:31 PM
To: 'Maarten Vissers'; Dimitri Papadimitriou
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Maarten, 
  I agree with your opinion not putting proprietary stuff into GMPLS. The
purpose 
of GMPLS is to define an open protocol platform to support public/private
optical NNI 
signaling, NOT proprietary NNI. From interworking perspective, the openness
of 
signaling interface has to be consistent with transport interface. 
  It does not exclude that someone wants piggyback the proprietary over
GMPLS. 
It is O.K as long as they keep this in their cloud and nobody really care
what 
they have inside. But it is not a GMPLS, whatever you call it. 
  There is no need to introduce proprietary into GMPLS. 
  Regards,    
G.Q Wang 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 
-----Original Message----- 
From:   Maarten Vissers [SMTP:[email-masked]] 
Sent:   Tuesday, May 22, 2001 6:34 AM 
To:     Dimitri Papadimitriou 
Cc:     [email-masked]; [email-masked]; q11/15; t1x1.5 
Subject:        [IP-Optical] Re: Proposed text for the concatenation 
Dimitri, Eric, 
When one or two vendors or one or two operators would like to support a 
particular feature in their equipment/network, it doesn't imply that 
there is general agreement to add such feature in to the standard. Only 
those features for which interworking is agreed end up in the standard. 
Some of the others may find its way into an informative annex/appendix 
in the standard, clearly marked as such to stress that you can not 
expect network support for this feature, nor interworking. Many other 
features do not make it at all into the standard in the absence of 
sufficient support; those are completely rejected. 
This process is present in any standards body as far as I can see, 
including the IETF. Many proposals in IETF are rejected, like in other 
standards bodies. 
At this moment we argue about features to be supported by the control 
plane for the automatic switched optical network (consisting of 
SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the 
ITU-T and T1X1.5 are responsible. Any issues are to be addressed by 
these standards bodies. 
Those organisations not being a member of ITU-T can address their issue 
in T1X1.5, and if support is obtained members of T1X1.5 being also a 
member of ITU-T can/will then forward this issue to ITU-T for world wide 
consideration. 
For the case a new feature (idea) is developed for the transport plane, 
any organisation (vendor, operator) can contribute this to ITU-T and/or 
T1X1.5 to seek support, and to make it part of the standard. If this 
isn't done, the feature seems to be unimportant for standardisation (and 
thus interworking). For this case, there is no rationale to add control 
plane functionality for this feature to the transport plane's control 
plane specification; standard transport plane UNIs and NNIs are not 
supporting this feature, so why would the associated standard control 
plane UNI/NNI support it. 
This doesn't imply that the feature is not developed; the feature is 
developed as a proprietary extension of the transport plane, control 
plane and management plane standards. Many vendors and operators offer, 
require and operate proprietary features today, and (most likely) will 
continue to do so in the future. 

The IETF is extending the control plane definitions of MPLS with optical 
network specific constructs to be able to use this extended control 
plane specification as part of the automatic swithced optical network. 
As part of this work, vendors have requested control plane extensions to 
support their proprietary transport plane features. In order to do so, 
these proprietary transport plane features had to be defined to some 
level of detail in the control plane specification... otherwise nobody 
understood what was controlled. And what a marvelous interactions we 
have seen in the last few weeks on these transport plane specifications 
of concatenation, transparency and adaptive pointer processing modes 
(AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are 
all but control plane issues; these are transport plane issues and are 
outside the charter of GMPLS (and IETF). 
As all standards bodies progress their work by means of received 
contributions, it is peculiar to read in messages from people active 
within the IP standard body (i.e. IETF) that the transport plane 
standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to 
the needs of the transport plane. Where were their contributions to the 
transport plane standards bodies ...? 
And the following message from IETF to ITU-T will no doubt be received 
with open arms :-( : "i propose here to postpone the edition of this 
G.783 document in order to include the needed changes in order to 
synchronize the ITU-T specification with the last GMPLS SDH/Sonet 
document version (Ed. Eric Mannie) which has demonstrated that current 
ITU-T standards clearly don't cover some specific functions like 
flexible ACC". WOW... can we ever be more respectful and friendly...? 

Regards, 
Maarten << File: Card for Maarten Vissers >> 

Delivery-date: Wed, 23 May 2001 14:03:00 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Heiles Juergen' <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>,  'Bala Rajagopalan' <[email-masked]>, 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
Date: Wed, 23 May 2001 23:01:14 +0200

Hello Monica,

I fully agree with you and with the comments made by Dimitri, Lyndon and
Bala. The idea of the footnote to flag the features is a good consensus.

Is that ok for Juergen, Maarten and the others ?

Thanks,

Kind regards,

Eric

-----Original Message-----
From: Lazer, Monica A, NNAD [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 10:42 PM
To: 'Heiles Juergen'; Mannie, Eric; 'Fong, Man Wing'; 'Bernstein, Greg';
'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

Delivery-date: Wed, 23 May 2001 13:55:10 -0700
Date: Wed, 23 May 2001 22:52:28 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Eric Mannie <[email-masked]>
CC: "Ong, Lyndon" <[email-masked]>, "'Guo-Qiang Wang'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------096930B20DB2B551576094E6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric et all,

For each feature which is not defined by the ITU-T or the ANSI T1,
we could add a footnote refering to the following text: "this 
feature is not defined either in ANSI T1 or in ITU-T Standards".

In addition to the proposed proposed text (see below), we could 
add under parenthesis in which section each of these features are 
defined within the draft.

--- proposed new section:

X. Relationship with SDH and SONET standards

Some of the features described in this specification are not defined
either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and 
2000). However, these features are useful and implemented in many 
equipment's. All these features are optional but can be controlled 
using this specification.

These features are: arbitrary contiguous concatenation, flexible 
arbitrary contiguous concatenation and transparency. They have been
addressed in the relevant sections of this specification.

---

With the added text, everything gets our agreement.

Regards,
Dimitri. 

> "Ong, Lyndon" wrote:
> 
> Hi,
> 
> It cannot be "proprietary" in the sense that you still need at least 2
> sets of people to implement it,
> if only 1 person implements it that will cause it to be removed.  You
> could argue that this may lead to a
> feature that is weak and not useful because only a few implement it
> (and of course this NEVER
> happens with ITU-T specs ;o) but not that it is proprietary as in 1
> vendor only.
> 
> Marking the document to show where something is not (currently!) in
> the ITU standard seems like
> a fair solution, and we can put this discussion to bed.  If on the
> other hand there is a technical
> concern, this should be expressed.
> 
> Cheers,
> 
> Lyndon
> 
>      -----Original Message-----
>      From: Guo-Qiang Wang [mailto:[email-masked]]
>      Sent: Wednesday, May 23, 2001 7:31 AM
>      To: 'Maarten Vissers'; Dimitri Papadimitriou
>      Cc: [email-masked]; [email-masked];
>      q11/15; t1x1.5
>      Subject: RE: [IP-Optical] Re: Proposed text for the
>      concatenation
> 
>      Maarten,
>        I agree with your opinion not putting proprietary stuff
>      into GMPLS. The purpose
>      of GMPLS is to define an open protocol platform to support
>      public/private optical NNI
>      signaling, NOT proprietary NNI. From interworking
>      perspective, the openness of
>      signaling interface has to be consistent with transport
>      interface.
>        It does not exclude that someone wants piggyback the
>      proprietary over GMPLS.
>      It is O.K as long as they keep this in their cloud and
>      nobody really care what
>      they have inside. But it is not a GMPLS, whatever you call
>      it.
>        There is no need to introduce proprietary into GMPLS.
--------------096930B20DB2B551576094E6
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------096930B20DB2B551576094E6--

Delivery-date: Wed, 23 May 2001 13:47:38 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Guo-Qiang Wang' <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 23 May 2001 22:44:00 +0200

Hello again,

>  As stated in my previous e-mail, GMPLS is defined for signaling of
optical NNI. 

Not exactly, we defined it without speaking about UNI and NNI. Indeed GMPLS
is *being* defined for all kind of interfaces, UNI, public NNI, private NNI,
etc. The signaling runs between an ingress device and an egress device, or
between two endpoints.

Also the term optical is misleading. We didn't want to put optical
everywhere because GMPLS is multi-layer and multi-technology. The TDM layer
is not optical, the packet layer is not optical.

>The openness of GMPLS is that everybody has to understand what your are 
>talking about, both syntactically and semantically.

Semantically and syntactically the siganling is non ambiguous. The
particular agreement that you choose to use to implement the mechanism
described by the siganling doesn't belong to the signaling specification.
Most of GMPLS is generic, it means that you can apply it in different
contexts for different technologies. If two different standardization bodies
(but not the IETF of course) define how to implement the transparency, the
GMPLS signaling will work with both. The manufacturer will have to choose
one profile to implement and of course two different profiles could not
interoperate. The GMPLS signaling is neutral and generic with respect to the
way to implement transparency, flexible concatenation, etc.

>It is for inter-domain communication, 
>the smallest domain is NE itself. For intro-domain signaling, one can use
whatever 
>signaling protocols they choose as nobody would care of that.

GMPLS is for both. You need standards also at an intra-domain interface if
you want to buy boxes from two different manufacturers. Indeed the current
version of GMPLS is more focussing on the intra-domain interfaces than the
inter-domain interfaces.

>  If one (or two) vendor's approach is not called proprietary, then we have
to re-define 
> what the standard is. 

I don't work for a vendor :-) Who told you that some features are needed
only for one or two vendors ? How do you quantify the number of vendors that
are needed to have a standard ? We work on a consensus based and this draft
has 17 companies on it with 30 people. Usually it is much much less at the
IETF, you only have a small number of co-authors. I already gave a summary
of the process that we followed, all the meetings that we hold, all the
conference call that we hold, all the e-mails that we exchanged, etc.

You described one model in your e-mail, that's a valid model but this is not
THE (only) model. There are plenty of other models that can be fulfilled
with GMPLS.

Kind regards,

Eric

Eric, 
  As stated in my previous e-mail, GMPLS is defined for signaling of optical
NNI. 
The openness of GMPLS is that everybody has to understand what your are 
talking about, both syntactically and semantically. It is for inter-domain
communication, 
the smallest domain is NE itself. For intro-domain signaling, one can use
whatever 
signaling protocols they choose as nobody would care of that. 
  If one (or two) vendor's approach is not called proprietary, then we have
to re-define 
 what the standard is. 

G.Q Wang 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 

-----Original Message----- 
From:   Mannie, Eric [SMTP:[email-masked]] 
Sent:   Wednesday, May 23, 2001 2:17 PM 
To:     Wang, Guo-Qiang [KAN:0V10:EXCH] 
Cc:     [email-masked]; [email-masked]; q11/15; t1x1.5 
Subject:        RE: [IP-Optical] Re: Proposed text for the concatenation 
Hello Guo-Qiang, 
I would like again to clarify a few important points: 
- we are doing signaling and not an implementation profile, not a data plane

specification. 
- ****almost all the features are optional****. 
- put the field to zero to say: "no way, I don't want to hear about that". 
- the fact that a feature is in the signaling does not mean that it must be 
implemented. 
- you can claim to be compliant with the draft without implementing some 
features. 
- a basic signaling implementation that allows *only* to open a VC-4 circuit

is compliant. 
- you can ignore what you don't want to implement or just pick up what you 
want. 
- GMPLS is a toolbox, we don't say which tools to use, it is up to you to 
decide. 
We don't try to restrict the draft to only the features that are implemented

or implementable by *all* the manufacturers because this is an endless 
discussion and that's exactly what is happening now. 
Some features that we want to control are not standardized by the ITU-T, but

they exist, they are implemented by manufacturers, they are asked by 
operators. They will not disappear because a few folks don't want to hear 
about them. 
We are speaking about "we would like to have a screwdriver in the toolbox", 
the guys that only use hammers say "we don't want to see screwdrivers in the

toolbox" we just use nails. Let's be open and fair and let's the guys that 
like screws the right to use them (that's called democracy). 
Why are some people so afraid by having signaling features that they don't 
have to support. Why would you like to prevent others to do what they want 
and need if it does not impact you. 
We are not trying to find the minimum set of features that everybody agreed 
on, we don't want neither to incorporate everything. We want to have a 
sufficiently large set of features that can allow to implement a powerful 
new kind of behavior for SDH/SONET. 
GMPLS supports your "public/private optical NNI", and *in addition* what you

call a proprietary NNI. Why are you so disturbed by the fact that it does 
more than *you* need ? 
As you said "purpose of GMPLS is to define an open protocol platform", what 
is your definition of "open" in that context ? 
Kind regards, 
Eric 
-----Original Message----- 
From: Guo-Qiang Wang [mailto:[email-masked]] 
Sent: Wednesday, May 23, 2001 4:31 PM 
To: 'Maarten Vissers'; Dimitri Papadimitriou 
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5 
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation 

Maarten, 
  I agree with your opinion not putting proprietary stuff into GMPLS. The 
purpose 
of GMPLS is to define an open protocol platform to support public/private 
optical NNI 
signaling, NOT proprietary NNI. From interworking perspective, the openness 
of 
signaling interface has to be consistent with transport interface. 
  It does not exclude that someone wants piggyback the proprietary over 
GMPLS. 
It is O.K as long as they keep this in their cloud and nobody really care 
what 
they have inside. But it is not a GMPLS, whatever you call it. 
  There is no need to introduce proprietary into GMPLS. 
  Regards,    
G.Q Wang 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 
-----Original Message----- 
From:   Maarten Vissers [SMTP:[email-masked]] 
Sent:   Tuesday, May 22, 2001 6:34 AM 
To:     Dimitri Papadimitriou 
Cc:     [email-masked]; [email-masked]; q11/15; t1x1.5 
Subject:        [IP-Optical] Re: Proposed text for the concatenation 
Dimitri, Eric, 
When one or two vendors or one or two operators would like to support a 
particular feature in their equipment/network, it doesn't imply that 
there is general agreement to add such feature in to the standard. Only 
those features for which interworking is agreed end up in the standard. 
Some of the others may find its way into an informative annex/appendix 
in the standard, clearly marked as such to stress that you can not 
expect network support for this feature, nor interworking. Many other 
features do not make it at all into the standard in the absence of 
sufficient support; those are completely rejected. 
This process is present in any standards body as far as I can see, 
including the IETF. Many proposals in IETF are rejected, like in other 
standards bodies. 
At this moment we argue about features to be supported by the control 
plane for the automatic switched optical network (consisting of 
SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the 
ITU-T and T1X1.5 are responsible. Any issues are to be addressed by 
these standards bodies. 
Those organisations not being a member of ITU-T can address their issue 
in T1X1.5, and if support is obtained members of T1X1.5 being also a 
member of ITU-T can/will then forward this issue to ITU-T for world wide 
consideration. 
For the case a new feature (idea) is developed for the transport plane, 
any organisation (vendor, operator) can contribute this to ITU-T and/or 
T1X1.5 to seek support, and to make it part of the standard. If this 
isn't done, the feature seems to be unimportant for standardisation (and 
thus interworking). For this case, there is no rationale to add control 
plane functionality for this feature to the transport plane's control 
plane specification; standard transport plane UNIs and NNIs are not 
supporting this feature, so why would the associated standard control 
plane UNI/NNI support it. 
This doesn't imply that the feature is not developed; the feature is 
developed as a proprietary extension of the transport plane, control 
plane and management plane standards. Many vendors and operators offer, 
require and operate proprietary features today, and (most likely) will 
continue to do so in the future. 

The IETF is extending the control plane definitions of MPLS with optical 
network specific constructs to be able to use this extended control 
plane specification as part of the automatic swithced optical network. 
As part of this work, vendors have requested control plane extensions to 
support their proprietary transport plane features. In order to do so, 
these proprietary transport plane features had to be defined to some 
level of detail in the control plane specification... otherwise nobody 
understood what was controlled. And what a marvelous interactions we 
have seen in the last few weeks on these transport plane specifications 
of concatenation, transparency and adaptive pointer processing modes 
(AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are 
all but control plane issues; these are transport plane issues and are 
outside the charter of GMPLS (and IETF). 
As all standards bodies progress their work by means of received 
contributions, it is peculiar to read in messages from people active 
within the IP standard body (i.e. IETF) that the transport plane 
standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to 
the needs of the transport plane. Where were their contributions to the 
transport plane standards bodies ...? 
And the following message from IETF to ITU-T will no doubt be received 
with open arms :-( : "i propose here to postpone the edition of this 
G.783 document in order to include the needed changes in order to 
synchronize the ITU-T specification with the last GMPLS SDH/Sonet 
document version (Ed. Eric Mannie) which has demonstrated that current 
ITU-T standards clearly don't cover some specific functions like 
flexible ACC". WOW... can we ever be more respectful and friendly...? 

Regards, 
Maarten << File: Card for Maarten Vissers >> 

Delivery-date: Wed, 23 May 2001 13:43:59 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Heiles Juergen'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
Date: Wed, 23 May 2001 16:42:15 -0400

>From an operator's perspective, it is essential to clearly flag the features
that are standards compliant from those, which deviate from existing
standards, even when they are improvements to the standards. The reason for
this is rooted in the need to have the ability to identify all the relevant
issues when inter-working network elements from multiple vendors in the same
networks, while taking advantage of new non-standard features.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 8:57 AM
To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

        Juergen

> -----Original Message-----
> From: Mannie, Eric [SMTP:[email-masked]]
> Sent: Tuesday, May 22, 2001 9:22 PM
> To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:      RE: Proposed text for the concatenation
>
> Hello Man Wing, Bala and All,
>
> >I think Eric's proposed text gives a very good coverage on all cases
>
> Thanks :-)
>
> >and all we need is indicating which field is ... optional
>
> Indeed everything is already optional in the draft except the signal type
of
> course:
>
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
>
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
>
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
>
> The draft doesn't indicate what must be implemented of course.
>
> >and all we need is indicating which field is standard....
>
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.>
>
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
>
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
>
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
>
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
>
> ---------- End of text
>
> Agreed ? Comments ?
>
> Comments from our ITU-T folks are welcome (really :-)
>
> Kind regards,
>
> Eric
>
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
>
>
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
>
> Man Wing
>
>

Delivery-date: Wed, 23 May 2001 13:09:54 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Saha, Sayandeb'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Wed, 23 May 2001 22:07:40 +0200

Dear Sayan,

Thanks for the comments. However note that when requesting transparency for
an STS-48 signal for instance, the signal type to use is STS-48. You cant'
concatenate STS-1's since concatenation of STS-1 is not defined, but
concatenation of STS-1 SPE's is. If you ask the concatenation of 48 x STS-1
SPE's you are not speaking about the frame with its overhead, so you cannot
request transparency. So we took the decision to use well defined signal
types when requesting transparency (e.g. STS-48). And we took the convention
to indicate in NCC the number of SPE's in that signal that must be
concatenated. It took us some time to find a way to code each possible
signal in a non ambiguous way. So I the original examples are correct.

Kind regards,

Eric

-----Original Message-----
From: Saha, Sayandeb [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 9:10 PM
To: Mannie, Eric
Cc: [email-masked]'; [email-masked]'
Subject: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt 

Hi ALL,
I noticed the following in section 4 of
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt .

 The example number 16 is ...

16. An STS-48c signal with LOH DCC and E2 transparency is formed
   by the application of CCT with Type 1, NCC with value 48, NVC with
   value 0, MT with value 1 and T with flag 5 and 10 to an STS-48
   Elementary Signal.

It should be 

   An STS-48c signal with LOH DCC and E2 transparency is formed
   by the application of CCT with Type 1, NCC with value 48, NVC with
   value 0, MT with value 1 and T with flag 5 and 10 to an STS-1 SPE
   Elementary Signal.

The example number 17 is ...

17. An STS-768c signal with K1/K2 and LOH DCC transparency is
   formed by the application of CCT with Type 1, NCC with value 768,
   NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
   STS-768 Elementary Signal.

It should be 

   An STS-768c signal with K1/K2 and LOH DCC transparency is
   formed by the application of CCT with Type 1, NCC with value 768,
   NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
   STS-1 SPE Elementary Signal.

Regards
-Sayan

Delivery-date: Wed, 23 May 2001 12:13:29 -0700
To: John Drake <[email-masked]>
cc: "'Adam Shepherd'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Timing of the upstream data path establishment 
Date: Wed, 23 May 2001 15:12:02 -0400
From: Harry Mantakos <[email-masked]>

>I don't think that this is an issue.  Suggested label allows a node to begin
>to establish the forward direction as it progresses the Path message.  Since
>it controls the labels in the reverse direction, it can also begin to
>establish the reverse direction concurrently.

As I understand it, suggested label allows a single node to do
whatever hardware preparation is required for the upstream and
downstream data flows in parallel, but this preparation is
still necessarily done at each node in the path sequentially.
If it takes 'T' time to prep hardware for a single direction at a
single node, and there are 'N' nodes, you're looking at something
on the order of TN to establish the LSP. In the absence of suggested
label, you'd be looking at something like 2TN.

The suggested "3-way handshake" allows "preparation" to be done
at all nodes in the path in parallel. The circuit establishment
time can be reduced to something on the order of T (assuming suggested
label was chosen).
-harry

Delivery-date: Wed, 23 May 2001 12:11:19 -0700
From: "Saha, Sayandeb" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Editorial comments on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt 
Date: Wed, 23 May 2001 15:09:50 -0400

Hi ALL,
I noticed the following in section 4 of
draft-ietf-ccamp-gmpls-sonet-sdh-00.txt .

 The example number 16 is ...

16. An STS-48c signal with LOH DCC and E2 transparency is formed
   by the application of CCT with Type 1, NCC with value 48, NVC with
   value 0, MT with value 1 and T with flag 5 and 10 to an STS-48
   Elementary Signal.

It should be 

   An STS-48c signal with LOH DCC and E2 transparency is formed
   by the application of CCT with Type 1, NCC with value 48, NVC with
   value 0, MT with value 1 and T with flag 5 and 10 to an STS-1 SPE
   Elementary Signal.

The example number 17 is ...

17. An STS-768c signal with K1/K2 and LOH DCC transparency is
   formed by the application of CCT with Type 1, NCC with value 768,
   NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
   STS-768 Elementary Signal.

It should be 

   An STS-768c signal with K1/K2 and LOH DCC transparency is
   formed by the application of CCT with Type 1, NCC with value 768,
   NVC with value 0, MT with value 1 and T with flag 5 and 7 to an
   STS-1 SPE Elementary Signal.

Regards
-Sayan

Delivery-date: Wed, 23 May 2001 11:20:54 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Guo-Qiang Wang' <[email-masked]>
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Wed, 23 May 2001 20:17:12 +0200

Hello Guo-Qiang,

I would like again to clarify a few important points:

- we are doing signaling and not an implementation profile, not a data plane
specification.
- ****almost all the features are optional****.
- put the field to zero to say: "no way, I don't want to hear about that".
- the fact that a feature is in the signaling does not mean that it must be
implemented.
- you can claim to be compliant with the draft without implementing some
features.
- a basic signaling implementation that allows *only* to open a VC-4 circuit
is compliant.
- you can ignore what you don't want to implement or just pick up what you
want.
- GMPLS is a toolbox, we don't say which tools to use, it is up to you to
decide.

We don't try to restrict the draft to only the features that are implemented
or implementable by *all* the manufacturers because this is an endless
discussion and that's exactly what is happening now. 

Some features that we want to control are not standardized by the ITU-T, but
they exist, they are implemented by manufacturers, they are asked by
operators. They will not disappear because a few folks don't want to hear
about them.

We are speaking about "we would like to have a screwdriver in the toolbox",
the guys that only use hammers say "we don't want to see screwdrivers in the
toolbox" we just use nails. Let's be open and fair and let's the guys that
like screws the right to use them (that's called democracy).

Why are some people so afraid by having signaling features that they don't
have to support. Why would you like to prevent others to do what they want
and need if it does not impact you.

We are not trying to find the minimum set of features that everybody agreed
on, we don't want neither to incorporate everything. We want to have a
sufficiently large set of features that can allow to implement a powerful
new kind of behavior for SDH/SONET.

GMPLS supports your "public/private optical NNI", and *in addition* what you
call a proprietary NNI. Why are you so disturbed by the fact that it does
more than *you* need ?

As you said "purpose of GMPLS is to define an open protocol platform", what
is your definition of "open" in that context ?

Kind regards,

Eric

-----Original Message-----
From: Guo-Qiang Wang [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 4:31 PM
To: 'Maarten Vissers'; Dimitri Papadimitriou
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Maarten, 
  I agree with your opinion not putting proprietary stuff into GMPLS. The
purpose 
of GMPLS is to define an open protocol platform to support public/private
optical NNI 
signaling, NOT proprietary NNI. From interworking perspective, the openness
of 
signaling interface has to be consistent with transport interface. 
  It does not exclude that someone wants piggyback the proprietary over
GMPLS. 
It is O.K as long as they keep this in their cloud and nobody really care
what 
they have inside. But it is not a GMPLS, whatever you call it. 
  There is no need to introduce proprietary into GMPLS. 
  Regards,    
G.Q Wang 
Emerging Network Technology 
Nortel Networks 
Tel: (613)765-4195 (ESN 395-4195) 
Fax: (613)768-1140 
[email-masked] 
-----Original Message----- 
From:   Maarten Vissers [SMTP:[email-masked]] 
Sent:   Tuesday, May 22, 2001 6:34 AM 
To:     Dimitri Papadimitriou 
Cc:     [email-masked]; [email-masked]; q11/15; t1x1.5 
Subject:        [IP-Optical] Re: Proposed text for the concatenation 
Dimitri, Eric, 
When one or two vendors or one or two operators would like to support a 
particular feature in their equipment/network, it doesn't imply that 
there is general agreement to add such feature in to the standard. Only 
those features for which interworking is agreed end up in the standard. 
Some of the others may find its way into an informative annex/appendix 
in the standard, clearly marked as such to stress that you can not 
expect network support for this feature, nor interworking. Many other 
features do not make it at all into the standard in the absence of 
sufficient support; those are completely rejected. 
This process is present in any standards body as far as I can see, 
including the IETF. Many proposals in IETF are rejected, like in other 
standards bodies. 
At this moment we argue about features to be supported by the control 
plane for the automatic switched optical network (consisting of 
SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the 
ITU-T and T1X1.5 are responsible. Any issues are to be addressed by 
these standards bodies. 
Those organisations not being a member of ITU-T can address their issue 
in T1X1.5, and if support is obtained members of T1X1.5 being also a 
member of ITU-T can/will then forward this issue to ITU-T for world wide 
consideration. 
For the case a new feature (idea) is developed for the transport plane, 
any organisation (vendor, operator) can contribute this to ITU-T and/or 
T1X1.5 to seek support, and to make it part of the standard. If this 
isn't done, the feature seems to be unimportant for standardisation (and 
thus interworking). For this case, there is no rationale to add control 
plane functionality for this feature to the transport plane's control 
plane specification; standard transport plane UNIs and NNIs are not 
supporting this feature, so why would the associated standard control 
plane UNI/NNI support it. 
This doesn't imply that the feature is not developed; the feature is 
developed as a proprietary extension of the transport plane, control 
plane and management plane standards. Many vendors and operators offer, 
require and operate proprietary features today, and (most likely) will 
continue to do so in the future. 

The IETF is extending the control plane definitions of MPLS with optical 
network specific constructs to be able to use this extended control 
plane specification as part of the automatic swithced optical network. 
As part of this work, vendors have requested control plane extensions to 
support their proprietary transport plane features. In order to do so, 
these proprietary transport plane features had to be defined to some 
level of detail in the control plane specification... otherwise nobody 
understood what was controlled. And what a marvelous interactions we 
have seen in the last few weeks on these transport plane specifications 
of concatenation, transparency and adaptive pointer processing modes 
(AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are 
all but control plane issues; these are transport plane issues and are 
outside the charter of GMPLS (and IETF). 
As all standards bodies progress their work by means of received 
contributions, it is peculiar to read in messages from people active 
within the IP standard body (i.e. IETF) that the transport plane 
standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to 
the needs of the transport plane. Where were their contributions to the 
transport plane standards bodies ...? 
And the following message from IETF to ITU-T will no doubt be received 
with open arms :-( : "i propose here to postpone the edition of this 
G.783 document in order to include the needed changes in order to 
synchronize the ITU-T specification with the last GMPLS SDH/Sonet 
document version (Ed. Eric Mannie) which has demonstrated that current 
ITU-T standards clearly don't cover some specific functions like 
flexible ACC". WOW... can we ever be more respectful and friendly...? 

Regards, 
Maarten << File: Card for Maarten Vissers >> 

Delivery-date: Wed, 23 May 2001 11:08:50 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Heiles Juergen' <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>,  'Bala Rajagopalan' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Wed, 23 May 2001 20:06:33 +0200

Hello Juergen,

A few brief comments (at least I tried):

- We are not trying to find the minimum set of features that everybody
agreed on, we don't want neither to incorporate everything. We want to have
a reasonable set of features that matches the new SDH/SONET behaviors being
implemented in the new generation of equipment's.

- We are not designing the control plane to control only SDH/SONET as
defined by ITU-T and T1X1. We provide more control features than needed for
standardized SDH/SONET. It has no impact on those that want to use and
control strictly the standardized SDH/SONET.

- Some features don't need additional ITU-T or T1X1 standards, e.g.
transparency at the NNI. We already explained various scenarios where there
is no issue.

- We want to give the right to users and manufacturers to have their own
implementation agreements. If they don't want to be 100% compliant with the
ITU-T or T1X1 standard it is their right.

- About AUG/STS groups there is absolutely nothing new needed in SDH/SONET
to use it. That belongs to the new behaviors that we are defining. The GMPLS
behaviors are not defined in G.783. G.783 is a functional description, we
take a lot of freedom with it since we want to use signaling and routing
protocols.

What text do you propose for the draft ?

Is the following revised text acceptable:

--- proposed new section:

X. Relationship with SDH and SONET standards

Some of the features described in this specification are not defined neither
in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
these features are useful and implemented in many equipment's. All these
features are optional but can be controlled using this specification.

These features are: arbitrary contiguous concatenation, flexible arbitrary
contiguous concatenation and transparency. They have been addressed in the
relevant sections of this specification.

---------- End of text

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 2:57 PM
To: Mannie, Eric; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala
Rajagopalan'
Cc: [email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: Proposed text for the concatenation

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the
proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document
for any proprietary solution, where will we stop (I want B3 transparency and
I over connection setup for containers (without POH)? Do we really want to
define the signaling support for single, two, three vendor solutions. I
would leave this to the vendors. They implemented a proprietary transport
plane solution so they can also define their proprietary control plane
solution. If we have a broader interest in the feature we should look at the
application and consider if it should be standardized both for the transport
plane and the control plane.
- Remember that we define the control in order to support the transport
plane and not vice versa. A stand alone transport plane makes sense (and has
been in use for years), a stand alone control plane doesn't. Interworking at
the control plane doesn't help much if the transport plane doesn't
interwork. So it should be a common standardization activity both in the
control and in the transport plane.
- If we define something proprietary we need information about the feature,
we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what
implications they have on the transport plane, they might exclude each
other. That can happen as we focus only on the control plane and don't care
about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot
kill a good solution that fits network needs by blocking it from a standard.
If someone builds it and shows its advantages operators will start to ask
for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard
feature and this is a proprietary feature. Don't start to explain how we can
come form a proprietary  feature to interworking or a standard. And don't
start to explain how the feature could be implemented. It will bring you
into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail,
but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of
individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the
layers and can screw up your whole management. In addition it is not real
transparency what is needed, it is functional transparency. For example for
B2. Or for the DCC bytes you might allow byte slips. But what implications
has this on the DCN? It is easy to define a feature for the control plane
and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in
dropping the already included B2 transparency. Because it is not a straight
forward solution? Requires some awkward processing? And some people don't
understand how it works? That might be also true for other features
(flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in
your mind. I think about a completely different approach. We both don't know
it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another
proprietary feature. The AUG/STS group signal type provides some
transparency concerning the underlying VC-3/4/4-Xc structure. However as
pointer processing for the individual VCs is still required in case of
multiplexing the network elements have to detect the VC-N structure by
themselves using the pointer information (valid pointer, concatenation
indication). But this doesn't work with flexible arbitrary contiguous
concatenation, at least with the solution I have in mind. Additional
information on the VCs that belong together is needed in-band (SOH?) if
automatic detection should be supported. If it is not supported it cannot be
part of a AUG/STS group signal type while all other types of concatenation
can be. If it is supported you might not need a label set. A label for the
first time slot is enough. The network element detects which other belong to
the group. So from the currently available informatio!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual
concatenation can be used with any contiguous concatenation. Although with
flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed
section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
It should be noted that AUG/TUG are not and were never intended to be
networking entities. They were introduced as internal signal structures in
order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying
VC-N structure. IF you multiplex the signal you still have to do pointer
processing for the individual VCs. As a AUG/STS group or TUG has no overhead
of its own, any supervision has to be performed on the individual VCs. So
what will it buy us ?(ok, ok better not to ask the question, some one
supports it and has its good reasons to do so as it is the case for any of
the above features)

Regards

	Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Tuesday, May 22, 2001 9:22 PM
> To:	'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:	[email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:	RE: Proposed text for the concatenation
> 
> Hello Man Wing, Bala and All,
> 
> >I think Eric's proposed text gives a very good coverage on all cases
> 
> Thanks :-)
> 
> >and all we need is indicating which field is ... optional
> 
> Indeed everything is already optional in the draft except the signal type
of
> course:
> 
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
> 
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
> 
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
> 
> The draft doesn't indicate what must be implemented of course.
> 
> >and all we need is indicating which field is standard....
> 
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal
types
> have an equivalent definition in the standards.
> 
> --- proposed new section:
> 
> X. Relationship with SDH and SONET standards
> 
> Some of the features described in this specification are not defined
neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).
However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.> 
> 
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in
the
> relevant sections of this specification.
> 
> Arbitrary contiguous concatenation does not need any additional standard
to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
> 
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
> 
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again
this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at
all
> about this paragraph, ideas are welcome, please help !
> 
> ---------- End of text
> 
> Agreed ? Comments ?
> 
> Comments from our ITU-T folks are welcome (really :-)
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
> 
> 
> Very good point, Greg. If I remember correctly, the initial email
initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line
is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just
a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and
all
> we need is indicating which field is non-standard and optional.
> 
> Man Wing
> 
>  

Delivery-date: Wed, 23 May 2001 09:42:59 -0700
To: [email-masked]
Date: Wed, 23 May 2001 09:41:37 -0700
From: "Lyndon Ong" <[email-masked]>
Reply-To: [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Organization: QUALCOMM Eudora Web-Mail  (http://www.eudoramail.com:80) 
Content-Length: 1716

Hi,
 
It cannot be "proprietary" in the sense that you still need at least 2 sets
of people to implement it,
if only 1 person implements it that will cause it to be removed.  You could
argue that this may lead to a
feature that is weak and not useful because only a few implement it (and of
course this NEVER 
happens with ITU-T specs ;o) but not that it is proprietary as in 1 vendor
only.
 
Marking the document to show where something is not (currently!) in the ITU
standard seems like
a fair solution, and we can put this discussion to bed.  If on the other
hand there is a technical 
concern, this should be expressed.
 
Cheers,
 
Lyndon

-----Original Message-----
From: Guo-Qiang Wang [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 7:31 AM
To: 'Maarten Vissers'; Dimitri Papadimitriou
Cc: [email-masked]; [email-masked]; q11/15; t1x1.5
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation

Maarten, 
  I agree with your opinion not putting proprietary stuff into GMPLS. The
purpose 
of GMPLS is to define an open protocol platform to support public/private
optical NNI 
signaling, NOT proprietary NNI. From interworking perspective, the openness
of 
signaling interface has to be consistent with transport interface. 
  It does not exclude that someone wants piggyback the proprietary over
GMPLS. 
It is O.K as long as they keep this in their cloud and nobody really care
what 
they have inside. But it is not a GMPLS, whatever you call it. 
  There is no need to introduce proprietary into GMPLS. 

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Delivery-date: Wed, 23 May 2001 08:55:49 -0700
From: John Drake <[email-masked]>
To: 'Adam Shepherd' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Timing of the upstream data path establishment
Date: Wed, 23 May 2001 08:50:33 -0700

Adam,

I don't think that this is an issue.  Suggested label allows a node to begin
to establish the forward direction as it progresses the Path message.  Since
it controls the labels in the reverse direction, it can also begin to
establish the reverse direction concurrently.

Thanks,

John
-----Original Message-----
From: Adam Shepherd [mailto:[email-masked]]
Sent: Wednesday, May 23, 2001 7:06 AM
To: [email-masked]; [email-masked]
Subject: Timing of the upstream data path establishment

Hi all

We have been considering some issues regarding the timing of the
establishment of the reverse direction data path for bidirectional LSPs in
RSVP GMPLS.  We would be interested in input from the mailing list on
whether these problems are significant, and if so, whether there is a strong
enough case for modifying the drafts at this stage.

The key factor is whether bidirectional LSP establishment is a 2-way
handshake (Path, Resv), as currently, or a 3-way one (Path, Resv and
mandatory ResvConf).  We believe that the 3-way handshake, as used in the
OIF OUNI, potentially offers significant reductions in latency of
establishing bidirectional LSPs for LSRs where hardware programming is slow.
The motivation here is the same as for Suggested Label (described in
draft-ietf-mpls-generalized-signaling section 3.4).

2-way handshake
---------------

With 2-way handshaking, the egress LSR can send reverse direction data as
soon as it receives the Path (as in GMPLS
draft-ietf-mpls-generalized-rsvp-te, section 3.1, paragraph 4).  Transit
LSRs must program the reverse direction data path before forwarding the Path
across the network or there is a risk that reverse direction data will be
lost.  ResvConf is optional, and if sent it does not affect the timing of
the setup of the data path.

The benefits of this are as follows.

*	If the significant factor in latency is message propagation, then
the latency for establishment of the reverse direction data path is one
third as long as 3-way handshaking (the time taken for the Path message to
cross the network, rather than Path, Resv, ResvConf).  Arguably, reverse
direction latency is less important than downstream - the initiating LSR is
the one that triggered the LSP establishment, so is more likely to have the
immediate requirement to send data.

*	Less signaling traffic and less processing required.  However
ResvConf processing is probably not a very large proportion of overall load.

3-way handshake
---------------

In this approach, ResvConf becomes mandatory for bidirectional LSPs, and the
egress LSR cannot send reverse direction data until it has received this
message (those familiar with the OIF OUNI will note this matches
oif2000-125.4 Section 12.4.8, figure 12.1).  Transit LSRs may forward the
Path message before completing reverse direction data path programming.

The advantage of 3-way handshaking is as follows.  If hardware programming
is the significant factor in latency, then latency is significantly reduced
as we can parallelize hardware programming at each LSR.  Each LSR can start
programming on receipt of the Path message (based on the Upstream Label and
Suggested Label), but forward the message immediately.  The total latency is
dominated by the maximum of each LSR's programming latency, rather than the
sum.

Dynamic selection
-----------------

As a third option, we propose a possible solution to support either 2-way or
3-way handshaking in RSVP GMPLS, at the choice of the LSRs involved.  By
default, 2-way handshaking is used.  However, any LSR can delay programming,
in which case, the egress LSR must be informed that a 3-way handshake is
required.  The requirement for 3-way handshaking must be indicated in the
Path message, and we propose using a RESV_CONFIRM object on the Path message
to do so.

In more detail, this works as follows.

*	Any ingress or transit LSR MAY elect to enable 3-way handshaking and
forward the Path message before completing programming of the reverse
direction data path.  Typically it would do so because hardware programming
is slow.  If it elects to do so, it MUST add a RESV_CONFIRM object to the
Path message.

*	A transit LSR receiving a Path message with a RESV_CONFIRM object
SHOULD forward the Path message before completing programming of the reverse
direction data path.  However it MAY choose not to do so.

*	An egress LSR receiving a Path message with a RESV_CONFIRM object
SHOULD include its own RESV_CONFIRM object in the Resv and it SHOULD NOT
start to send reverse direction data until it receives the ResvConf message.
(If it does send sooner, then data may be lost).

*	Each LSR MUST complete programming of both directions before
forwarding the Resv message.

Moving Forward
--------------

We would be interested to get feedback from readers of this list on which
option is preferred.  If it is felt that dynamic selection is best, then is
the solution we have proposed suitable?

Regards,
Adam

Adam Shepherd
Network Convergence Group
Data Connection Ltd
-------------------

Tel: +44 (0) 20 8366 1177                Fax: +44 (0) 20 8363 1468
Email: [email-masked]  Web: http://www.dataconnection.com

Envelope-to: [email-masked]
Delivery-date: Wed, 23 May 2001 08:49:51 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Adam Shepherd" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Timing of the upstream data path establishment
Date: Wed, 23 May 2001 11:44:15 -0400

Adam,
I should refer you to the archive on this point which has been discussed before.

The drafts state that the reverse direction (tail to head) reservation and
programming must be completed before the Path/Label Request can be forwarded,
but this, I believe, ignored by many people.

The bottom line was that it is solely an issue for the tail end (aka egress) to
decide when to start sending data.  There are many approaches that it can take
to determine this and, as you point out, requesting ResvConf is a good one.
Another is to 'know' that the network has behaved as specified in the draft
(either by increasing the latency or by having speedy hardware).

A further choice is for the tail end to wait a period of time before sending
data.  If all nodes in the network come from the same supplier, they will take
roughly the same time to program so once the tail end is programmed, all the
others should be ready.

The tail could even wait until it sees light on the forward path before turning
on the reverse path.

Your third option (add RESV_CONFIRM to Path if you believe your node's hardware
programming may be too slow) is an interesting flag that might interest SPs when
they're buying equipment. "Look," it says, "this hardware takes a long time to
program, and everyone else needs to adapt to it."

Finally, perhaps you could suggest how this would be applied to CR-LDP.

Have fun,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]
----- Original Message -----
From: "Adam Shepherd" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 23, 2001 10:05 AM
Subject: Timing of the upstream data path establishment

> Hi all
>
> We have been considering some issues regarding the timing of the
> establishment of the reverse direction data path for bidirectional LSPs in
> RSVP GMPLS.  We would be interested in input from the mailing list on
> whether these problems are significant, and if so, whether there is a strong
> enough case for modifying the drafts at this stage.
>
> The key factor is whether bidirectional LSP establishment is a 2-way
> handshake (Path, Resv), as currently, or a 3-way one (Path, Resv and
> mandatory ResvConf).  We believe that the 3-way handshake, as used in the
> OIF OUNI, potentially offers significant reductions in latency of
> establishing bidirectional LSPs for LSRs where hardware programming is slow.
> The motivation here is the same as for Suggested Label (described in
> draft-ietf-mpls-generalized-signaling section 3.4).
>
> 2-way handshake
> ---------------
>
> With 2-way handshaking, the egress LSR can send reverse direction data as
> soon as it receives the Path (as in GMPLS
> draft-ietf-mpls-generalized-rsvp-te, section 3.1, paragraph 4).  Transit
> LSRs must program the reverse direction data path before forwarding the Path
> across the network or there is a risk that reverse direction data will be
> lost.  ResvConf is optional, and if sent it does not affect the timing of
> the setup of the data path.
>
> The benefits of this are as follows.
>
> * If the significant factor in latency is message propagation, then
> the latency for establishment of the reverse direction data path is one
> third as long as 3-way handshaking (the time taken for the Path message to
> cross the network, rather than Path, Resv, ResvConf).  Arguably, reverse
> direction latency is less important than downstream - the initiating LSR is
> the one that triggered the LSP establishment, so is more likely to have the
> immediate requirement to send data.
>
> * Less signaling traffic and less processing required.  However
> ResvConf processing is probably not a very large proportion of overall load.
>
> 3-way handshake
> ---------------
>
> In this approach, ResvConf becomes mandatory for bidirectional LSPs, and the
> egress LSR cannot send reverse direction data until it has received this
> message (those familiar with the OIF OUNI will note this matches
> oif2000-125.4 Section 12.4.8, figure 12.1).  Transit LSRs may forward the
> Path message before completing reverse direction data path programming.
>
> The advantage of 3-way handshaking is as follows.  If hardware programming
> is the significant factor in latency, then latency is significantly reduced
> as we can parallelize hardware programming at each LSR.  Each LSR can start
> programming on receipt of the Path message (based on the Upstream Label and
> Suggested Label), but forward the message immediately.  The total latency is
> dominated by the maximum of each LSR's programming latency, rather than the
> sum.
>
> Dynamic selection
> -----------------
>
> As a third option, we propose a possible solution to support either 2-way or
> 3-way handshaking in RSVP GMPLS, at the choice of the LSRs involved.  By
> default, 2-way handshaking is used.  However, any LSR can delay programming,
> in which case, the egress LSR must be informed that a 3-way handshake is
> required.  The requirement for 3-way handshaking must be indicated in the
> Path message, and we propose using a RESV_CONFIRM object on the Path message
> to do so.
>
> In more detail, this works as follows.
>
> * Any ingress or transit LSR MAY elect to enable 3-way handshaking and
> forward the Path message before completing programming of the reverse
> direction data path.  Typically it would do so because hardware programming
> is slow.  If it elects to do so, it MUST add a RESV_CONFIRM object to the
> Path message.
>
> * A transit LSR receiving a Path message with a RESV_CONFIRM object
> SHOULD forward the Path message before completing programming of the reverse
> direction data path.  However it MAY choose not to do so.
>
> * An egress LSR receiving a Path message with a RESV_CONFIRM object
> SHOULD include its own RESV_CONFIRM object in the Resv and it SHOULD NOT
> start to send reverse direction data until it receives the ResvConf message.
> (If it does send sooner, then data may be lost).
>
> * Each LSR MUST complete programming of both directions before
> forwarding the Resv message.
>
> Moving Forward
> --------------
>
> We would be interested to get feedback from readers of this list on which
> option is preferred.  If it is felt that dynamic selection is best, then is
> the solution we have proposed suitable?
>
> Regards,
> Adam
>
>
> Adam Shepherd
> Network Convergence Group
> Data Connection Ltd
> -------------------
>
> Tel: +44 (0) 20 8366 1177                Fax: +44 (0) 20 8363 1468
> Email: [email-masked]  Web: http://www.dataconnection.com
>

Delivery-date: Wed, 23 May 2001 08:06:56 -0700
Date: Wed, 23 May 2001 17:04:27 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Heiles Juergen <[email-masked]>
CC: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------AAF6BF94651045028486CA0B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello Juergen,

Only two short remarks here on the AUG/STS-Group:
- First, on relation with transparency, it is clearly indicated
into the document:
"Note as well that transparency is only applicable when using     
the following Signal Types (ST's): STM-1, STM-4, STM-16, STM-64,
STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-768. At
least one transparency type must be specified when requesting 
such a signal type. NOT WITH AUG/STS-G"
- Second it is clearly indicated into the document that:
"Administrative Unit Group-N's (AUG-N's) are either a homogeneous
collection of AU-3s or AU-4s. When used as a signal type this
means that all the VC-3s or VC-4s in the AU-3s or AU-4s that 
comprise the AUG-N are switched together as one UNIQUE signal..." 

So, by taking care of cautiously defining the terms used in the 
document, we were convinced (by one of your itu-t colleagues) that 
introducing such kind of signal into the current document can 
increase it's utility (since TUG were already introduced at that 
time in the document it was a question of consistency as well
so i am surprised on the fact you missed the TUG since they are
referenced in the document since March 2001 so TUG were introduced
prior to the last published version) since today he provides such 
kind of services - at that time the argument was "what can i do
with gmpls if it doesn't cover any service covered today by our
product !" - NB: now there is an informal 'agreement' with the 
referenced person to introduce the related material in order to 
propose itu-t specification alignment. 

Kind regards,
Dimitri.

Heiles Juergen wrote:
> 
> The concatenation waves are going high here on the mailing list.
> I attended the Paris editing session and didn't complain about the proprietary solutions.
> However the ongoing discussion showed me several points:
> - When we start to introduce one proprietary solution we open the document for any proprietary solution, where will we stop (I want B3 transparency and I over connection setup for containers (without POH)? Do we really want to define the signaling support for single, two, three vendor solutions. I would leave this to the vendors. They implemented a proprietary transport plane solution so they can also define their proprietary control plane solution. If we have a broader interest in the feature we should look at the application and consider if it should be standardized both for the transport plane and the control plane.
> - Remember that we define the control in order to support the transport plane and not vice versa. A stand alone transport plane makes sense (and has been in use for years), a stand alone control plane doesn't. Interworking at the control plane doesn't help much if the transport plane doesn't interwork. So it should be a common standardization activity both in the control and in the transport plane.
> - If we define something proprietary we need information about the feature, we cannot do it with guesses.
> - We also have to be careful with proprietary features as we don't know what implications they have on the transport plane, they might exclude each other. That can happen as we focus only on the control plane and don't care about the implications at the transport plane. We can generate a real mess.
> - I don't want to restrict new ideas and developments. Actually you cannot kill a good solution that fits network needs by blocking it from a standard. If someone builds it and shows its advantages operators will start to ask for it.
> 
> Now coming to Erics new proposed section:
> In my view the proposal makes it even worse. Just say this is a standard feature and this is a proprietary feature. Don't start to explain how we can come form a proprietary  feature to interworking or a standard. And don't start to explain how the feature could be implemented. It will bring you into more trouble. This is a control plane document, nothing more.
> 
> Arbitrary contiguous concatenation:
> What are the relaxed limitations. Either say nothing or define it in detail, but the later is not the task of this document.
> 
> Transparency:
> RS and MS transparency is a standard feature, while transparency of individual overhead bytes is not. You have to distinguish between the two.
> Transparency of individual bytes is an critical issue. You violate the layers and can screw up your whole management. In addition it is not real transparency what is needed, it is functional transparency. For example for B2. Or for the DCC bytes you might allow byte slips. But what implications has this on the DCN? It is easy to define a feature for the control plane and don't care about the transport plane implications.
> Although you are a strong supporter of transparency, you were very fast in dropping the already included B2 transparency. Because it is not a straight forward solution? Requires some awkward processing? And some people don't understand how it works? That might be also true for other features (flexible arbitrary concatenation). So why include one and not the other?
> 
> Flexible arbitrary contiguous concatenation:
> You started to describe a implementation. You have a certain solution in your mind. I think about a completely different approach. We both don't know it exactly, we just guess. Is this a good base to achieve interoperability.
> One problem I see has to do with the AUG7STS Group signal type, another proprietary feature. The AUG/STS group signal type provides some transparency concerning the underlying VC-3/4/4-Xc structure. However as pointer processing for the individual VCs is still required in case of multiplexing the network elements have to detect the VC-N structure by themselves using the pointer information (valid pointer, concatenation indication). But this doesn't work with flexible arbitrary contiguous concatenation, at least with the solution I have in mind. Additional information on the VCs that belong together is needed in-band (SOH?) if automatic detection should be supported. If it is not supported it cannot be part of a AUG/STS group signal type while all other types of concatenation can be. If it is supported you might not need a label set. A label for the first time slot is enough. The network element detects which other belong to the group. So from the currently available inform!
 at!
>  io!
> !
> !
> n it is difficult to tell if the control plane support is correct.
> One other question. The Sonet/SDH GMPLS document says that virtual concatenation can be used with any contiguous concatenation. Although with flexible arbitrary contiguous concatenation as both require a label set?
> 
> Coming back to the AUG/STS group and TUG. I missed it in your new proposed section. It is a proprietary feature.
> Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783. It should be noted that AUG/TUG are not and were never intended to be networking entities. They were introduced as internal signal structures in order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and RS are the networking entities.
> A AUG/STS group or TUG provides some transparency concerning the underlying VC-N structure. IF you multiplex the signal you still have to do pointer processing for the individual VCs. As a AUG/STS group or TUG has no overhead of its own, any supervision has to be performed on the individual VCs. So what will it buy us ?(ok, ok better not to ask the question, some one supports it and has its good reasons to do so as it is the case for any of the above features)
> 
> Regards
> 
>         Juergen
> 
> > -----Original Message-----
> > From: Mannie, Eric [SMTP:[email-masked]]
> > Sent: Tuesday, May 22, 2001 9:22 PM
> > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc:   [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject:      RE: Proposed text for the concatenation
> >
> > Hello Man Wing, Bala and All,
> >
> > >I think Eric's proposed text gives a very good coverage on all cases
> >
> > Thanks :-)
> >
> > >and all we need is indicating which field is ... optional
> >
> > Indeed everything is already optional in the draft except the signal type of
> > course:
> >
> >   - CCT: set to zero to say no contiguous concatenation requested (default
> > value)
> >   - NCC: set to zero when CCT is set to zero (default value)
> >   - NVC: set to zero to say no virtual concatenation (default value).
> >   - Multiplier: set to one if one instance (default value).
> >   - transparency: set to zero to say don't care (default value).
> >
> > So there is no issue there, I will add a specific paragraph to re-enforce
> > it.
> >
> > In addition, when a downstream node receives an "incoming request" he can
> > decide to accept it or to refuse it depending of what is requested,
> > depending of the CAC process, depending of the customer profile, depending
> > of the capabilities that it supports, etc.
> >
> > The draft doesn't indicate what must be implemented of course.
> >
> > >and all we need is indicating which field is standard....
> >
> > Ok, I agree. Let's indicate in the draft the features that are not
> > standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> > concatenation, and transparency. Is there another one ? All the signal types
> > have an equivalent definition in the standards.
> >
> > --- proposed new section:
> >
> > X. Relationship with SDH and SONET standards
> >
> > Some of the features described in this specification are not defined neither
> > in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
> > these features are useful and implemented in many equipment's. All these
> > features are optional but can be controlled using this specification.>
> >
> > These features are: arbitrary contiguous concatenation, flexible arbitrary
> > contiguous concatenation and transparency. They have been > described in the
> > relevant sections of this specification.
> >
> > Arbitrary contiguous concatenation does not need any additional standard to
> > interoperate. It simply relaxes some limitations specified in the
> > corresponding AINSI and ITU-T standards.
> >
> > Transparency does not need any standard at the UNI since it is only
> > implemented in the data plane at the NNI. This can be requested using the
> > signaling at the UNI, independently of its implementation at the NNI.
> > Interoperability between multiple manufacturers at the NNI can be achieved
> > in different ways: through the use of a standard, an implementation
> > agreement made by a forum, or an implementation agreement between two
> > manufacturers (e.g. at the request of an operator).
> >
> > Flexible arbitrary contiguous concatenation just need a very simple and
> > obvious agreement to interoperate between multiple manufacturers. Again this
> > can be achieved in different ways: through the use of a standard, an
> > implementation agreement made by a forum, or an implementation agreement
> > between two manufacturers (e.g. at the request of an operator). A simple
> > agreement could for instance simply indicate where is copied the original
> > path overhead when "inverse multiplexing" locally a contiguously
> > concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at all
> > about this paragraph, ideas are welcome, please help !
> >
> > ---------- End of text
> >
> > Agreed ? Comments ?
> >
> > Comments from our ITU-T folks are welcome (really :-)
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Tuesday, May 22, 2001 5:15 PM
> > To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: Proposed text for the concatenation
> >
> >
> > Very good point, Greg. If I remember correctly, the initial email initiated
> > such a great discussion was someone asked about whether it was worth
> > investing development effort on arbitrary concatenation. The bottom line is
> > if there is an appearing business case for the feature, then you will
> > support it. As some of you (vendors) already indicated that your systems
> > support AC because there are operators using and asking for this feature.
> > There might be a lot of vendors and users supporting this or might be just a
> > few, but the fact is there are someone supporting it. When defining new
> > protocols, I agree that we should consider and cover all cases, as long as
> > any non-standard fields are optional.
> > I think Eric's proposed text gives a very good coverage on all cases and all
> > we need is indicating which field is non-standard and optional.
> >
> > Man Wing
> >
> >
--------------AAF6BF94651045028486CA0B
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------AAF6BF94651045028486CA0B--

Delivery-date: Wed, 23 May 2001 07:06:36 -0700
From: Adam Shepherd <[email-masked]>
To: [email-masked], [email-masked]
Subject: Timing of the upstream data path establishment
Date: Wed, 23 May 2001 15:05:36 +0100

Hi all

We have been considering some issues regarding the timing of the
establishment of the reverse direction data path for bidirectional LSPs in
RSVP GMPLS.  We would be interested in input from the mailing list on
whether these problems are significant, and if so, whether there is a strong
enough case for modifying the drafts at this stage.

The key factor is whether bidirectional LSP establishment is a 2-way
handshake (Path, Resv), as currently, or a 3-way one (Path, Resv and
mandatory ResvConf).  We believe that the 3-way handshake, as used in the
OIF OUNI, potentially offers significant reductions in latency of
establishing bidirectional LSPs for LSRs where hardware programming is slow.
The motivation here is the same as for Suggested Label (described in
draft-ietf-mpls-generalized-signaling section 3.4).

2-way handshake
---------------

With 2-way handshaking, the egress LSR can send reverse direction data as
soon as it receives the Path (as in GMPLS
draft-ietf-mpls-generalized-rsvp-te, section 3.1, paragraph 4).  Transit
LSRs must program the reverse direction data path before forwarding the Path
across the network or there is a risk that reverse direction data will be
lost.  ResvConf is optional, and if sent it does not affect the timing of
the setup of the data path.

The benefits of this are as follows.

*	If the significant factor in latency is message propagation, then
the latency for establishment of the reverse direction data path is one
third as long as 3-way handshaking (the time taken for the Path message to
cross the network, rather than Path, Resv, ResvConf).  Arguably, reverse
direction latency is less important than downstream - the initiating LSR is
the one that triggered the LSP establishment, so is more likely to have the
immediate requirement to send data.

*	Less signaling traffic and less processing required.  However
ResvConf processing is probably not a very large proportion of overall load.

3-way handshake
---------------

In this approach, ResvConf becomes mandatory for bidirectional LSPs, and the
egress LSR cannot send reverse direction data until it has received this
message (those familiar with the OIF OUNI will note this matches
oif2000-125.4 Section 12.4.8, figure 12.1).  Transit LSRs may forward the
Path message before completing reverse direction data path programming.

The advantage of 3-way handshaking is as follows.  If hardware programming
is the significant factor in latency, then latency is significantly reduced
as we can parallelize hardware programming at each LSR.  Each LSR can start
programming on receipt of the Path message (based on the Upstream Label and
Suggested Label), but forward the message immediately.  The total latency is
dominated by the maximum of each LSR's programming latency, rather than the
sum.

Dynamic selection
-----------------

As a third option, we propose a possible solution to support either 2-way or
3-way handshaking in RSVP GMPLS, at the choice of the LSRs involved.  By
default, 2-way handshaking is used.  However, any LSR can delay programming,
in which case, the egress LSR must be informed that a 3-way handshake is
required.  The requirement for 3-way handshaking must be indicated in the
Path message, and we propose using a RESV_CONFIRM object on the Path message
to do so.

In more detail, this works as follows.

*	Any ingress or transit LSR MAY elect to enable 3-way handshaking and
forward the Path message before completing programming of the reverse
direction data path.  Typically it would do so because hardware programming
is slow.  If it elects to do so, it MUST add a RESV_CONFIRM object to the
Path message.

*	A transit LSR receiving a Path message with a RESV_CONFIRM object
SHOULD forward the Path message before completing programming of the reverse
direction data path.  However it MAY choose not to do so.

*	An egress LSR receiving a Path message with a RESV_CONFIRM object
SHOULD include its own RESV_CONFIRM object in the Resv and it SHOULD NOT
start to send reverse direction data until it receives the ResvConf message.
(If it does send sooner, then data may be lost).

*	Each LSR MUST complete programming of both directions before
forwarding the Resv message.

Moving Forward
--------------

We would be interested to get feedback from readers of this list on which
option is preferred.  If it is felt that dynamic selection is best, then is
the solution we have proposed suitable?

Regards,
Adam

Adam Shepherd
Network Convergence Group
Data Connection Ltd
-------------------

Tel: +44 (0) 20 8366 1177                Fax: +44 (0) 20 8363 1468
Email: [email-masked]  Web: http://www.dataconnection.com

Delivery-date: Wed, 23 May 2001 06:00:02 -0700
From: Heiles Juergen <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Bala Rajagopalan'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Wed, 23 May 2001 14:57:22 +0200

The concatenation waves are going high here on the mailing list.
I attended the Paris editing session and didn't complain about the proprietary solutions.
However the ongoing discussion showed me several points:
- When we start to introduce one proprietary solution we open the document for any proprietary solution, where will we stop (I want B3 transparency and I over connection setup for containers (without POH)? Do we really want to define the signaling support for single, two, three vendor solutions. I would leave this to the vendors. They implemented a proprietary transport plane solution so they can also define their proprietary control plane solution. If we have a broader interest in the feature we should look at the application and consider if it should be standardized both for the transport plane and the control plane.
- Remember that we define the control in order to support the transport plane and not vice versa. A stand alone transport plane makes sense (and has been in use for years), a stand alone control plane doesn't. Interworking at the control plane doesn't help much if the transport plane doesn't interwork. So it should be a common standardization activity both in the control and in the transport plane.
- If we define something proprietary we need information about the feature, we cannot do it with guesses.
- We also have to be careful with proprietary features as we don't know what implications they have on the transport plane, they might exclude each other. That can happen as we focus only on the control plane and don't care about the implications at the transport plane. We can generate a real mess.
- I don't want to restrict new ideas and developments. Actually you cannot kill a good solution that fits network needs by blocking it from a standard. If someone builds it and shows its advantages operators will start to ask for it.

Now coming to Erics new proposed section:
In my view the proposal makes it even worse. Just say this is a standard feature and this is a proprietary feature. Don't start to explain how we can come form a proprietary  feature to interworking or a standard. And don't start to explain how the feature could be implemented. It will bring you into more trouble. This is a control plane document, nothing more.

Arbitrary contiguous concatenation:
What are the relaxed limitations. Either say nothing or define it in detail, but the later is not the task of this document.

Transparency:
RS and MS transparency is a standard feature, while transparency of individual overhead bytes is not. You have to distinguish between the two.
Transparency of individual bytes is an critical issue. You violate the layers and can screw up your whole management. In addition it is not real transparency what is needed, it is functional transparency. For example for B2. Or for the DCC bytes you might allow byte slips. But what implications has this on the DCN? It is easy to define a feature for the control plane and don't care about the transport plane implications.
Although you are a strong supporter of transparency, you were very fast in dropping the already included B2 transparency. Because it is not a straight forward solution? Requires some awkward processing? And some people don't understand how it works? That might be also true for other features (flexible arbitrary concatenation). So why include one and not the other?

Flexible arbitrary contiguous concatenation:
You started to describe a implementation. You have a certain solution in your mind. I think about a completely different approach. We both don't know it exactly, we just guess. Is this a good base to achieve interoperability.
One problem I see has to do with the AUG7STS Group signal type, another proprietary feature. The AUG/STS group signal type provides some transparency concerning the underlying VC-3/4/4-Xc structure. However as pointer processing for the individual VCs is still required in case of multiplexing the network elements have to detect the VC-N structure by themselves using the pointer information (valid pointer, concatenation indication). But this doesn't work with flexible arbitrary contiguous concatenation, at least with the solution I have in mind. Additional information on the VCs that belong together is needed in-band (SOH?) if automatic detection should be supported. If it is not supported it cannot be part of a AUG/STS group signal type while all other types of concatenation can be. If it is supported you might not need a label set. A label for the first time slot is enough. The network element detects which other belong to the group. So from the currently available informatio!
!
n it is difficult to tell if the control plane support is correct.
One other question. The Sonet/SDH GMPLS document says that virtual concatenation can be used with any contiguous concatenation. Although with flexible arbitrary contiguous concatenation as both require a label set?

Coming back to the AUG/STS group and TUG. I missed it in your new proposed section. It is a proprietary feature.
Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783. It should be noted that AUG/TUG are not and were never intended to be networking entities. They were introduced as internal signal structures in order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and RS are the networking entities.
A AUG/STS group or TUG provides some transparency concerning the underlying VC-N structure. IF you multiplex the signal you still have to do pointer processing for the individual VCs. As a AUG/STS group or TUG has no overhead of its own, any supervision has to be performed on the individual VCs. So what will it buy us ?(ok, ok better not to ask the question, some one supports it and has its good reasons to do so as it is the case for any of the above features)

Regards

	Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Tuesday, May 22, 2001 9:22 PM
> To:	'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> Cc:	[email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:	RE: Proposed text for the concatenation
> 
> Hello Man Wing, Bala and All,
> 
> >I think Eric's proposed text gives a very good coverage on all cases
> 
> Thanks :-)
> 
> >and all we need is indicating which field is ... optional
> 
> Indeed everything is already optional in the draft except the signal type of
> course:
> 
>   - CCT: set to zero to say no contiguous concatenation requested (default
> value)
>   - NCC: set to zero when CCT is set to zero (default value)
>   - NVC: set to zero to say no virtual concatenation (default value).
>   - Multiplier: set to one if one instance (default value).
>   - transparency: set to zero to say don't care (default value).
> 
> So there is no issue there, I will add a specific paragraph to re-enforce
> it.
> 
> In addition, when a downstream node receives an "incoming request" he can
> decide to accept it or to refuse it depending of what is requested,
> depending of the CAC process, depending of the customer profile, depending
> of the capabilities that it supports, etc.
> 
> The draft doesn't indicate what must be implemented of course.
> 
> >and all we need is indicating which field is standard....
> 
> Ok, I agree. Let's indicate in the draft the features that are not
> standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
> concatenation, and transparency. Is there another one ? All the signal types
> have an equivalent definition in the standards.
> 
> --- proposed new section:
> 
> X. Relationship with SDH and SONET standards
> 
> Some of the features described in this specification are not defined neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.> 
> 
> These features are: arbitrary contiguous concatenation, flexible arbitrary
> contiguous concatenation and transparency. They have been > described in the
> relevant sections of this specification.
> 
> Arbitrary contiguous concatenation does not need any additional standard to
> interoperate. It simply relaxes some limitations specified in the
> corresponding AINSI and ITU-T standards.
> 
> Transparency does not need any standard at the UNI since it is only
> implemented in the data plane at the NNI. This can be requested using the
> signaling at the UNI, independently of its implementation at the NNI.
> Interoperability between multiple manufacturers at the NNI can be achieved
> in different ways: through the use of a standard, an implementation
> agreement made by a forum, or an implementation agreement between two
> manufacturers (e.g. at the request of an operator).
> 
> Flexible arbitrary contiguous concatenation just need a very simple and
> obvious agreement to interoperate between multiple manufacturers. Again this
> can be achieved in different ways: through the use of a standard, an
> implementation agreement made by a forum, or an implementation agreement
> between two manufacturers (e.g. at the request of an operator). A simple
> agreement could for instance simply indicate where is copied the original
> path overhead when "inverse multiplexing" locally a contiguously
> concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at all
> about this paragraph, ideas are welcome, please help !
> 
> ---------- End of text
> 
> Agreed ? Comments ?
> 
> Comments from our ITU-T folks are welcome (really :-)
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 22, 2001 5:15 PM
> To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
> Cc: [email-masked]; [email-masked]
> Subject: RE: Proposed text for the concatenation
> 
> 
> Very good point, Greg. If I remember correctly, the initial email initiated
> such a great discussion was someone asked about whether it was worth
> investing development effort on arbitrary concatenation. The bottom line is
> if there is an appearing business case for the feature, then you will
> support it. As some of you (vendors) already indicated that your systems
> support AC because there are operators using and asking for this feature.
> There might be a lot of vendors and users supporting this or might be just a
> few, but the fact is there are someone supporting it. When defining new
> protocols, I agree that we should consider and cover all cases, as long as
> any non-standard fields are optional.
> I think Eric's proposed text gives a very good coverage on all cases and all
> we need is indicating which field is non-standard and optional.
> 
> Man Wing
> 
>  

Delivery-date: Wed, 23 May 2001 00:45:08 -0700
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 23 May 2001 09:43:20 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ASTN Layer Network Architecture

This is a multi-part message in MIME format.
--------------141BFC7477E19D963B8C56C8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have now also uploaded the document to the T1X1.5 ftp area:

ftp://ftp.t1.org/T1X1/X1.5/1x151260.doc
ftp://ftp.t1.org/T1X1/X1.5/1x151260.pdf

Regards,

Maarten

Maarten Vissers wrote:
> 
> To illustrate the multi layer aspects of the transport network and the
> interactions between control plane (instance)s in an automatic switched
> transport network, I created the following correspondence document:
> 
> http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-multi-cp.doc
> http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-multi-cp.pdf
> 
> Regards,
> 
> Maarten
> PS. ITU-T has promised to create an open area in which documents can be
> placed with world wide read access. I am checking if this open area is
> now available, so I can upload the above document into it as well. If
> not available I will upload the document to T1X1.5 ftp server.
--------------141BFC7477E19D963B8C56C8
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------141BFC7477E19D963B8C56C8--

Delivery-date: Tue, 22 May 2001 13:12:41 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Eric Gray' <[email-masked]>
Cc: "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, 'Bala Rajagopalan' <[email-masked]>,  [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Tue, 22 May 2001 22:11:35 +0200

Hello Eric,

>'not', 'neither' and 'nor' - either say 'are defined neither in ... nor in
...'
>or
>say 'are not defined either in ... or in ...'  As is, you are double
negating
>and
>effectively saying these features ARE defined in BOTH places.

Oooops, in French we have double negations (a particularity of our
marvellous language), I forget that problem constantly, sorry :-)

Thanks,

Eric-2

Delivery-date: Tue, 22 May 2001 13:04:57 -0700
Date: Tue, 22 May 2001 16:03:33 -0400
From: Eric Gray <[email-masked]>
To: "Mannie, Eric" <[email-masked]>
Cc: "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, 'Bala Rajagopalan' <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: Proposed text for the concatenation

"Mannie, Eric" wrote:

> ...
>
> --- proposed new section:
>
> X. Relationship with SDH and SONET standards
>
> Some of the features described in this specification are not defined neither
> in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000).

'not', 'neither' and 'nor' - either say 'are defined neither in ... nor in ...'
or
say 'are not defined either in ... or in ...'  As is, you are double negating
and
effectively saying these features ARE defined in BOTH places.

> However,
> these features are useful and implemented in many equipment's. All these
> features are optional but can be controlled using this specification.
>
> ...
>

--
Eric Gray

Delivery-date: Tue, 22 May 2001 12:24:08 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Fong, Man Wing'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, 'Bala Rajagopalan' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Tue, 22 May 2001 21:22:15 +0200

Hello Man Wing, Bala and All,

>I think Eric's proposed text gives a very good coverage on all cases

Thanks :-)

>and all we need is indicating which field is ... optional

Indeed everything is already optional in the draft except the signal type of
course:

  - CCT: set to zero to say no contiguous concatenation requested (default
value)
  - NCC: set to zero when CCT is set to zero (default value)
  - NVC: set to zero to say no virtual concatenation (default value).
  - Multiplier: set to one if one instance (default value).
  - transparency: set to zero to say don't care (default value).

So there is no issue there, I will add a specific paragraph to re-enforce
it.

In addition, when a downstream node receives an "incoming request" he can
decide to accept it or to refuse it depending of what is requested,
depending of the CAC process, depending of the customer profile, depending
of the capabilities that it supports, etc.

The draft doesn't indicate what must be implemented of course.

>and all we need is indicating which field is standard....

Ok, I agree. Let's indicate in the draft the features that are not
standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
concatenation, and transparency. Is there another one ? All the signal types
have an equivalent definition in the standards.

--- proposed new section:

X. Relationship with SDH and SONET standards

Some of the features described in this specification are not defined neither
in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
these features are useful and implemented in many equipment's. All these
features are optional but can be controlled using this specification.

These features are: arbitrary contiguous concatenation, flexible arbitrary
contiguous concatenation and transparency. They have been described in the
relevant sections of this specification.

Arbitrary contiguous concatenation does not need any additional standard to
interoperate. It simply relaxes some limitations specified in the
corresponding AINSI and ITU-T standards.

Transparency does not need any standard at the UNI since it is only
implemented in the data plane at the NNI. This can be requested using the
signaling at the UNI, independently of its implementation at the NNI.
Interoperability between multiple manufacturers at the NNI can be achieved
in different ways: through the use of a standard, an implementation
agreement made by a forum, or an implementation agreement between two
manufacturers (e.g. at the request of an operator).

Flexible arbitrary contiguous concatenation just need a very simple and
obvious agreement to interoperate between multiple manufacturers. Again this
can be achieved in different ways: through the use of a standard, an
implementation agreement made by a forum, or an implementation agreement
between two manufacturers (e.g. at the request of an operator). A simple
agreement could for instance simply indicate where is copied the original
path overhead when "inverse multiplexing" locally a contiguously
concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at all
about this paragraph, ideas are welcome, please help !

---------- End of text

Agreed ? Comments ?

Comments from our ITU-T folks are welcome (really :-)

Kind regards,

Eric

-----Original Message-----
From: Fong, Man Wing [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 5:15 PM
To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Very good point, Greg. If I remember correctly, the initial email initiated
such a great discussion was someone asked about whether it was worth
investing development effort on arbitrary concatenation. The bottom line is
if there is an appearing business case for the feature, then you will
support it. As some of you (vendors) already indicated that your systems
support AC because there are operators using and asking for this feature.
There might be a lot of vendors and users supporting this or might be just a
few, but the fact is there are someone supporting it. When defining new
protocols, I agree that we should consider and cover all cases, as long as
any non-standard fields are optional.
I think Eric's proposed text gives a very good coverage on all cases and all
we need is indicating which field is non-standard and optional.

Man Wing

Delivery-date: Tue, 22 May 2001 10:24:42 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Waveband definition [was: GMPLS Message Structures]
Date: Tue, 22 May 2001 10:23:32 -0700

Hi Marteen,

           Thanks for the reply. But the definition what u provided is not 
covered in the draft. I think we need to put these things clearly in the 
draft.
I have some more doubts on waveband. Please clarify.

Also, for waveband switching, the genralized label has the format wavebandId 
- start label - end label).
When the label request message is received on incoming interface, how to 
identify that the waveband label is requested ?
Is it the LSP encoding type or some other parameter in label request
message? If it is the Lambda encoding type then how to identify that whether 
a lambda or waveband label is requested ?

Also, it is mentioned that wavebandId (32 bits) is selected by the sender 
and reused in all the subsequent messages. What all subsequent
messages is it mentioning to ?

Are not people stressing more on SDH/SONET extensions rather than WDM ?

Thanks,
manoj.

>From: Maarten Vissers <[email-masked]>
>To: Yuri Landry <[email-masked]>, [email-masked],   
>[email-masked], [email-masked]
>Subject: Waveband definition [was: GMPLS Message Structures]
>Date: Tue, 22 May 2001 08:58:07 +0200
>
>Manoj, Yuri,
>
>I received a message that my definition of waveband is too restricted.
>
>A waveband should be an optical multiplex, administered as a single
>bundle, not necessary contiguous in frequency slot.
>
>	E.g. there may be good technical reasons to consider a
>	'waveband' created at an OADM formed by taking every 2nd
>	wavelength in a 50GHz-spaced transmission band.
>
>In first instance the above definition may not be considered this as a
>"band"; it
>looks more like a "gapped-band" :-). Nevertheless, due to technical
>reasons we should consider a waveband as just another name for a
>particular group of wavelengths, which may best be viewed as a group of
>identified/listed wavelengths.
>
>Regards,
>
>Maarten
>
>Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > In my current understanding, a waveband is a group of OCh (optical
> > channel) signals located in a contiguous set of tributary (i.e.
> > frequency) slots.
> >
> > A waveband is therefore related to partitioning, rather than a layering.
> > A waveband shouldn't have an LSP encoding type itself, but instead be
> > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > type) of "contiguous waveband" can be defined for this purpose with the
> > RNC (requested number of components) indicating the size of the
> > waveband.
> >
> > The above is simply a first shot; in general the issue can be more
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > optimized freq. slot widths, a waveband might need a start-of-waveband
> > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Mano,
> > >
> > > >            Can someone tell me the message structure of Label 
>Request and
> > > >Label Mapping in GMPLS ?
> > > >I am confused about the presence of LightPath Id in O-UNI messages 
>and LSP
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids 
>or Is
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS 
>messages
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be 
>mapped
> > > >to
> > > >multiple LSP Ids or vice versa ?
> > >
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID 
>for
> > > network connection, which may consist many LSPs. For example, the 
>virtual
> > > concatenation case.
> > >
> > > A LSP may tunnel through multiple pre-established connections.
> > >
> > > >Also, for waveband switching, the genralized label has the format
> > > >(wavebandId - start label - end label).
> > > >When the label request message is received on incoming interface, how 
>to
> > > >identify that the waveband label is requested ?
> > > >Is it the LSP encoding type or some other parameter in label request
> > > >message
> > > >? If it is the Lambda encoding type then how to identify that whether 
>a
> > > >lambda or waveband label is requested ?
> > > >
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the 
>sender
> > > >and reused in all the subsequent messages. What all subsequent
> > > >messages is it mentioning to ?
> > > >
> > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > >
> > > >I am not able to workout the message structures for GMPLS.
> > > >
> > >
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to 
>have
> > > the waveband label is that someone claimed that the waveband's order 
>might
> > > flip when going through a switch. My suggestion is don't take it 
>seriously.
> > >
> > > >I am not sure how these drafts are at last call. Atleast it should 
>mention
> > > >the message structures of various messages.
> > > >
> > >
> > > Agree.
> > >
> > > Regards,
> > >
> > > Yuri
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 22 May 2001 08:42:54 -0700
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Tue, 22 May 2001 16:32:20 +0100

Eric,

Thanks for taking the time to reply.

I have annotated your text below in capitals, Not to shout, but rather just
to show up!

Regards

	Tony

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 22 May 2001 16:10
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Hello Tony,

>From an operators perspective, I am very concerned at the proposal for
>arbitrary concatenation. It does nothing that virtual concatenation cannot
>achieve (in fact less, as it does not support random time slot assignment
>capability), and involves the upgrade of every network element it traverses
>(virtual only requires support in the terminating devices).

This was extensively discussed last week and apparently not everybody agreed
:-)

NO AGREEMENT REQUIRED. EXISTING EQUIPMENTS CANNOT SUPPORT ARBITRARY (though
no doubt a few could/can though we still couldn't manage them if they
did)...

Of course virtual concatenation would be nice and easier from the network
point of view.
However, in the real world it is not so simple.
Two factors are important: cost and the legacy equipment.

We are operator of both a large transmission network and a large IP transit
AS. Traditionally, IP routers don't implement virtual concatenation (as far
as I know virtual concatenation is not implemented at all by Cisco, all
interfaces are contiguously concatenated).

SDH/SONET ALREADY SUPPORTS CONTIGUOUS SO THE ABOVE IS NOT AN ISSUE

Note that this is only relevant for IP routers connected through a switched
SDH network. It is not relevant if two IP routers are directly connected by
a lambda using POS encapsulation (that's the way the Ebone IP backbone is
build), in that case you don't care. You just implement the easiest/cheapest
solution, i.e. contiguous concatenation. However we are facing a large
demand for VC-4-4c from our customers.

There are also some *cheap* (interesting for operators) edge devices (ADM's,
terminal multiplexers) that don't implement virtual concatenation at all.
For instance, devices used to transport FE/GE in the MAN.

However, a significant number of manufacturers are proposing ADM's that
implement virtual concatenation, and some of them supports even LCAS (Link
Capacity Adjustment Scheme). That becomes really interesting and that's cool
from the network and service point of view.

THIS APPLICATION HAS BEEN INTRODUCED AT ITU AND IS PROCEEDING RAPIDLY. You'r
correct. It's cool.

So for IP we need contiguous concatenation, for Ethernet services we need
virtual concatenation and contiguous concatenation.

Flexible concatenation is a local optimization at an interface needed to
optimize the bandwidth allocation. It was not needed in the past, it is now
needed because we will have dynamic circuits that could create fragmentation
in the multiplex. See hereafter.

IF FRAGMENTATION IS CAUSING PROBLEMS, THEN USE THE DEFINED CONTIGUOUS TO
Virtual converter that is already standardised.

Arbitrary contiguous concatenation is interesting for two reasons, first if
you sell new services with new bandwidth levels e.g. a VC-3-3c, VC-4-5c,
etc. Second, because you have again the optimization problem, for instance
if you have a mix of VC-4's and concatenated VC-4's, you could want to
optimize the bandwidth allocation and to start a VC-4-4c at any place.

VC-4-5C DOES NOT EXIST. VC-4-5V DOES EXIST AND does not suffer the
optimisation problems

>Could the contributors to this technique explain why we need to define
>another Ford when we already have a Ferrari?

In the dynamic model that we are thinking about, circuits will be
established and closed dynamically. After some time you could have a
fragmented multiplex. It is similar to the hard disk fragmentation problem,
after some time your have small holes everywhere. You cannot re-use these
small holes for a contiguous block of bandwidth, except if you re-organize
your network (intrusive). A way to solve the problem is to enable flexible
concatenation. It is useful for the user if his local interface multiplex is
completely fragmented and that he cannot open a new circuit anymore due to
the lack of a contiguous block that is big enough. It is also a useful local
optimization internally to the network.

VIRTUAL ALREADY ALLOWS THIS (Or to use the Ford ananalgy again, Any colour
you want as long as it's Virtual) :-)

Kind regards,

Eric

>From an operators perspective, I am very concerned at the proposal for
arbitrary concatenation. It does nothing that virtual concatenation cannot
achieve (in fact less, as it does not support random time slot assignment
capability), and involves the upgrade of every network element it traverses
(virtual only requires support in the terminating devices).

The further addition of flexible arbitrary confuses matters still further
where a contiguous to virtual conversion is already fully defined.

The proposal is technically inferior to the already defined and existing
techniques, and is unlikely to receive a warm welcome if bought to the ITU.
Could the contributors to this technique explain why we need to define
another Ford when we already have a Ferrari?

Regards

	Tony Flavin

	BTexact.

	BTexact.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 18 May 2001 21:28
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

	

Delivery-date: Tue, 22 May 2001 08:16:49 -0700
From: "Fong, Man Wing" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Tue, 22 May 2001 10:14:43 -0500

Very good point, Greg. If I remember correctly, the initial email initiated
such a great discussion was someone asked about whether it was worth
investing development effort on arbitrary concatenation. The bottom line is
if there is an appearing business case for the feature, then you will
support it. As some of you (vendors) already indicated that your systems
support AC because there are operators using and asking for this feature.
There might be a lot of vendors and users supporting this or might be just a
few, but the fact is there are someone supporting it. When defining new
protocols, I agree that we should consider and cover all cases, as long as
any non-standard fields are optional.
I think Eric's proposed text gives a very good coverage on all cases and all
we need is indicating which field is non-standard and optional.

Man Wing

 -----Original Message-----
From: 	Bernstein, Greg [mailto:[email-masked]] 
Sent:	Monday, May 21, 2001 10:41 PM
To:	'Mannie, Eric'; 'Maarten Vissers'
Cc:	[email-masked]; [email-masked]
Subject:	RE: Proposed text for the concatenation

If the goal is interoperability,  it seems like we are getting very
concerned with things that don't matter to that goal.  I'd like to have the
signaling take in all the cases we've discussed, and where there are areas
that the existing standards don't cover (or may not want to cover) we should
define what we mean precisely, state that it is non-standard.
As Lyndon Ong pointed out if multiple vendors don't interoperate with this
feature it will be dropped from the internet standard.
As someone already pointed out, if a customer is willing to pay for a
feature we will supply it.  I'm not sure why we wouldn't want to be able to
interoperate with that feature and for the purpose here we need to describe
what it is in a signaling protocol. Regardless of its current status as a
standard or industry practice.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 3:39 AM
To: 'Maarten Vissers'
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Re-hello Maarten,

>I have been asking for this AUG-X addition.....
>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all. The STSG-X has been made a signal type by my company
>some years ago to support the requirements of some specific customers.

Whaoum, you implemented a non-standardized feature and you re-defined
SDH/SONET in your equipment without the permission of ITU-T :-)

I think that this feature make a lot of sense, you are not the only one that
requested it. In a similar way, other folks requested TUG-X/VTG and this
complements very well your initial request. Moreover, these signal types are
of paramount importance for GMPLS operations since they allow to open a
forwarding adjacency (i.e. an SDH/SONET circuit for which you don't specify
the content) that can be later on sub-structured in whatever you like
(following the SDH/SONET rules of course).

By the way, I don't understand why you said that you need a standard for
AUG-X/STSG-X, TUG-X/VTG...

THERE IS ABSOLUTELY NO NEW STANDARD REQUIRED FOR THAT !

It does not change ANYTHING to SDH/SONET in the data/forwarding plane. It
stays 100% PURE SDH/SONET as in the standards. It is purely a signaling
feature. In addition, even the terminology (AUG-X) is defined in the
standards.

So the only issue that I see is that you don't want to have it because you
can control it by a control plane (whatever is the control plane ???).

>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all.

"Signal type" is not a G.707 vocabulary, we used that vocabulary for GMPLS
signaling. Even VC-4's, VC-3's, etc are not defined as a signal type. So do
you want to say that we cannot neither open a VC-4 circuit because G.707 did
not define the GMPLS concept of signal type ? That doesn't make any sense !

Moreover, AUG-X, TUG-2 and TUG-3 ARE DEFINED in G.707 of course (that's part
of the fundamental specification).

>....I don't want to have
>my requested feature treated any different than any other feature that I
>have been argueing about (arbitrary concatenation, semi-transparent
>STM-N).

Are we playing a game here ???

>As this AUG-X feature is beyond current standards (in this case
>G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
>series of control plane specifications.

Great, the own ITU-T functional description is not aligned to its own
protocol ! So it means that SDH does not work ! Seriously, who cares ?
Protocols are implemented not functional descriptions that helps to
understand protocols. I am sure that G.783 will be updated very soon to
reflect SDH.

Sorry I am lost, what is the goal of all your e-mails ? What do you want to
achieve ?

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, May 21, 2001 4:28 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,

I am serious. (See also my reply to Greg.)

You wrote:
> Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
TUG-X/VTG,
> they are defined in the standards, it is just a code type, like VC-4 or
> STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

I have been asking for this AUG-X addition, with the assumption that I
would write a contribution to get G.783 extended with an additional
MSn/Sn_A function supporting this AUG-X feature... You find this once
more reflected in my email to Greg this morning.

AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
standards at all. The STSG-X has been made a signal type by my company
some years ago to support the requirements of some specific customers.
It's proprietary so far.

But given the result of the discussions last week, I don't want to have
my requested feature treated any different than any other feature that I
have been argueing about (arbitrary concatenation, semi-transparent
STM-N). As this AUG-X feature is beyond current standards (in this case
G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
series of control plane specifications.
Up to that moment in time, it should be a vendor specific extension of
G.ason/GMPLS.

Regards,

Maarten

Delivery-date: Tue, 22 May 2001 08:14:25 -0700
From: "Mannie, Eric" <[email-masked]>
To: [email-masked]
Subject: FW: Proposed text for the concatenation
Date: Tue, 22 May 2001 17:13:08 +0200

-----Original Message-----
From: Mannie, Eric 
Sent: Tuesday, May 22, 2001 5:10 PM
To: [email-masked]'
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Hello Tony,

>From an operators perspective, I am very concerned at the proposal for
>arbitrary concatenation. It does nothing that virtual concatenation cannot
>achieve (in fact less, as it does not support random time slot assignment
>capability), and involves the upgrade of every network element it traverses
>(virtual only requires support in the terminating devices).

This was extensively discussed last week and apparently not everybody agreed
:-)
Of course virtual concatenation would be nice and easier from the network
point of view.
However, in the real world it is not so simple.
Two factors are important: cost and the legacy equipment.

We are operator of both a large transmission network and a large IP transit
AS. Traditionally, IP routers don't implement virtual concatenation (as far
as I know virtual concatenation is not implemented at all by Cisco, all
interfaces are contiguously concatenated).

Note that this is only relevant for IP routers connected through a switched
SDH network. It is not relevant if two IP routers are directly connected by
a lambda using POS encapsulation (that's the way the Ebone IP backbone is
build), in that case you don't care. You just implement the easiest/cheapest
solution, i.e. contiguous concatenation. However we are facing a large
demand for VC-4-4c from our customers.

There are also some *cheap* (interesting for operators) edge devices (ADM's,
terminal multiplexers) that don't implement virtual concatenation at all.
For instance, devices used to transport FE/GE in the MAN.

However, a significant number of manufacturers are proposing ADM's that
implement virtual concatenation, and some of them supports even LCAS (Link
Capacity Adjustment Scheme). That becomes really interesting and that's cool
from the network and service point of view.

So for IP we need contiguous concatenation, for Ethernet services we need
virtual concatenation and contiguous concatenation.

Flexible concatenation is a local optimization at an interface needed to
optimize the bandwidth allocation. It was not needed in the past, it is now
needed because we will have dynamic circuits that could create fragmentation
in the multiplex. See hereafter.

Arbitrary contiguous concatenation is interesting for two reasons, first if
you sell new services with new bandwidth levels e.g. a VC-3-3c, VC-4-5c,
etc. Second, because you have again the optimization problem, for instance
if you have a mix of VC-4's and concatenated VC-4's, you could want to
optimize the bandwidth allocation and to start a VC-4-4c at any place.

>Could the contributors to this technique explain why we need to define
>another Ford when we already have a Ferrari?

In the dynamic model that we are thinking about, circuits will be
established and closed dynamically. After some time you could have a
fragmented multiplex. It is similar to the hard disk fragmentation problem,
after some time your have small holes everywhere. You cannot re-use these
small holes for a contiguous block of bandwidth, except if you re-organize
your network (intrusive). A way to solve the problem is to enable flexible
concatenation. It is useful for the user if his local interface multiplex is
completely fragmented and that he cannot open a new circuit anymore due to
the lack of a contiguous block that is big enough. It is also a useful local
optimization internally to the network.

Kind regards,

Eric

>From an operators perspective, I am very concerned at the proposal for
arbitrary concatenation. It does nothing that virtual concatenation cannot
achieve (in fact less, as it does not support random time slot assignment
capability), and involves the upgrade of every network element it traverses
(virtual only requires support in the terminating devices).

The further addition of flexible arbitrary confuses matters still further
where a contiguous to virtual conversion is already fully defined.

The proposal is technically inferior to the already defined and existing
techniques, and is unlikely to receive a warm welcome if bought to the ITU.
Could the contributors to this technique explain why we need to define
another Ford when we already have a Ferrari?

Regards

	Tony Flavin

	BTexact.

	BTexact.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 18 May 2001 21:28
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

	

Delivery-date: Tue, 22 May 2001 07:55:02 -0700
From: "Yuri Landry" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Waveband definition [was: GMPLS Message Structures]
Date: Tue, 22 May 2001 14:51:43 -0000

Maarten,

Is this your definition, or your interpretation of GMPLS signaling drafts' 
definition? I think it's the first case.

So there is another important issue. We may need to create a dictionary (an 
ID) to align our "words".

Regards,

Yuri

>From: Maarten Vissers <[email-masked]>
>To: Yuri Landry <[email-masked]>, [email-masked],   
>[email-masked], [email-masked]
>Subject: Waveband definition [was: GMPLS Message Structures]
>Date: Tue, 22 May 2001 08:58:07 +0200
>
>Manoj, Yuri,
>
>I received a message that my definition of waveband is too restricted.
>
>A waveband should be an optical multiplex, administered as a single
>bundle, not necessary contiguous in frequency slot.
>
>	E.g. there may be good technical reasons to consider a
>	'waveband' created at an OADM formed by taking every 2nd
>	wavelength in a 50GHz-spaced transmission band.
>
>In first instance the above definition may not be considered this as a
>"band"; it
>looks more like a "gapped-band" :-). Nevertheless, due to technical
>reasons we should consider a waveband as just another name for a
>particular group of wavelengths, which may best be viewed as a group of
>identified/listed wavelengths.
>
>Regards,
>
>Maarten
>
>Maarten Vissers wrote:
> >
> > Manoj, Yuri,
> >
> > In my current understanding, a waveband is a group of OCh (optical
> > channel) signals located in a contiguous set of tributary (i.e.
> > frequency) slots.
> >
> > A waveband is therefore related to partitioning, rather than a layering.
> > A waveband shouldn't have an LSP encoding type itself, but instead be
> > part of the OCh layer network. E.g. a specific RGT (requested groupting
> > type) of "contiguous waveband" can be defined for this purpose with the
> > RNC (requested number of components) indicating the size of the
> > waveband.
> >
> > The above is simply a first shot; in general the issue can be more
> > complex due to the fact that the frequency slot for a 2G5, a 10G and a
> > 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> > 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> > optimized freq. slot widths, a waveband might need a start-of-waveband
> > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> >
> > Regards,
> >
> > Maarten
> >
> > Yuri Landry wrote:
> > >
> > > Mano,
> > >
> > > >            Can someone tell me the message structure of Label 
>Request and
> > > >Label Mapping in GMPLS ?
> > > >I am confused about the presence of LightPath Id in O-UNI messages 
>and LSP
> > > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids 
>or Is
> > > >it like that both lightPath Id and LSP Id will be carried in GMPLS 
>messages
> > > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be 
>mapped
> > > >to
> > > >multiple LSP Ids or vice versa ?
> > >
> > > I think you mean Connection ID and LSP ID. A connection ID is an ID 
>for
> > > network connection, which may consist many LSPs. For example, the 
>virtual
> > > concatenation case.
> > >
> > > A LSP may tunnel through multiple pre-established connections.
> > >
> > > >Also, for waveband switching, the genralized label has the format
> > > >(wavebandId - start label - end label).
> > > >When the label request message is received on incoming interface, how 
>to
> > > >identify that the waveband label is requested ?
> > > >Is it the LSP encoding type or some other parameter in label request
> > > >message
> > > >? If it is the Lambda encoding type then how to identify that whether 
>a
> > > >lambda or waveband label is requested ?
> > > >
> > > >Also, it is mentioned that wavebandId (32 bits) is selected by the 
>sender
> > > >and reused in all the subsequent messages. What all subsequent
> > > >messages is it mentioning to ?
> > > >
> > > >Can wavebandId be present in Label Withdraw/Release messages ?
> > > >
> > > >I am not able to workout the message structures for GMPLS.
> > > >
> > >
> > > To me waveband label defined in GMPLS drafts is a joke. The reason to 
>have
> > > the waveband label is that someone claimed that the waveband's order 
>might
> > > flip when going through a switch. My suggestion is don't take it 
>seriously.
> > >
> > > >I am not sure how these drafts are at last call. Atleast it should 
>mention
> > > >the message structures of various messages.
> > > >
> > >
> > > Agree.
> > >
> > > Regards,
> > >
> > > Yuri
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
><< mvissers.vcf >>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Tue, 22 May 2001 07:37:51 -0700
From: "Mannie, Eric" <[email-masked]>
To: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Status of the GMPLS extensions for SONET and SDH control draft
Date: Tue, 22 May 2001 16:36:50 +0200

Dear all,

The GMPLS extensions for SONET and SDH control are discussed since 1.5 years
by a large set of people, we had a large number of meetings at each IETF and
even during OIF. The draft itself has 30 co-authors from 16 companies. The
signaling was presented at several IETF meetings, published in various
releases of internet drafts, presented in conferences, used as a basis for
the OIF UNI, and is currently in WG last call.

For each feature we had to debate about its meaning, its use, its
applicability, etc. It is certainly not about one or two vendors that wanted
to have a proprietary feature. This signaling also represents our vision of
what we could do in the future with SDH/SONET and GMPLS, we tried to include
several ideas that, from our point of view, could be beneficial for many.

This draft speaks only about SDH/SONET SERVICES and their relevant features.
We discussed only a few services and we agreed to keep others for further
study, e.g. LCAS, control of other SDH multiplex structures, etc. We
focussed on a very few services that seems sufficiently important to be
included first: concatenation and transparency. The proof that these
services are of importance is the amount of additional debate that we had
during the last few weeks thanks to the WG last call process.

There is up to now no reason to consider transparency and concatenation as
being proprietary extensions given the support that these features had from
the community. They are implemented/being implemented by many and they are
clearly useful. Note in addition that virtual and contiguous concatenation
are an integral part of the SDH/SONET standards. Arbitrary and flexible
concatenations are behaviours using the current SDH/SONET toolbox.

There was a lot of discussion on IETF and ITU-T mailing lists about the need
of each particular type  of concatenation and there was no consensus that we
should restrict our scope to one in particular. There are different needs
and different usages. Today IP routers use almost exclusively contiguous
concatenations, Ethernet devices use mainly virtual concatenation, arbitrary
concatenation gives much more flexibility (and is used) and flexible
concatenation allows a local optimization needed because we will have
dynamic circuits. Each type has its own usage and its own applicability
field. It does not mean that somebody must implement all of them of course.

The issue that was raised during this working group last call process up to
now is relative to the flexible concatenation. Somehow this was included in
some previous versions of the draft but not fully understood by everybody.
It disappeared completely during some editing, I am guilty. We proposed a
text to clarify it and we had no negative answer about the technical content
of the text up to now (this text is re-included hereafter).

Simply a few people argued that we need new ITU-T standards to support these
features, that everything that is not described in G.707 is proprietary, and
that we are redefining SDH/SONET standards.

We are indeed defining some particular behaviours on the top of the
standardized SDH/SONET, but we are not redefining anything in the SDH/SONET
standards. These behaviours are new, some have limitations, but we think
that they are all valuable and useful. I understand that people that
discovered this work for the first time had problems to understand its
scope.

I received no technical comment about the draft with the new proposed
extension for flexible concatenation (included again hereafter). Please, I
will appreciate if you could send comments if you see any technical problem.

We are also still waiting to know what are the missing standards that are
needed to implement these features in the context that is described in Annex
2 of this e-mail, we had no answer today.

Thanks to help us.

Kind regards,

Eric

---------------------------------------------
ANNEX 1
---------------------------------------------

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

-----------------------------------------------------------------------
Annex 2: about the service's features that we are talking about:
-----------------------------------------------------------------------

1) SDH/SONET features that need an additional standard to be able to
interoperate:
----------------------------------------------------------------------------
------

In that case this is not at all in the scope of the IETF of course. I never
heard anybody at the IETF proposing to do SDH/SONET standards, it does not
make sense of course. The IETF management was *very* clear about that. It is
well understood and agreed.

2) SDH/SONET features that don't need any new SDH/SONET standard:
-----------------------------------------------------------------

Let's speak about three important features:

About arbitrary contiguous concatenation:
----------------------------------------

Arbitrary contiguous concatenation (as described it in the proposed text)
don't need any standard, it is just a way to use SDH/SONET. It is already
implemented since a while by many manufacturers in legacy equipment's. In
that case there is NO reason why we should not define features to control it
in the GMPLS signaling. It is not because it is not described in G.707 that
we cannot do it, or that it doesn't work.

About transparency:
-------------------

Transparency at the GMPLS UNI does not require any SDH/SONET standard
because it is not implemented at the UNI, it is 100% about signaling. We
never said that GMPLS must be used at both the UNI and NNI. The NNI could be
in a proprietary cloud of a single manufacturer. So, there is no reason to
remove it from the GMPLS signaling.

If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
at the NNI between two manufacturers needs an agreement to interoperate.
This agreement can be achieved in very different ways: through the use of a
standard, an implementation agreement made by a forum, or an implementation
agreement between two manufacturers (e.g. at the request of an operator).

ITU-T, T1X1, ETSI or OIF could produce such an agreement. At the last OIF
there was a session dedicated to transparency. We can expect to see more
contributions at the next OIF meeting. Some contributions could also be
presented to T1X1. Anyway, that's not the business of IETF and has nothing
to do with transparency in the GMPLS signaling at the UNI.

About flexible arbitrary contiguous concatenation:
--------------------------------------------------

What is the additional standard that we need to support flexible arbitrary
contiguous concatenation. Could someone describe what should be standardized
and why two implementations could not interoperate ?

The GMPLS signaling allows to know the type, the number, the order, and the
position of all components. Flexible arbitrary contiguous concatenation in
GMPLS is only an indication send to the downstream node that it could use
this feature. The upstream node doesn't request it, it simply says to the
downstream node that it supports it. The downstream node can either decide
to ignore it and use a standard contiguous concatenation, or an arbitrary
contiguous concatenation; or it could refuse the connection request. This is
a local optimization to deal with local external fragmentation of the
multiplex that will happen if one route very dynamic demands. There is for
sure absolutely no interoperability issue between nodes that implement it
and nodes that doesn't implement it because it is not used in that case :-)

Delivery-date: Tue, 22 May 2001 07:05:06 -0700
From: [email-masked]
To: [email-masked]
Subject: FW: Proposed text for the concatenation
Date: Tue, 22 May 2001 14:53:47 +0100

Eric,

>From an operators perspective, I am very concerned at the proposal for
arbitrary concatenation. It does nothing that virtual concatenation cannot
achieve (in fact less, as it does not support random time slot assignment
capability), and involves the upgrade of every network element it traverses
(virtual only requires support in the terminating devices).

The further addition of flexible arbitrary confuses matters still further
where a contiguous to virtual conversion is already fully defined.

The proposal is technically inferior to the already defined and existing
techniques, and is unlikely to receive a warm welcome if bought to the ITU.
Could the contributors to this technique explain why we need to define
another Ford when we already have a Ferrari?

Regards

	Tony Flavin

	BTexact.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: 18 May 2001 21:28
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

	

Delivery-date: Tue, 22 May 2001 03:39:00 -0700
Cc: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Date: Tue, 22 May 2001 12:34:02 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
Original-CC: [email-masked], [email-masked], q11/15 <[email-masked]>, "t1x1.5" <[email-masked]>
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------A970830C09ED8B9891595A61
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dimitri, Eric,

When one or two vendors or one or two operators would like to support a
particular feature in their equipment/network, it doesn't imply that
there is general agreement to add such feature in to the standard. Only
those features for which interworking is agreed end up in the standard.
Some of the others may find its way into an informative annex/appendix
in the standard, clearly marked as such to stress that you can not
expect network support for this feature, nor interworking. Many other
features do not make it at all into the standard in the absence of
sufficient support; those are completely rejected.

This process is present in any standards body as far as I can see,
including the IETF. Many proposals in IETF are rejected, like in other
standards bodies.

At this moment we argue about features to be supported by the control
plane for the automatic switched optical network (consisting of
SDH/SONET, WDM/pre-OTN and OTN networks) for which specifications the
ITU-T and T1X1.5 are responsible. Any issues are to be addressed by
these standards bodies. 
Those organisations not being a member of ITU-T can address their issue
in T1X1.5, and if support is obtained members of T1X1.5 being also a
member of ITU-T can/will then forward this issue to ITU-T for world wide
consideration.

For the case a new feature (idea) is developed for the transport plane,
any organisation (vendor, operator) can contribute this to ITU-T and/or
T1X1.5 to seek support, and to make it part of the standard. If this
isn't done, the feature seems to be unimportant for standardisation (and
thus interworking). For this case, there is no rationale to add control
plane functionality for this feature to the transport plane's control
plane specification; standard transport plane UNIs and NNIs are not
supporting this feature, so why would the associated standard control
plane UNI/NNI support it.

This doesn't imply that the feature is not developed; the feature is
developed as a proprietary extension of the transport plane, control
plane and management plane standards. Many vendors and operators offer,
require and operate proprietary features today, and (most likely) will
continue to do so in the future.

The IETF is extending the control plane definitions of MPLS with optical
network specific constructs to be able to use this extended control
plane specification as part of the automatic swithced optical network.
As part of this work, vendors have requested control plane extensions to
support their proprietary transport plane features. In order to do so,
these proprietary transport plane features had to be defined to some
level of detail in the control plane specification... otherwise nobody
understood what was controlled. And what a marvelous interactions we
have seen in the last few weeks on these transport plane specifications
of concatenation, transparency and adaptive pointer processing modes
(AUG/STSG/TUG/VTG)... :-( .  This clearly showed that these issues are
all but control plane issues; these are transport plane issues and are
outside the charter of GMPLS (and IETF).

As all standards bodies progress their work by means of received
contributions, it is peculiar to read in messages from people active
within the IP standard body (i.e. IETF) that the transport plane
standards bodies (i.e. ITU-T and T1X1.5) are not adequately reacting to
the needs of the transport plane. Where were their contributions to the
transport plane standards bodies ...?
And the following message from IETF to ITU-T will no doubt be received
with open arms :-( : "i propose here to postpone the edition of this
G.783 document in order to include the needed changes in order to
synchronize the ITU-T specification with the last GMPLS SDH/Sonet
document version (Ed. Eric Mannie) which has demonstrated that current
ITU-T standards clearly don't cover some specific functions like
flexible ACC". WOW... can we ever be more respectful and friendly...?

Regards,

Maarten
--------------A970830C09ED8B9891595A61
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------A970830C09ED8B9891595A61--

Delivery-date: Tue, 22 May 2001 01:35:35 -0700
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 22 May 2001 10:34:44 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked], [email-masked]
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: ASTN Layer Network Architecture

This is a multi-part message in MIME format.
--------------0BCF4763FAAEF7DE7CD0838E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To illustrate the multi layer aspects of the transport network and the
interactions between control plane (instance)s in an automatic switched
transport network, I created the following correspondence document:

http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-multi-cp.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-multi-cp.pdf

Regards,

Maarten
PS. ITU-T has promised to create an open area in which documents can be
placed with world wide read access. I am checking if this open area is
now available, so I can upload the above document into it as well. If
not available I will upload the document to T1X1.5 ftp server.
--------------0BCF4763FAAEF7DE7CD0838E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------0BCF4763FAAEF7DE7CD0838E--

Delivery-date: Mon, 21 May 2001 23:59:12 -0700
To: Yuri Landry <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Tue, 22 May 2001 08:58:07 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: Yuri Landry <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Waveband definition [was: GMPLS Message Structures]

This is a multi-part message in MIME format.
--------------3BEC16384AFE27EAF03A7358
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj, Yuri,

I received a message that my definition of waveband is too restricted. 

A waveband should be an optical multiplex, administered as a single
bundle, not necessary contiguous in frequency slot.

	E.g. there may be good technical reasons to consider a
	'waveband' created at an OADM formed by taking every 2nd
	wavelength in a 50GHz-spaced transmission band.

In first instance the above definition may not be considered this as a
"band"; it
looks more like a "gapped-band" :-). Nevertheless, due to technical
reasons we should consider a waveband as just another name for a
particular group of wavelengths, which may best be viewed as a group of
identified/listed wavelengths. 

Regards,

Maarten

Maarten Vissers wrote:
> 
> Manoj, Yuri,
> 
> In my current understanding, a waveband is a group of OCh (optical
> channel) signals located in a contiguous set of tributary (i.e.
> frequency) slots.
> 
> A waveband is therefore related to partitioning, rather than a layering.
> A waveband shouldn't have an LSP encoding type itself, but instead be
> part of the OCh layer network. E.g. a specific RGT (requested groupting
> type) of "contiguous waveband" can be defined for this purpose with the
> RNC (requested number of components) indicating the size of the
> waveband.
> 
> The above is simply a first shot; in general the issue can be more
> complex due to the fact that the frequency slot for a 2G5, a 10G and a
> 40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
> 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
> 100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
> optimized freq. slot widths, a waveband might need a start-of-waveband
> and end-of-waveband (SOW-EOW) indication, instead of RNC.
> 
> Regards,
> 
> Maarten
> 
> Yuri Landry wrote:
> >
> > Mano,
> >
> > >            Can someone tell me the message structure of Label Request and
> > >Label Mapping in GMPLS ?
> > >I am confused about the presence of LightPath Id in O-UNI messages and LSP
> > >Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
> > >it like that both lightPath Id and LSP Id will be carried in GMPLS messages
> > >? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped
> > >to
> > >multiple LSP Ids or vice versa ?
> >
> > I think you mean Connection ID and LSP ID. A connection ID is an ID for
> > network connection, which may consist many LSPs. For example, the virtual
> > concatenation case.
> >
> > A LSP may tunnel through multiple pre-established connections.
> >
> > >Also, for waveband switching, the genralized label has the format
> > >(wavebandId - start label - end label).
> > >When the label request message is received on incoming interface, how to
> > >identify that the waveband label is requested ?
> > >Is it the LSP encoding type or some other parameter in label request
> > >message
> > >? If it is the Lambda encoding type then how to identify that whether a
> > >lambda or waveband label is requested ?
> > >
> > >Also, it is mentioned that wavebandId (32 bits) is selected by the sender
> > >and reused in all the subsequent messages. What all subsequent
> > >messages is it mentioning to ?
> > >
> > >Can wavebandId be present in Label Withdraw/Release messages ?
> > >
> > >I am not able to workout the message structures for GMPLS.
> > >
> >
> > To me waveband label defined in GMPLS drafts is a joke. The reason to have
> > the waveband label is that someone claimed that the waveband's order might
> > flip when going through a switch. My suggestion is don't take it seriously.
> >
> > >I am not sure how these drafts are at last call. Atleast it should mention
> > >the message structures of various messages.
> > >
> >
> > Agree.
> >
> > Regards,
> >
> > Yuri
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------3BEC16384AFE27EAF03A7358
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3BEC16384AFE27EAF03A7358--

Delivery-date: Mon, 21 May 2001 20:41:30 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 20:40:43 -0700

If the goal is interoperability,  it seems like we are getting very
concerned with things that don't matter to that goal.  I'd like to have the
signaling take in all the cases we've discussed, and where there are areas
that the existing standards don't cover (or may not want to cover) we should
define what we mean precisely, state that it is non-standard.
As Lyndon Ong pointed out if multiple vendors don't interoperate with this
feature it will be dropped from the internet standard.
As someone already pointed out, if a customer is willing to pay for a
feature we will supply it.  I'm not sure why we wouldn't want to be able to
interoperate with that feature and for the purpose here we need to describe
what it is in a signaling protocol. Regardless of its current status as a
standard or industry practice.

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Tuesday, May 22, 2001 3:39 AM
To: 'Maarten Vissers'
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Re-hello Maarten,

>I have been asking for this AUG-X addition.....
>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all. The STSG-X has been made a signal type by my company
>some years ago to support the requirements of some specific customers.

Whaoum, you implemented a non-standardized feature and you re-defined
SDH/SONET in your equipment without the permission of ITU-T :-)

I think that this feature make a lot of sense, you are not the only one that
requested it. In a similar way, other folks requested TUG-X/VTG and this
complements very well your initial request. Moreover, these signal types are
of paramount importance for GMPLS operations since they allow to open a
forwarding adjacency (i.e. an SDH/SONET circuit for which you don't specify
the content) that can be later on sub-structured in whatever you like
(following the SDH/SONET rules of course).

By the way, I don't understand why you said that you need a standard for
AUG-X/STSG-X, TUG-X/VTG...

THERE IS ABSOLUTELY NO NEW STANDARD REQUIRED FOR THAT !

It does not change ANYTHING to SDH/SONET in the data/forwarding plane. It
stays 100% PURE SDH/SONET as in the standards. It is purely a signaling
feature. In addition, even the terminology (AUG-X) is defined in the
standards.

So the only issue that I see is that you don't want to have it because you
can control it by a control plane (whatever is the control plane ???).

>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all.

"Signal type" is not a G.707 vocabulary, we used that vocabulary for GMPLS
signaling. Even VC-4's, VC-3's, etc are not defined as a signal type. So do
you want to say that we cannot neither open a VC-4 circuit because G.707 did
not define the GMPLS concept of signal type ? That doesn't make any sense !

Moreover, AUG-X, TUG-2 and TUG-3 ARE DEFINED in G.707 of course (that's part
of the fundamental specification).

>....I don't want to have
>my requested feature treated any different than any other feature that I
>have been argueing about (arbitrary concatenation, semi-transparent
>STM-N).

Are we playing a game here ???

>As this AUG-X feature is beyond current standards (in this case
>G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
>series of control plane specifications.

Great, the own ITU-T functional description is not aligned to its own
protocol ! So it means that SDH does not work ! Seriously, who cares ?
Protocols are implemented not functional descriptions that helps to
understand protocols. I am sure that G.783 will be updated very soon to
reflect SDH.

Sorry I am lost, what is the goal of all your e-mails ? What do you want to
achieve ?

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, May 21, 2001 4:28 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,

I am serious. (See also my reply to Greg.)

You wrote:
> Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
TUG-X/VTG,
> they are defined in the standards, it is just a code type, like VC-4 or
> STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

I have been asking for this AUG-X addition, with the assumption that I
would write a contribution to get G.783 extended with an additional
MSn/Sn_A function supporting this AUG-X feature... You find this once
more reflected in my email to Greg this morning.

AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
standards at all. The STSG-X has been made a signal type by my company
some years ago to support the requirements of some specific customers.
It's proprietary so far.

But given the result of the discussions last week, I don't want to have
my requested feature treated any different than any other feature that I
have been argueing about (arbitrary concatenation, semi-transparent
STM-N). As this AUG-X feature is beyond current standards (in this case
G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
series of control plane specifications.
Up to that moment in time, it should be a vendor specific extension of
G.ason/GMPLS.

Regards,

Maarten

Delivery-date: Mon, 21 May 2001 20:22:00 -0700
From: "Bernstein, Greg" <[email-masked]>
To: Maarten Vissers <[email-masked]>
Cc: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>, Anup Tirumala <[email-masked]>,  [email-masked], [email-masked], [email-masked],  "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Mon, 21 May 2001 20:20:57 -0700

Hi Maarten,
Some of this sounds like a conversation I had with Suresh Katukam
(Cerent/Cisco) quite some time ago.
Here were the essential points:
(1)Virtual Concatenation is between end systems.  And information concerning
virtual concatenation needs be conveyed between end systems.  For example
multiple virtually concatenated connections to the same end point need to be
distinquished from each other (Note that the sequence numbering of the
components in contained in the SONET path overhead H4 with that niffty
multi-frame technique). George Swallow suggested which fields we should use
for this but of course I forgot to write it down.
(2)Standard Concatenation is something that all intermediate systems need to
know about, i.e., can they support it and also because they need to do
something about it.
(3) Using arbitrary concatenation on standard concatenation sized signals is
a local property between two adjacient boxes.
(4) Using arbitrary concatenation with "odd sized" signals is something that
needs to be signaled to every intermediate node.

Now for to use (3) I need to give a list of time slots.
So included in the specification is a mix of information: end system, local,
and needed by all intermediate nodes. 

Greg B.
***********************************
Dr. Greg M. Bernstein
Senior Scientist, Ciena Corporation 

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 2:14 PM
To: Bernstein, Greg
Cc: 'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in
sonet/sdh

Greg,

I got the impression that there was some misunderstanding with respect
to your 2nd alternative. The "link" you refer to is (if my understanding
is correct) e.g. the connection between two adjacent SONET/SDH (cross
connect) equipments; e.g. a transoceanic connection.

If you do not want to have the need to ever perform bandwidth
defragmentation on this "link", arbitrary concatenation support in the
STM-N/OC-N line ports facing the transoceanic cable is the only
alternative in my opinion. Virtual concatenation is not intended to
support this requirement.

As I wrote in an earlier email this evening (at least in this timezone),
arbitrary concatenation used in this application can be treated similar
to standard contiguous concatenation, if the igress signals are only
standard contiguous concatenated signals and the basic signals (STS1,
VC-4). The transoceanic HOVC/STS link will simply have less "blocking".
In this application there is no need to reflect any arbitrary
concatenation capability in the signalling.

If you however want to have the SONET/SDH network support interworking
of STS-Xa and VC-4-Xa signals for other values of X than the contiguous
concatenated ones, the signalling specifications need to reflect the
arbitrary concatenated capabilities.

But to prevent inconsistency between transport plane and control plane
standards, either both standards need to include arbitrary concatenation
or have it both not included.

For the case the agreement in the transport plane standardisation is to
extend the current SONET/SDH networks with interworking capabilities for
STS-Xa (X=1..N) and VC-4-Xa (X=1..N) signals, the development of a
complete set of STS-Xa and VC-4-Xa requirements can be generated; e.g.
including 
- STS-Xa/VC-4-Xa with LCAS to allow hitless capacity adjustment to be
supported,
- addition of multiplex structure identifier in the MSOH/LOH to support
AUG-X/STSG-X,
- payload mapping specifications
- virtual concatenation/arbitrary concatenation interworking functions
- etc.

Regards,

Maarten

"Bernstein, Greg" wrote:
> 
> Are we having fun for a Thursday, or what?
> Zhi, had me convinced that I should do a "start up" specializing in
virtual
> concatenation for link bandwidth optimization, then Monica asked me about
> overhead use in arbitrary concatenation...
> Here are some more points:
> (1)     Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE
equipment
> and has nice consequences for avoiding re-grooming.
> (2)     Virtual concatenation is a whole new and useful feature that uses
> path level overhead, in particular the H4 byte.  Hence the path level BIP
B3
> needs to recalculated.  This is more a PTE (path termination equipment)
kind
> of thing to do.  Not something that a typical switch would necessarily
want
> to do for compatibility purposes. This was intended for a much more
> sophisticated application, i.e., a path level "bonding" or inverse
> multiplexing, but it lacks path level transparency if used to avoid
> regrooming.
> 
> Hope this puts some more gasoline (petrol) onto the fire.
> 
> Greg B.
> 
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Lazer, Monica A, NNAD [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 11:01 AM
>                 To:     Bernstein, Greg; 'Zhi-Wei Lin'
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        RE: [T1X1.5] RE: [IP-Optical]
concatenation
> extensions in sonet/s dh
> 
>                 Why wouldn't the 2 boxes in option 2 use virtual
> concatenation instead of
>                 arbitrary concatenation, though?
> 
>                 Monica A. Lazer
>                 Advanced Transport Technology and Architecture Planning
> 
>                 908 234 8462
>                 [email-masked]
> 
>                 -----Original Message-----
>                 From: Bernstein, Greg [mailto:[email-masked]]
>                 Sent: Thursday, May 17, 2001 12:27 PM
>                 To: 'Zhi-Wei Lin'
>                 Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
>                 [email-masked]; [email-masked];
t1x1.5;
> q11/15
>                 Subject: [T1X1.5] RE: [IP-Optical] concatenation
extensions
> in sonet/sdh
> 
>                 To avoid re-grooming either virtual concatenation or
> arbitrary concatenation
>                 can help, but the implications are quite different.
>                 Say we have a particularly valuable (expensive) link that
we
> can't or don't
>                 want to re-groom then we have two options:
>                 (1)     Require that ALL end systems that could
potentially
> use this link
>                 convert over to virtual concatenation from standard
> concatenation.
>                 (2)     Or, install boxes at both ends of the link that
> support the
>                 arbitrary concatenation that we've been discussing.
> 
>                 Which of these seems more realistic and practical?
>                 Greg B.
>                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                         New phone: (510) 573-2237
> 
>                                 -----Original Message-----
>                                 From:   Zhi-Wei Lin
> [mailto:[email-masked]]
>                                 Sent:   Thursday, May 17, 2001 8:41 AM
>                                 To:     Bernstein, Greg
>                                 Cc:     'Maarten Vissers'; Anup Tirumala;
>                 [email-masked]; [email-masked];
> [email-masked];
>                 t1x1.5; q11/15
>                                 Subject:        Re: [IP-Optical]
> concatenation extensions in
>                 sonet/sdh
> 
>                                 Hi,
> 
>                                 some observations:
> 
>                                 in terms of re-grooming and such, I
believe
> both virtual
>                 concatenation
>                                 and arbitrary concatenation can perform
> this. One method is
>                                 standardized, the other is proprietary.
> 
>                                 In terms of routing of the individual
> connections that make
>                 up the
>                                 concatenated signal, virtual concatenation
> is more flexible
>                 than
>                                 arbitrary concatenation, since you can put
> each component VC
>                 in
>                                 different lines, and each component can be
> routed
>                 differently.
> 
>                                 In terms of interworking, yes the
SIGNALLING
> can defnititely
>                 be made to
>                                 interwork. However, the larger issue for
> interworking is
>                 support by the
>                                 transport equipment themselves. Thus
> interworking involves
>                 TWO parts:
>                                 signaling interworking and transport
> interworking. Having
>                 one without
>                                 the other doesn't really help...
> 
>                                 Thus, in terms of solving real problems,
> either virtual or
>                 arbitrary can
>                                 accomplish that, but IMO, virtual seems
more
> flexible...and
>                                 standardized...
> 
>                                 In terms of standards as fostering
> interoperability and
>                 stifling of
>                                 innovation, in principle yes I agree. And
> therefore if
>                 arbitrary
>                                 concatenation should be standardized, it
> should be
>                 standardized in the
>                                 correct standards body. As Maarten
> mentioned, the relevant
>                 standards
>                                 bodies discussed arbitrary concatenation
> years ago, and
>                 decided
>                                 (hopefully based on their expert technical
> opinion - I
>                 wasn't involved)
>                                 not to include arbitrary but instead to
> include virtual.
>                 IMO, there must
>                                 be good reasons, and from what I can tell,
I
> see virtual as
>                 been more
>                                 flexible so that is a pretty good
> reason...we at IETF, being
>                 protocol
>                                 experts (and budding transport experts?)
> should not try to
>                 second-guess
>                                 the decisions without fully understanding
> the
>                 ramifications...
> 
>                                 As for stifling innovation, anytime you
> standardize anything
>                 there is
>                                 always some factor of development that
gets
> fixed (is this
>                 something
>                                 that should not be said in a public
forum???
> -- sorry!!).
>                 Therefore
>                                 there is always a tradeoff between
> innovation and
>                 standardization. I
>                                 think the job of standards bodies is to
try
> to balance these
>                 two factors
>                                 such that the industry in general can live
> with the result
>                 without
>                                 unduly burdening...
> 
>                                 agree?
> 
>                                 Zhi
> 
>                                 "Bernstein, Greg" wrote:
>                                 >
>                                 > A couple more points.
>                                 > (1)     GMPLS works well with arbitrary
> concatenations
>                 need to specify the
>                                 > time slots since it provides a signaling
> protocol that can
>                 do just that,
>                                 > i.e., GMPLS actually enables this
feature
> to interoperate.
>                                 > (2)     Arbitrary concatenation offers a
> solution to a
>                 real problem, i.e.,
>                                 > eliminates the need for re-grooming on
> lines that support
>                 it.  For those who
>                                 > have invested non-trivial amounts of
money
> in transoceanic
>                 links this can be
>                                 > a significant savings.
>                                 > (3)     The goal is interoperability and
> to solve real
>                 problems.  We've got
>                                 > a real problem and with a minor edit to
> the GMPLS SONET
>                 specification we can
>                                 > have an interoperable method for solving
> it.
>                                 >
>                                 > To be precise in the definition of
> arbitrary
>                 concatenation:
>                                 > As a concatenated signal within a single
> SONET Line (SDH
>                 MS), with
>                                 > potentially arbitrary timeslots used for
> its components.
>                                 >
>                                 > The current main application is:
avoiding
> the need for
>                 service impacting
>                                 > re-grooming. Note that this applies to
> standard sized
>                 signals and is a per
>                                 > link property.
>                                 >
>                                 > Other applications do exist and are
> somewhat competitive
>                 with non-LCAS
>                                 > virtual concatenation since the
> implementation of
>                 arbitrary concatenation
>                                 > for odd sized signals is simpler than
that
> of virtual
>                 concatenation.  Once
>                                 > "odd" sized signals are used an entire
> path through the
>                 network must exist
>                                 > that supports them.
>                                 >
>                                 > Folks I thought the role of standards
> organizations was to
>                 foster
>                                 > interoperability that enables the
industry
> to move forward
>                 rather than as a
>                                 > means to stifle innovation. I think it
is
> better for the
>                 marketplace to
>                                 > decide which features are desirable.
>                                 >
>                                 > Greg B.
>                                 >
>                                 >         Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
>                                 >         New phone: (510) 573-2237
>                                 >

Delivery-date: Mon, 21 May 2001 20:21:57 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "Mannie, Eric" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 20:20:41 -0700

The text looks good Eric.  I'm happy to help with any text to make the
definition of arbitrary flexible concatenation clearer. 

Greg B.

-----Original Message-----
From: Mannie, Eric [mailto:[email-masked]]
Sent: Friday, May 18, 2001 1:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

	

Delivery-date: Mon, 21 May 2001 18:29:37 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Mak, L (Leen)'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Mon, 21 May 2001 21:30:30 -0400

Folks,

Without getting into the merits of arbit concat,
the suggestion that the GMPLS document be explicit about
the "standard" (ITU) versus "pre" or "non-standard" 
features controlled seems reasonable. Afterall,
when you name the doc "GMPLS for SONET/SDH", the
natural expectation is that you refer to what people
commonly understand as "SONET/SDH". In any case,
a precise description of the new features 
and a notation that these are not
currently "standard"  isn't a big deal to do. 
On the other hand, not doing so just breeds confusion.

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Mak, L (Leen) [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 5:42 AM
> To: 'Zhi-Wei Lin'; Paul Bonenfant
> Cc: 'Bernstein, Greg'; 'Steve West'; 'Stephen Trowbridge';
> [email-masked]; [email-masked]; t1x1.5; 
> q11/15; Mak,
> L (Leen)
> Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> 
> 
> I think Zhi brings us back to the question which started
> this debate in the first place.
> I would support Zhi's option 4).
> 
> That is, in the IETF doc(s), make a clear distinction between
> the stuff supporting currently standardised SONET/SDH
> transport capabilities and the stuff aimed at possible future 
> extensions. The latter could be in an informational Annex 
> or alike, and once ITU and/or T1 standardise a new 
> transport capability, its related control stuff can easily be 
> moved from the Annex to the body of the RFC.
> 
> We should avoid blurring the roles of the various standards 
> bodies. This is not in the interest of the operators nor in 
> the interest of the vendors, because spreading subjects 
> over more bodies will only increase the risk of 
> inconsistencies, misunderstandings etc, etc.
> 
> So ITU-T and T1X1 should remain the bodies where 
> SONET/SDH transport capabilities are being proposed,
> discussed, and standardised.
> The IETF should remain the body where the GMPLS
> capabilities, required to control those transport capabilities
> are standardised. 
> Their relation should be: "the transport capability gets
> the control capability it needs", and not the other way
> around. 
> 
> 
> Leen Mak.
> 
> 
> 
> > -----Original Message-----
> > From: Zhi-Wei Lin [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 1:46
> >[...]
> > As for transparency and the rest, right. So as you said, the 
> > question we
> > should ask ourselves is:
> > 
> > 1) Should we add extensions to GMPLS for capabilities not 
> standardized
> > 2) Should we pre-empt standards and add capabilities that 
> are not yet
> > standardized
> > 3) If 2) is yes, should we add capabilities that we "think" will be
> > standardized. What about capabilities where we have no opinion or we
> > think will not be standardized (folks, bring out your crystal ball!)
> > 4) Should we stick strictly with standards-compliant 
> capabilities and
> > include extensions to allow ease of extending the 
> signalling mechanism
> > (Deborah's point). Add these in the future once it is standardized.
> > 
> >[..]
> > Zhi
> 

Delivery-date: Mon, 21 May 2001 12:52:30 -0700
Date: Mon, 21 May 2001 21:50:10 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "'Maarten Vissers'" <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------E203D397333AE68BF0CA4725
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

It is clear for me and when comparing the April 2000 version
of G.707 and what we have today in the GMPLS document it is
aligned (for instance AUG-X are included in the section 6.2.3 
Administrative Units in the STM-N of the last version) but
nevertheless in the last corrigendum that i receive on G.783
(March 2000) and living list it has not been done so... Since
the October 2000 version of the document is to be published
(not available at the ITU-T side), i propose here to postpone
the edition of this G.783 document in order to include the 
needed changes in order to synchronize the ITU-T specification
with the last GMPLS SDH/Sonet document version (Ed. Eric Mannie)
which has demonstrated that current ITU-T standards clearly don't
cover some specific functions like flexible ACC. Therefore the 
update must be done independently ... i mean whether GMPLS is 
there or not !!!

What do you think about ?

Regards,
- Dimitri.

"Mannie, Eric" wrote:
> 
> Re-hello Maarten,
> 
> >I have been asking for this AUG-X addition.....
> >AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
> >standards at all. The STSG-X has been made a signal type by my company
> >some years ago to support the requirements of some specific customers.
> 
> Whaoum, you implemented a non-standardized feature and you re-defined
> SDH/SONET in your equipment without the permission of ITU-T :-)
> 
> I think that this feature make a lot of sense, you are not the only one that
> requested it. In a similar way, other folks requested TUG-X/VTG and this
> complements very well your initial request. Moreover, these signal types are
> of paramount importance for GMPLS operations since they allow to open a
> forwarding adjacency (i.e. an SDH/SONET circuit for which you don't specify
> the content) that can be later on sub-structured in whatever you like
> (following the SDH/SONET rules of course).
> 
> By the way, I don't understand why you said that you need a standard for
> AUG-X/STSG-X, TUG-X/VTG...
> 
> THERE IS ABSOLUTELY NO NEW STANDARD REQUIRED FOR THAT !
> 
> It does not change ANYTHING to SDH/SONET in the data/forwarding plane. It
> stays 100% PURE SDH/SONET as in the standards. It is purely a signaling
> feature. In addition, even the terminology (AUG-X) is defined in the
> standards.
> 
> So the only issue that I see is that you don't want to have it because you
> can control it by a control plane (whatever is the control plane ???).
> 
> >AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
> >standards at all.
> 
> "Signal type" is not a G.707 vocabulary, we used that vocabulary for GMPLS
> signaling. Even VC-4's, VC-3's, etc are not defined as a signal type. So do
> you want to say that we cannot neither open a VC-4 circuit because G.707 did
> not define the GMPLS concept of signal type ? That doesn't make any sense !
> 
> Moreover, AUG-X, TUG-2 and TUG-3 ARE DEFINED in G.707 of course (that's part
> of the fundamental specification).
> 
> >....I don't want to have
> >my requested feature treated any different than any other feature that I
> >have been argueing about (arbitrary concatenation, semi-transparent
> >STM-N).
> 
> Are we playing a game here ???
> 
> >As this AUG-X feature is beyond current standards (in this case
> >G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
> >series of control plane specifications.
> 
> Great, the own ITU-T functional description is not aligned to its own
> protocol ! So it means that SDH does not work ! Seriously, who cares ?
> Protocols are implemented not functional descriptions that helps to
> understand protocols. I am sure that G.783 will be updated very soon to
> reflect SDH.
> 
> Sorry I am lost, what is the goal of all your e-mails ? What do you want to
> achieve ?
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Monday, May 21, 2001 4:28 PM
> To: Mannie, Eric
> Cc: [email-masked]; [email-masked]
> Subject: Re: Proposed text for the concatenation
> 
> Eric,
> 
> I am serious. (See also my reply to Greg.)
> 
> You wrote:
> > Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
> TUG-X/VTG,
> > they are defined in the standards, it is just a code type, like VC-4 or
> > STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.
> 
> I have been asking for this AUG-X addition, with the assumption that I
> would write a contribution to get G.783 extended with an additional
> MSn/Sn_A function supporting this AUG-X feature... You find this once
> more reflected in my email to Greg this morning.
> 
> AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
> standards at all. The STSG-X has been made a signal type by my company
> some years ago to support the requirements of some specific customers.
> It's proprietary so far.
> 
> But given the result of the discussions last week, I don't want to have
> my requested feature treated any different than any other feature that I
> have been argueing about (arbitrary concatenation, semi-transparent
> STM-N). As this AUG-X feature is beyond current standards (in this case
> G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
> series of control plane specifications.
> Up to that moment in time, it should be a vendor specific extension of
> G.ason/GMPLS.
> 
> Regards,
> 
> Maarten
--------------E203D397333AE68BF0CA4725
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------E203D397333AE68BF0CA4725--

Delivery-date: Mon, 21 May 2001 11:40:08 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 20:38:32 +0200

Re-hello Maarten,

>I have been asking for this AUG-X addition.....
>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all. The STSG-X has been made a signal type by my company
>some years ago to support the requirements of some specific customers.

Whaoum, you implemented a non-standardized feature and you re-defined
SDH/SONET in your equipment without the permission of ITU-T :-)

I think that this feature make a lot of sense, you are not the only one that
requested it. In a similar way, other folks requested TUG-X/VTG and this
complements very well your initial request. Moreover, these signal types are
of paramount importance for GMPLS operations since they allow to open a
forwarding adjacency (i.e. an SDH/SONET circuit for which you don't specify
the content) that can be later on sub-structured in whatever you like
(following the SDH/SONET rules of course).

By the way, I don't understand why you said that you need a standard for
AUG-X/STSG-X, TUG-X/VTG...

THERE IS ABSOLUTELY NO NEW STANDARD REQUIRED FOR THAT !

It does not change ANYTHING to SDH/SONET in the data/forwarding plane. It
stays 100% PURE SDH/SONET as in the standards. It is purely a signaling
feature. In addition, even the terminology (AUG-X) is defined in the
standards.

So the only issue that I see is that you don't want to have it because you
can control it by a control plane (whatever is the control plane ???).

>AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
>standards at all.

"Signal type" is not a G.707 vocabulary, we used that vocabulary for GMPLS
signaling. Even VC-4's, VC-3's, etc are not defined as a signal type. So do
you want to say that we cannot neither open a VC-4 circuit because G.707 did
not define the GMPLS concept of signal type ? That doesn't make any sense !

Moreover, AUG-X, TUG-2 and TUG-3 ARE DEFINED in G.707 of course (that's part
of the fundamental specification).

>....I don't want to have
>my requested feature treated any different than any other feature that I
>have been argueing about (arbitrary concatenation, semi-transparent
>STM-N).

Are we playing a game here ???

>As this AUG-X feature is beyond current standards (in this case
>G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
>series of control plane specifications.

Great, the own ITU-T functional description is not aligned to its own
protocol ! So it means that SDH does not work ! Seriously, who cares ?
Protocols are implemented not functional descriptions that helps to
understand protocols. I am sure that G.783 will be updated very soon to
reflect SDH.

Sorry I am lost, what is the goal of all your e-mails ? What do you want to
achieve ?

Rgds,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Monday, May 21, 2001 4:28 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,

I am serious. (See also my reply to Greg.)

You wrote:
> Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
TUG-X/VTG,
> they are defined in the standards, it is just a code type, like VC-4 or
> STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

I have been asking for this AUG-X addition, with the assumption that I
would write a contribution to get G.783 extended with an additional
MSn/Sn_A function supporting this AUG-X feature... You find this once
more reflected in my email to Greg this morning.

AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
standards at all. The STSG-X has been made a signal type by my company
some years ago to support the requirements of some specific customers.
It's proprietary so far.

But given the result of the discussions last week, I don't want to have
my requested feature treated any different than any other feature that I
have been argueing about (arbitrary concatenation, semi-transparent
STM-N). As this AUG-X feature is beyond current standards (in this case
G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
series of control plane specifications.
Up to that moment in time, it should be a vendor specific extension of
G.ason/GMPLS.

Regards,

Maarten

Delivery-date: Mon, 21 May 2001 11:22:42 -0700
From: Paul Bonenfant <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [IP-Optical] Re: Proposed text for the concatenation
Date: Mon, 21 May 2001 14:21:17 -0400

Maarten,

Does support for provisioning a pre/non-standard feature
necessarily imply a re-definition of SONET/SDH?  As far as 
I can tell the authors (and I note that you are an author,
as are a few other familiar names from my ITU and T1X1 days!)
went to at least some lengths to explicitly dispel this notion. 

Philosophical discussions notwithstanding, carriers are asking 
for (i.e., will PURCHASE), and vendors from ASIC manufacturers 
to systems providers are building, what amounts to "non"-standard, 
(or perhaps more appropriately "pre"-standard) implementations of 
SONET/SDH in current and emerging equipment. Ignore this and the 
G.ason/GMPLS specs for SONET/SDH will be on the fast track to 
irrelevance. 

Why not just acknowledge that not every aspect of provisioning in 
the spec is "standard" (and note where this is the case), and, as 
Dmitri suggests, work the ITU/T1X1 SONET/SDH spec enhancements in 
parallel.  Then, if ITU or T1X1 rejects any of said enhancements, 
relegate their signaling to vendor proprietary extensions...this
is the converse of your proposal, but IMO will result in a much
more attractive first version of the GMPLS SONET/SDH draft.

Regards, 

Paul

-----Original Message-----
From: Dimitri Papadimitriou [mailto:[email-masked]]
Sent: Monday, May 21, 2001 1:02 PM
To: Maarten Vissers
Cc: Mannie, Eric; [email-masked]; [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

Maarten,

>From my side, i don't see any drawback or problem to collaborate
in order to extend G.783. Since the work can be done in parallel,
without any impact on GMPLS signalling, i don't see where the 
problem is with the today version of the SDH/Sonet GMPLS document.
I think that Eric summarized very well the current situation.

Kind regards,
- Dimitri.

Maarten Vissers wrote:
> 
> Eric,
> 
> I am serious. (See also my reply to Greg.)
> 
> You wrote:
> > Note that GMPLS doesn't do something strange about AUG-X/STSG-X,
TUG-X/VTG,
> > they are defined in the standards, it is just a code type, like VC-4 or
> > STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.
> 
> I have been asking for this AUG-X addition, with the assumption that I
> would write a contribution to get G.783 extended with an additional
> MSn/Sn_A function supporting this AUG-X feature... You find this once
> more reflected in my email to Greg this morning.
> 
> AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
> standards at all. The STSG-X has been made a signal type by my company
> some years ago to support the requirements of some specific customers.
> It's proprietary so far.
> 
> But given the result of the discussions last week, I don't want to have
> my requested feature treated any different than any other feature that I
> have been argueing about (arbitrary concatenation, semi-transparent
> STM-N). As this AUG-X feature is beyond current standards (in this case
> G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
> series of control plane specifications.
> Up to that moment in time, it should be a vendor specific extension of
> G.ason/GMPLS.
> 
> Regards,
> 
> Maarten

Delivery-date: Mon, 21 May 2001 10:03:29 -0700
Date: Mon, 21 May 2001 19:02:01 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Maarten Vissers <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [IP-Optical] Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------1E0294B6923932ABF0F3C633
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Maarten,

>From my side, i don't see any drawback or problem to collaborate
in order to extend G.783. Since the work can be done in parallel,
without any impact on GMPLS signalling, i don't see where the 
problem is with the today version of the SDH/Sonet GMPLS document.
I think that Eric summarized very well the current situation.

Kind regards,
- Dimitri.

Maarten Vissers wrote:
> 
> Eric,
> 
> I am serious. (See also my reply to Greg.)
> 
> You wrote:
> > Note that GMPLS doesn't do something strange about AUG-X/STSG-X, TUG-X/VTG,
> > they are defined in the standards, it is just a code type, like VC-4 or
> > STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.
> 
> I have been asking for this AUG-X addition, with the assumption that I
> would write a contribution to get G.783 extended with an additional
> MSn/Sn_A function supporting this AUG-X feature... You find this once
> more reflected in my email to Greg this morning.
> 
> AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
> standards at all. The STSG-X has been made a signal type by my company
> some years ago to support the requirements of some specific customers.
> It's proprietary so far.
> 
> But given the result of the discussions last week, I don't want to have
> my requested feature treated any different than any other feature that I
> have been argueing about (arbitrary concatenation, semi-transparent
> STM-N). As this AUG-X feature is beyond current standards (in this case
> G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
> series of control plane specifications.
> Up to that moment in time, it should be a vendor specific extension of
> G.ason/GMPLS.
> 
> Regards,
> 
> Maarten
--------------1E0294B6923932ABF0F3C633
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------1E0294B6923932ABF0F3C633--

Delivery-date: Mon, 21 May 2001 09:24:36 -0700
From: Nic Larkin <[email-masked]>
To: [email-masked]
Subject: Length field in Label ERO subobject
Date: Mon, 21 May 2001 17:23:50 +0100

Hi all,

I have a question about the RSVP Label ERO subobject defined in section 5 of
draft-ietf-mpls-generalized-rsvp-te-03.

In this subobject, the Length field is defined to be one byte in size.

>From draft-ietf-ccamp-gmpls-sonet-sdh-00, it seems that it would be possible
(albeit unlikely) for a virtually concatenated label for a high bandwidth
link (e.g. an OC192) to be greater than 255 bytes in size.  Such a label
could not be represented in the Label ERO subobject as it stands.

Have I got this right, and if so, are there any plans to fix this?

Regards,
Nic.

Nic Larkin
Network Convergence Group
Data Connection Ltd
Tel:   +44 20 8366 1177           Fax:   +44 20 8363 1533
Email: [email-masked]     Web:   http://www.dataconnection.com

Delivery-date: Mon, 21 May 2001 07:28:40 -0700
Cc: [email-masked], [email-masked]
Date: Mon, 21 May 2001 16:28:09 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
Original-CC: [email-masked], [email-masked]
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------3CBC631603B643B2BC9BA5C1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Eric,

I am serious. (See also my reply to Greg.)

You wrote:
> Note that GMPLS doesn't do something strange about AUG-X/STSG-X, TUG-X/VTG,
> they are defined in the standards, it is just a code type, like VC-4 or
> STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

I have been asking for this AUG-X addition, with the assumption that I
would write a contribution to get G.783 extended with an additional
MSn/Sn_A function supporting this AUG-X feature... You find this once
more reflected in my email to Greg this morning.

AUG-X/STSG-X, TUG-X/VTG are not defined as signal types in SDH/SONET
standards at all. The STSG-X has been made a signal type by my company
some years ago to support the requirements of some specific customers.
It's proprietary so far.

But given the result of the discussions last week, I don't want to have
my requested feature treated any different than any other feature that I
have been argueing about (arbitrary concatenation, semi-transparent
STM-N). As this AUG-X feature is beyond current standards (in this case
G.783), it should be first addressed by Q.9/15 and then by G.ason/GMPLS
series of control plane specifications.
Up to that moment in time, it should be a vendor specific extension of
G.ason/GMPLS.

Regards,

Maarten
--------------3CBC631603B643B2BC9BA5C1
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------3CBC631603B643B2BC9BA5C1--

Delivery-date: Mon, 21 May 2001 06:59:57 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Lyndon Ong <[email-masked]>
Cc: Jonathan Lang <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 15:57:19 +0200

Maarten,

>The descriptions of arbitrary concatenation, flexible arbitrary
>concatenation, AUG-X/STSG-X, TUG-X/VTG, STM-N/OC-N transparency are
>beyond existing SONET/sDH standards and when included in GMPLS are
>"redefinitions of SONET/SDH". Redefinitions of SDH/SONET are not within
>the scope of GMPLS work...

Playing with words is fun ! Every word that is not part of the SDH/SONET
standards belongs only to ITU-T since it is a redefinition of SDH/SONET.

In the same way dynamic SDH/SONET circuit establishment (i.e. the use of a
control plane) is not part of SDH/SONET, it is a redefinition of SDH/SONET,
so GMPLS to control SDH/SONET is not in the GMPLS scope, and in the same way
GMPLS to control any other technology than IP is not part of the GMPLS
scope.

Transparency, arbitrary concatenation and flexible arbitrary concatenation
are not defined in SDH/SONET standards (is there a need ?). The use of a
signaling plane to control the SDH/SONET network is not defined in SDH/SONET
standards. All the types of SDH/SONET fast restoration schemes already
implemented (pre-computed, pre-signaled, etc) are not defined in SDH/SONET
standards, etc, etc.

So the conclusion is that the IETF should stop immediately to work on GMPLS
:-) We should have one different control plane for each layer :-) Cool you
will have a job for ten years, me too by the way !

Note that GMPLS doesn't do something strange about AUG-X/STSG-X, TUG-X/VTG,
they are defined in the standards, it is just a code type, like VC-4 or
STM-1. By the way, AUG-X in GMPLS was asked by your own colleagues.

Let's be serious please !

Rgds,

Eric

Lyndon Ong wrote:
> 
> Perhaps it may reassure people to note that part of the IETF process
> involves removal of a feature if you cannot document interoperability of
> multiple implementations of the feature.  This means that if it can't be
> implemented or no one wants to do it, it will be taken out of the specs.
> 
> Cheers,
> 
> Lyndon
> 
> At 02:31 PM 5/18/2001 -0700, Jonathan Lang wrote:
> >Stephen,
> >   The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
> >signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
> >there has been some confusion on the list about this.  Since vendors are
> >doing the "arbitrary concatenation" that Greg and Eric are describing,
why
> >shouldn't we allow the signaling protocol to support this?  To me this
seems
> >like fostering interoperability.
> >
> >-Jonathan
> >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Friday, May 18, 2001 2:06 PM
> > > To: Mannie, Eric
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Proposed text for the concatenation
> > >
> > >
> > > Eric,
> > > I think this goes against earlier email that says T1X1 and ITU-T
> > > are responsible for specification of SONET/SDH. There are two
> > > standardized forms of concatenation. Your proposal includes only
> > > one of the standardized forms and two that are, for the moment,
> > > proprietary. If we accept that SONET/SDH is the responsibility
> > > of T1X1/ITU-T, then for the moment I think the options can only
> > > be:
> > > - No concatenation
> > > - Standard Contiguous concatenation
> > > - Standard Virtual concatenation
> > > - (all others are, for the moment proprietary) vendor specific
> > >   concatenation types
> > > The other concatenation proposals must go to T1X1/ITU-T before
> > > they can be considered standardized.
> > > Regards,
> > > Steve Trowbridge
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Dear All,
> > > >
> > > > I am pleased to see so many people discussing so much on
> > > these mailing
> > > > lists, but now as an editor of
> > > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > > would like to make some progress.
> > > >
> > > > Please, carefully read the following text that clarifies
> > > the contiguous
> > > > concatenation part of the draft and that introduces one simple new
> > > > concatenation type.
> > > >
> > > > "This field indicates the type of SONET/SDH contiguous
> > > concatenation to
> > > > apply on the Elementary Signal. It is set to zero to
> > > indicate that no
> > > > contiguous concatenation is requested (default value). The
> > > values are
> > > > defined in the following table:
> > > >
> > > >        Bits   Contiguous Concatenation Type
> > > >       -----   ----------------------------------
> > > >        000     No contiguous concatenation requested
> > > >        001     Standard contiguous concatenation
> > > >        010     Arbitrary contiguous concatenation
> > > >        011     Flexible arbitrary contiguous concatenation
> > > >       others   Vendor specific concatenation types
> > > >
> > > > Standard contiguous concatenation refers to the contiguous
> > > concatenation as
> > > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > > contiguous
> > > > concatenation relaxes the limitations of these standards in
> > > terms of the
> > > > location where a contiguous signal can start, and in terms
> > > of the number of
> > > > concatenated VC's/SPE's that can compose this signal.
> > > >
> > > > Flexible arbitrary contiguous concatenation is an
> > > optimisation of the
> > > > arbitrary contiguous concatenation that allows to "inverse
> > > multiplex" a
> > > > contiguously concatenated signal on a per multiplex
> > > section/line basis. In
> > > > order to be effectively used, an upstream node must
> > > indicate that its
> > > > supports this feature to its immediate downstream node,
> > > using the CCT field.
> > > > The downstream node can in that case use that feature and
> > > return a list of
> > > > labels, one for each element of the "inverse multiplex";
> > > instead of one
> > > > single label indicating the beginning of the contiguous signal.
> > > >
> > > > The three types of contiguous concatenation defined here
> > > before defines
> > > > indeed a hierarchy of flexibility in the contiguous
> > > concatenation. If
> > > > selected, the flexible arbitrary contiguous concatenation,
> > > indicates that
> > > > any of the three types of contiguous concatenation can be
> > > chosen by the
> > > > downstream node. It is up to the downstream node to choose
> > > the one that it
> > > > wants to use. The upstream node, when receiving the labels from the
> > > > downstream node, may accept or refuse what was proposed."
> > > >
> > > > Please send me your technical comments about the technical
> > > correctness of
> > > > this text only. Please, delay discussions about the
> > > usefulness of these
> > > > features and the way to implement them to another time.
> > > What is important is
> > > > that each feature works. Your profile, implementation, or
> > > configuration
> > > > should determine what you like and what you want to
> > > support, not this
> > > > signalling.
> > > >
> > > > Take your time to read the text and to answer, it is 10PM
> > > in my time zone
> > > > and I will leave my office. I'll be back on Monday morning
> > > to read your
> > > > answers.
> > > >
> > > > Many thanks to all of you and have a nice week-end.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > Eric Mannie
> > > > Technology & Standards Strategy Manager
> > > > Network Engineering Strategy
> > > > EBONE
> > > >
> > > > Terhulpsesteenweg 6A
> > > > 1560 Hoeilaart - Belgium
> > > >
> > > > Tel:    +32 2 658 56 52
> > > > Mobile: +32 496 58 56 52
> > > > Fax:    +32 2 658 51 18
> > > > E-mail: [email-masked]
> > > >
> > > >
> > >

Delivery-date: Mon, 21 May 2001 04:31:18 -0700
Cc: Jonathan Lang <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked]
Date: Mon, 21 May 2001 13:30:54 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Lyndon Ong <[email-masked]>
Original-CC: Jonathan Lang <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------DC68005B2C926E96AE9CCE9C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lyndon,

I had the hope that the message below would have been unambiguous:

--------------------------------
Subject: Is IETF redefining SONET/SDH?
Date: Fri, 18 May 2001 17:50:01 +0200
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>

Well... from some of the emails posted to a few of the subIP area WGs
it may seem like that. However, it should be clear to everyone that we
are
not.
     
	It seems that the discussion is moving into that direction, but,
	let us be clear, we in the IETF shouldNOT be defining things
	that already have been defined or tried in the ITU. So we will not
	redefine SONET/SDH. We'd rather be in sync with what the ITU is
	defining in this area. It would be best to focus on defining the 
> the use of signaling/routing protocols to do provisioning and 
> restoration.
> 
Bert and Scott
-----------------------------------

The descriptions of arbitrary concatenation, flexible arbitrary
concatenation, AUG-X/STSG-X, TUG-X/VTG, STM-N/OC-N transparency are
beyond existing SONET/sDH standards and when included in GMPLS are
"redefinitions of SONET/SDH". Redefinitions of SDH/SONET are not within
the scope of GMPLS work...

Regards,

Maarten

Lyndon Ong wrote:
> 
> Perhaps it may reassure people to note that part of the IETF process
> involves removal of a feature if you cannot document interoperability of
> multiple implementations of the feature.  This means that if it can't be
> implemented or no one wants to do it, it will be taken out of the specs.
> 
> Cheers,
> 
> Lyndon
> 
> At 02:31 PM 5/18/2001 -0700, Jonathan Lang wrote:
> >Stephen,
> >   The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
> >signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
> >there has been some confusion on the list about this.  Since vendors are
> >doing the "arbitrary concatenation" that Greg and Eric are describing, why
> >shouldn't we allow the signaling protocol to support this?  To me this seems
> >like fostering interoperability.
> >
> >-Jonathan
> >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:[email-masked]]
> > > Sent: Friday, May 18, 2001 2:06 PM
> > > To: Mannie, Eric
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: Proposed text for the concatenation
> > >
> > >
> > > Eric,
> > > I think this goes against earlier email that says T1X1 and ITU-T
> > > are responsible for specification of SONET/SDH. There are two
> > > standardized forms of concatenation. Your proposal includes only
> > > one of the standardized forms and two that are, for the moment,
> > > proprietary. If we accept that SONET/SDH is the responsibility
> > > of T1X1/ITU-T, then for the moment I think the options can only
> > > be:
> > > - No concatenation
> > > - Standard Contiguous concatenation
> > > - Standard Virtual concatenation
> > > - (all others are, for the moment proprietary) vendor specific
> > >   concatenation types
> > > The other concatenation proposals must go to T1X1/ITU-T before
> > > they can be considered standardized.
> > > Regards,
> > > Steve Trowbridge
> > >
> > > "Mannie, Eric" wrote:
> > > >
> > > > Dear All,
> > > >
> > > > I am pleased to see so many people discussing so much on
> > > these mailing
> > > > lists, but now as an editor of
> > > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > > would like to make some progress.
> > > >
> > > > Please, carefully read the following text that clarifies
> > > the contiguous
> > > > concatenation part of the draft and that introduces one simple new
> > > > concatenation type.
> > > >
> > > > "This field indicates the type of SONET/SDH contiguous
> > > concatenation to
> > > > apply on the Elementary Signal. It is set to zero to
> > > indicate that no
> > > > contiguous concatenation is requested (default value). The
> > > values are
> > > > defined in the following table:
> > > >
> > > >        Bits   Contiguous Concatenation Type
> > > >       -----   ----------------------------------
> > > >        000     No contiguous concatenation requested
> > > >        001     Standard contiguous concatenation
> > > >        010     Arbitrary contiguous concatenation
> > > >        011     Flexible arbitrary contiguous concatenation
> > > >       others   Vendor specific concatenation types
> > > >
> > > > Standard contiguous concatenation refers to the contiguous
> > > concatenation as
> > > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > > contiguous
> > > > concatenation relaxes the limitations of these standards in
> > > terms of the
> > > > location where a contiguous signal can start, and in terms
> > > of the number of
> > > > concatenated VC's/SPE's that can compose this signal.
> > > >
> > > > Flexible arbitrary contiguous concatenation is an
> > > optimisation of the
> > > > arbitrary contiguous concatenation that allows to "inverse
> > > multiplex" a
> > > > contiguously concatenated signal on a per multiplex
> > > section/line basis. In
> > > > order to be effectively used, an upstream node must
> > > indicate that its
> > > > supports this feature to its immediate downstream node,
> > > using the CCT field.
> > > > The downstream node can in that case use that feature and
> > > return a list of
> > > > labels, one for each element of the "inverse multiplex";
> > > instead of one
> > > > single label indicating the beginning of the contiguous signal.
> > > >
> > > > The three types of contiguous concatenation defined here
> > > before defines
> > > > indeed a hierarchy of flexibility in the contiguous
> > > concatenation. If
> > > > selected, the flexible arbitrary contiguous concatenation,
> > > indicates that
> > > > any of the three types of contiguous concatenation can be
> > > chosen by the
> > > > downstream node. It is up to the downstream node to choose
> > > the one that it
> > > > wants to use. The upstream node, when receiving the labels from the
> > > > downstream node, may accept or refuse what was proposed."
> > > >
> > > > Please send me your technical comments about the technical
> > > correctness of
> > > > this text only. Please, delay discussions about the
> > > usefulness of these
> > > > features and the way to implement them to another time.
> > > What is important is
> > > > that each feature works. Your profile, implementation, or
> > > configuration
> > > > should determine what you like and what you want to
> > > support, not this
> > > > signalling.
> > > >
> > > > Take your time to read the text and to answer, it is 10PM
> > > in my time zone
> > > > and I will leave my office. I'll be back on Monday morning
> > > to read your
> > > > answers.
> > > >
> > > > Many thanks to all of you and have a nice week-end.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >
> > > > Eric Mannie
> > > > Technology & Standards Strategy Manager
> > > > Network Engineering Strategy
> > > > EBONE
> > > >
> > > > Terhulpsesteenweg 6A
> > > > 1560 Hoeilaart - Belgium
> > > >
> > > > Tel:    +32 2 658 56 52
> > > > Mobile: +32 496 58 56 52
> > > > Fax:    +32 2 658 51 18
> > > > E-mail: [email-masked]
> > > >
> > > >
> > >
--------------DC68005B2C926E96AE9CCE9C
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------DC68005B2C926E96AE9CCE9C--

Delivery-date: Mon, 21 May 2001 04:16:24 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked], 'Eric Gray' <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 13:14:32 +0200

Hello Stephen,

>I think this goes against earlier email that says T1X1 and ITU-T
>are responsible for specification of SONET/SDH. There are two
>standardized forms of concatenation. Your proposal includes only
>one of the standardized forms and two that are, for the moment,
>proprietary. If we accept that SONET/SDH is the responsibility
>of T1X1/ITU-T...the other concatenation proposals must go to
>T1X1/ITU-T before they can be considered standardized.

Transparency and contiguous arbitrary concatenation were done in the current
draft with the significant participation of ITU-T experts that regularly
attend and participate to ITU-T meetings (several of them working for your
company by the way). We reached a consensus for the current draft between a
significant number of people working on different sides, all were SDH/SONET
experts. The most active co-authors even hold an half-day editing session in
parallel with the last OIF meeting in Paris. See the explanations hereafter.

We should stop the debate ITU-T against IETF, my company is member of both
and the folks that work on GMPLS to control SDH/SONET since one year and a
half are SDH/SONET experts !

We gave some explanations in our document to better describe what we are
speaking about, it has *nothing* to do with the way to implement it. Anybody
is free to describe what he/she is talking about. We gave our explanation of
a few interesting SDH/SONET behaviours in order to be sure that people will
understand what we are talking about.

Moreover, it is not because something is not defined in an SDH standard that
it doesn't work or doesn't exist, specially if this doesn't require any
change to the standards ! Note that there is a life outside of the G.707
standard.

Sending flames to mailing lists without trying to understand how it works is
confusing for everybody.

In that context, one should make the difference between:

1) SDH/SONET features that need an additional standard to be able to
interoperate:
----------------------------------------------------------------------------
------

In that case this is NOT at all in the scope of the IETF of course. I never
heard anybody at the IETF proposing to do SDH/SONET standards, it does not
make sense. The IETF management was *very* clear about that. It is well
understood and agreed. There is non reason to come back to this point
constantly, and there is no reason to use it as an argument each time we
speak about SDH/SONET at the IETF !

2) SDH/SONET features that don't need any new SDH/SONET standard:
-----------------------------------------------------------------

Let's speak about the three features that are disturbing a *few* folks.

About arbitrary contiguous concatenation:
----------------------------------------

Arbitrary contiguous concatenation (as described it in the proposed text)
don't need any standard, it is just a way to use SDH/SONET. It is already
implemented since a while by many manufacturers in legacy equipment's. In
that case there is NO reason why we should not define features to control it
in the GMPLS signaling. It is not because it is not described in G.707 that
you cannot do it, or that it doesn't work. What do you want to standardize,
a written permission to do it maybe ?

About transparency:
-------------------

Transparency at the GMPLS UNI does NOT require any SDH/SONET standard
because it is NOT implemented at the UNI, it is 100% about signaling. We
never said that GMPLS MUST be used at both the UNI and NNI. The NNI could be
in a proprietary cloud of a single manufacturer. So, there is NO reason to
remove it from the GMPLS signaling.

If REQUESTED at the UNI, it has to be implemented at the NNI. Transparency
at the NNI between two manufacturers needs an agreement to interoperate.
This agreement can be achieved in very different ways: through the use of a
standard, an implementation agreement made by a forum, or an implementation
agreement between two manufacturers (e.g. at the request of an operator).

ITU-T is not the only standardization body that produced SDH standards, ETSI
also made SDH standards that were published as ETSI standards. T1X1 is not
the only body with ITU-T that can work on SDH, ETSI is there as well. The
OIF is also publishing standards, and at the last OIF there was a session
dedicated to transparency. We can expect to see more contributions at the
next OIF meeting. Some contributions could also be presented to T1X1.
Anyway, that's not the business of IETF and has nothing to do with
transparency in the GMPLS signaling at the UNI.

About flexible arbitrary contiguous concatenation:
--------------------------------------------------

What is the additional standard that we need to support flexible arbitrary
contiguous concatenation. Could someone describe what should be standardized
and why two implementations could not interoperate ?

The GMPLS signaling gives the type, the number, the order, and the position
of all components. Flexible arbitrary contiguous concatenation in GMPLS is
only an indication send to the downstream node that it could use this
feature. The upstream node doesn't request it, it simply says to the
downstream node that it supports it. The downstream node can either decide
to ignore it and use a standard contiguous concatenation, or an arbitrary
contiguous concatenation; or it could refuse the connection request. This is
a local optimization to deal with local external fragmentation of the
multiplex that will happen if you route very dynamic demands. Traditional
ITU-T folks don't understand the interest since they don't think in terms of
dynamic circuit establishment.

There is NO interoperability issue between nodes that implement it and nodes
that doesn't implement it. Again, a written permission to do it doesn't need
to be written in a standard.

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Friday, May 18, 2001 11:06 PM
To: Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,
I think this goes against earlier email that says T1X1 and ITU-T
are responsible for specification of SONET/SDH. There are two
standardized forms of concatenation. Your proposal includes only
one of the standardized forms and two that are, for the moment,
proprietary. If we accept that SONET/SDH is the responsibility
of T1X1/ITU-T, then for the moment I think the options can only
be:
- No concatenation
- Standard Contiguous concatenation
- Standard Virtual concatenation
- (all others are, for the moment proprietary) vendor specific
  concatenation types
The other concatenation proposals must go to T1X1/ITU-T before
they can be considered standardized.
Regards,
Steve Trowbridge

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> I am pleased to see so many people discussing so much on these mailing
> lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> would like to make some progress.
> 
> Please, carefully read the following text that clarifies the contiguous
> concatenation part of the draft and that introduces one simple new
> concatenation type.
> 
> "This field indicates the type of SONET/SDH contiguous concatenation to
> apply on the Elementary Signal. It is set to zero to indicate that no
> contiguous concatenation is requested (default value). The values are
> defined in the following table:
> 
>        Bits   Contiguous Concatenation Type
>       -----   ----------------------------------
>        000     No contiguous concatenation requested
>        001     Standard contiguous concatenation
>        010     Arbitrary contiguous concatenation
>        011     Flexible arbitrary contiguous concatenation
>       others   Vendor specific concatenation types
> 
> Standard contiguous concatenation refers to the contiguous concatenation
as
> it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> concatenation relaxes the limitations of these standards in terms of the
> location where a contiguous signal can start, and in terms of the number
of
> concatenated VC's/SPE's that can compose this signal.
> 
> Flexible arbitrary contiguous concatenation is an optimisation of the
> arbitrary contiguous concatenation that allows to "inverse multiplex" a
> contiguously concatenated signal on a per multiplex section/line basis. In
> order to be effectively used, an upstream node must indicate that its
> supports this feature to its immediate downstream node, using the CCT
field.
> The downstream node can in that case use that feature and return a list of
> labels, one for each element of the "inverse multiplex"; instead of one
> single label indicating the beginning of the contiguous signal.
> 
> The three types of contiguous concatenation defined here before defines
> indeed a hierarchy of flexibility in the contiguous concatenation. If
> selected, the flexible arbitrary contiguous concatenation, indicates that
> any of the three types of contiguous concatenation can be chosen by the
> downstream node. It is up to the downstream node to choose the one that it
> wants to use. The upstream node, when receiving the labels from the
> downstream node, may accept or refuse what was proposed."
> 
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important
is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
> 
> Take your time to read the text and to answer, it is 10PM in my time zone
> and I will leave my office. I'll be back on Monday morning to read your
> answers.
> 
> Many thanks to all of you and have a nice week-end.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
> 
>

Delivery-date: Mon, 21 May 2001 02:26:24 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Lyndon Ong' <[email-masked]>, Jonathan Lang <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Mon, 21 May 2001 11:24:05 +0200

Hello Lyndon,

Since we are not defining any standard for the SDH/SONET data plane but only
for the signaling plane, multiple *signaling* implementations will
interoperate without any problem !

Cheers,

Eric

-----Original Message-----
From: Lyndon Ong [mailto:[email-masked]]
Sent: Saturday, May 19, 2001 8:01 AM
To: Jonathan Lang; 'Stephen Trowbridge'; Mannie, Eric
Cc: [email-masked]; [email-masked]
Subject: RE: Proposed text for the concatenation

Perhaps it may reassure people to note that part of the IETF process
involves removal of a feature if you cannot document interoperability of
multiple implementations of the feature.  This means that if it can't be
implemented or no one wants to do it, it will be taken out of the specs.

Cheers,

Lyndon

At 02:31 PM 5/18/2001 -0700, Jonathan Lang wrote:
>Stephen,
>   The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
>signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
>there has been some confusion on the list about this.  Since vendors are
>doing the "arbitrary concatenation" that Greg and Eric are describing, why
>shouldn't we allow the signaling protocol to support this?  To me this
seems
>like fostering interoperability.
>
>-Jonathan
>
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 2:06 PM
> > To: Mannie, Eric
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Proposed text for the concatenation
> >
> >
> > Eric,
> > I think this goes against earlier email that says T1X1 and ITU-T
> > are responsible for specification of SONET/SDH. There are two
> > standardized forms of concatenation. Your proposal includes only
> > one of the standardized forms and two that are, for the moment,
> > proprietary. If we accept that SONET/SDH is the responsibility
> > of T1X1/ITU-T, then for the moment I think the options can only
> > be:
> > - No concatenation
> > - Standard Contiguous concatenation
> > - Standard Virtual concatenation
> > - (all others are, for the moment proprietary) vendor specific
> >   concatenation types
> > The other concatenation proposals must go to T1X1/ITU-T before
> > they can be considered standardized.
> > Regards,
> > Steve Trowbridge
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > I am pleased to see so many people discussing so much on
> > these mailing
> > > lists, but now as an editor of
> > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > would like to make some progress.
> > >
> > > Please, carefully read the following text that clarifies
> > the contiguous
> > > concatenation part of the draft and that introduces one simple new
> > > concatenation type.
> > >
> > > "This field indicates the type of SONET/SDH contiguous
> > concatenation to
> > > apply on the Elementary Signal. It is set to zero to
> > indicate that no
> > > contiguous concatenation is requested (default value). The
> > values are
> > > defined in the following table:
> > >
> > >        Bits   Contiguous Concatenation Type
> > >       -----   ----------------------------------
> > >        000     No contiguous concatenation requested
> > >        001     Standard contiguous concatenation
> > >        010     Arbitrary contiguous concatenation
> > >        011     Flexible arbitrary contiguous concatenation
> > >       others   Vendor specific concatenation types
> > >
> > > Standard contiguous concatenation refers to the contiguous
> > concatenation as
> > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > contiguous
> > > concatenation relaxes the limitations of these standards in
> > terms of the
> > > location where a contiguous signal can start, and in terms
> > of the number of
> > > concatenated VC's/SPE's that can compose this signal.
> > >
> > > Flexible arbitrary contiguous concatenation is an
> > optimisation of the
> > > arbitrary contiguous concatenation that allows to "inverse
> > multiplex" a
> > > contiguously concatenated signal on a per multiplex
> > section/line basis. In
> > > order to be effectively used, an upstream node must
> > indicate that its
> > > supports this feature to its immediate downstream node,
> > using the CCT field.
> > > The downstream node can in that case use that feature and
> > return a list of
> > > labels, one for each element of the "inverse multiplex";
> > instead of one
> > > single label indicating the beginning of the contiguous signal.
> > >
> > > The three types of contiguous concatenation defined here
> > before defines
> > > indeed a hierarchy of flexibility in the contiguous
> > concatenation. If
> > > selected, the flexible arbitrary contiguous concatenation,
> > indicates that
> > > any of the three types of contiguous concatenation can be
> > chosen by the
> > > downstream node. It is up to the downstream node to choose
> > the one that it
> > > wants to use. The upstream node, when receiving the labels from the
> > > downstream node, may accept or refuse what was proposed."
> > >
> > > Please send me your technical comments about the technical
> > correctness of
> > > this text only. Please, delay discussions about the
> > usefulness of these
> > > features and the way to implement them to another time.
> > What is important is
> > > that each feature works. Your profile, implementation, or
> > configuration
> > > should determine what you like and what you want to
> > support, not this
> > > signalling.
> > >
> > > Take your time to read the text and to answer, it is 10PM
> > in my time zone
> > > and I will leave my office. I'll be back on Monday morning
> > to read your
> > > answers.
> > >
> > > Many thanks to all of you and have a nice week-end.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > Eric Mannie
> > > Technology & Standards Strategy Manager
> > > Network Engineering Strategy
> > > EBONE
> > >
> > > Terhulpsesteenweg 6A
> > > 1560 Hoeilaart - Belgium
> > >
> > > Tel:    +32 2 658 56 52
> > > Mobile: +32 496 58 56 52
> > > Fax:    +32 2 658 51 18
> > > E-mail: [email-masked]
> > >
> > >
> >

Delivery-date: Mon, 21 May 2001 02:05:58 -0700
Cc: "'Huub van Helvoort'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Mon, 21 May 2001 11:02:24 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: "'Huub van Helvoort'" <[email-masked]>, Zhi-Wei Lin <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] Re: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------412A107E3AFCCA08322901E3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

Comment in-line:

"Bernstein, Greg" wrote:
> 
> Hi Huub, see the comments in line below. But first, a couple of points (as
> usual):
> (1)     Virtual Concatenation is a great feature in SONET/SDH and I'm very
> much for it and I think it has a lot to offer.
> (2)     Arbitrary Concatenation means (to me) three things: (a) arbitrary
> size - don't know that this is that useful in a general network-(b)
> arbitrary starting time slot, (c) arbitrary locations of successive
> timeslots.
> (3)     If we use arbitrary concatenation but restrict to standard sizes,
> then we have the capability to avoid regrooming on a link by link basis
> (note that the arbitrary placement doesn't preclude a restriction to
> standard timeslot usage.
> (4)     In line with Eric's comment do we want the signaling protocol to
> include standard practice, possibly standard practice, features offered by
> one quarter of the vendors, etc... Or strictly what is standardized?
> Switching based on path groups certainly isn't in any standard (its not
> precluded)but a few vendors provide it so we put it in. 

Given the discussion on arbitrary concatenation and the clear request
not to redefine SONET/SDH in the control plane specification, I would
like to apply it to all SONET/SDH extensions... including the one that I
proposed (AUG-X/STSG-X) and the one already present (and my trigger)
TUG-X/VTG.

I will have to propose to Q.9/15 (responsible for G.783) to define an
additional MSn/Sn_A function which will be capable to support the AUG-X.
Note that there is no need to extend G.707 (or T1.105) for this feature.
It is a pure SDH/SONET equipment issue (i.e. G.783).

> The additional
> transparency feature was requested so we put it in (some of us put in a
> bunch of work to fix it up from its initial form, even if we would have
> preferred its deferal). 

Also this extension of SONET/SDH should not be included, unless it is
supported by G.707 and T1.105.

> Hence it was my notion that we were making the
> signaling specification a common language and not trying to redefine
> SONET/SDH standards (which should aim for the least common denominator in
> some sense.  BTW how did that extreme layer violation of in-band FEC get in
> the OC-192 spec?).

If you look at the FEC model in G.783, you will notice that there is no
layer violation. The FEC processing is part of the RS/MS adaptation
function, and to support it two new adaptation functions have been
defined RSn/MSFn_A and RSn/MSn-fec_A (see 10.3.6/G.783 10/2000). Note
that the existing RSn_TT and MSn_TT functions haven't been modified at
all.

Regards,

Maarten
--------------412A107E3AFCCA08322901E3
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------412A107E3AFCCA08322901E3--

Delivery-date: Mon, 21 May 2001 01:48:20 -0700
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 21 May 2001 10:43:02 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Yuri Landry <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked]
Subject: Re: GMPLS Message Structures

This is a multi-part message in MIME format.
--------------EBBF11179F3A7C91813BD881
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Manoj, Yuri,

In my current understanding, a waveband is a group of OCh (optical
channel) signals located in a contiguous set of tributary (i.e.
frequency) slots.

A waveband is therefore related to partitioning, rather than a layering.
A waveband shouldn't have an LSP encoding type itself, but instead be
part of the OCh layer network. E.g. a specific RGT (requested groupting
type) of "contiguous waveband" can be defined for this purpose with the
RNC (requested number of components) indicating the size of the
waveband.

The above is simply a first shot; in general the issue can be more
complex due to the fact that the frequency slot for a 2G5, a 10G and a
40G signal may have differnet bandwidths: e.g. 2G5 freq. slot width e.g.
25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq. slot width e.g.
100 GHz. For the case of (future?) mixed rate WDM signals with bit rate
optimized freq. slot widths, a waveband might need a start-of-waveband
and end-of-waveband (SOW-EOW) indication, instead of RNC.

Regards,

Maarten

Yuri Landry wrote:
> 
> Mano,
> 
> >            Can someone tell me the message structure of Label Request and
> >Label Mapping in GMPLS ?
> >I am confused about the presence of LightPath Id in O-UNI messages and LSP
> >Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
> >it like that both lightPath Id and LSP Id will be carried in GMPLS messages
> >? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped
> >to
> >multiple LSP Ids or vice versa ?
> 
> I think you mean Connection ID and LSP ID. A connection ID is an ID for
> network connection, which may consist many LSPs. For example, the virtual
> concatenation case.
> 
> A LSP may tunnel through multiple pre-established connections.
> 
> >Also, for waveband switching, the genralized label has the format
> >(wavebandId - start label - end label).
> >When the label request message is received on incoming interface, how to
> >identify that the waveband label is requested ?
> >Is it the LSP encoding type or some other parameter in label request
> >message
> >? If it is the Lambda encoding type then how to identify that whether a
> >lambda or waveband label is requested ?
> >
> >Also, it is mentioned that wavebandId (32 bits) is selected by the sender
> >and reused in all the subsequent messages. What all subsequent
> >messages is it mentioning to ?
> >
> >Can wavebandId be present in Label Withdraw/Release messages ?
> >
> >I am not able to workout the message structures for GMPLS.
> >
> 
> To me waveband label defined in GMPLS drafts is a joke. The reason to have
> the waveband label is that someone claimed that the waveband's order might
> flip when going through a switch. My suggestion is don't take it seriously.
> 
> >I am not sure how these drafts are at last call. Atleast it should mention
> >the message structures of various messages.
> >
> 
> Agree.
> 
> Regards,
> 
> Yuri
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
--------------EBBF11179F3A7C91813BD881
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------EBBF11179F3A7C91813BD881--

Delivery-date: Fri, 18 May 2001 23:04:51 -0700
Date: Fri, 18 May 2001 23:01:00 -0700
To: Jonathan Lang <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "Mannie, Eric" <[email-masked]>
From: Lyndon Ong <[email-masked]>
Subject: RE: Proposed text for the concatenation
Cc: [email-masked], [email-masked]

Perhaps it may reassure people to note that part of the IETF process
involves removal of a feature if you cannot document interoperability of
multiple implementations of the feature.  This means that if it can't be
implemented or no one wants to do it, it will be taken out of the specs.

Cheers,

Lyndon

At 02:31 PM 5/18/2001 -0700, Jonathan Lang wrote:
>Stephen,
>   The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
>signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
>there has been some confusion on the list about this.  Since vendors are
>doing the "arbitrary concatenation" that Greg and Eric are describing, why
>shouldn't we allow the signaling protocol to support this?  To me this seems
>like fostering interoperability.
>
>-Jonathan
>
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:[email-masked]]
> > Sent: Friday, May 18, 2001 2:06 PM
> > To: Mannie, Eric
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: Proposed text for the concatenation
> >
> >
> > Eric,
> > I think this goes against earlier email that says T1X1 and ITU-T
> > are responsible for specification of SONET/SDH. There are two
> > standardized forms of concatenation. Your proposal includes only
> > one of the standardized forms and two that are, for the moment,
> > proprietary. If we accept that SONET/SDH is the responsibility
> > of T1X1/ITU-T, then for the moment I think the options can only
> > be:
> > - No concatenation
> > - Standard Contiguous concatenation
> > - Standard Virtual concatenation
> > - (all others are, for the moment proprietary) vendor specific
> >   concatenation types
> > The other concatenation proposals must go to T1X1/ITU-T before
> > they can be considered standardized.
> > Regards,
> > Steve Trowbridge
> >
> > "Mannie, Eric" wrote:
> > >
> > > Dear All,
> > >
> > > I am pleased to see so many people discussing so much on
> > these mailing
> > > lists, but now as an editor of
> > draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > > would like to make some progress.
> > >
> > > Please, carefully read the following text that clarifies
> > the contiguous
> > > concatenation part of the draft and that introduces one simple new
> > > concatenation type.
> > >
> > > "This field indicates the type of SONET/SDH contiguous
> > concatenation to
> > > apply on the Elementary Signal. It is set to zero to
> > indicate that no
> > > contiguous concatenation is requested (default value). The
> > values are
> > > defined in the following table:
> > >
> > >        Bits   Contiguous Concatenation Type
> > >       -----   ----------------------------------
> > >        000     No contiguous concatenation requested
> > >        001     Standard contiguous concatenation
> > >        010     Arbitrary contiguous concatenation
> > >        011     Flexible arbitrary contiguous concatenation
> > >       others   Vendor specific concatenation types
> > >
> > > Standard contiguous concatenation refers to the contiguous
> > concatenation as
> > > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary
> > contiguous
> > > concatenation relaxes the limitations of these standards in
> > terms of the
> > > location where a contiguous signal can start, and in terms
> > of the number of
> > > concatenated VC's/SPE's that can compose this signal.
> > >
> > > Flexible arbitrary contiguous concatenation is an
> > optimisation of the
> > > arbitrary contiguous concatenation that allows to "inverse
> > multiplex" a
> > > contiguously concatenated signal on a per multiplex
> > section/line basis. In
> > > order to be effectively used, an upstream node must
> > indicate that its
> > > supports this feature to its immediate downstream node,
> > using the CCT field.
> > > The downstream node can in that case use that feature and
> > return a list of
> > > labels, one for each element of the "inverse multiplex";
> > instead of one
> > > single label indicating the beginning of the contiguous signal.
> > >
> > > The three types of contiguous concatenation defined here
> > before defines
> > > indeed a hierarchy of flexibility in the contiguous
> > concatenation. If
> > > selected, the flexible arbitrary contiguous concatenation,
> > indicates that
> > > any of the three types of contiguous concatenation can be
> > chosen by the
> > > downstream node. It is up to the downstream node to choose
> > the one that it
> > > wants to use. The upstream node, when receiving the labels from the
> > > downstream node, may accept or refuse what was proposed."
> > >
> > > Please send me your technical comments about the technical
> > correctness of
> > > this text only. Please, delay discussions about the
> > usefulness of these
> > > features and the way to implement them to another time.
> > What is important is
> > > that each feature works. Your profile, implementation, or
> > configuration
> > > should determine what you like and what you want to
> > support, not this
> > > signalling.
> > >
> > > Take your time to read the text and to answer, it is 10PM
> > in my time zone
> > > and I will leave my office. I'll be back on Monday morning
> > to read your
> > > answers.
> > >
> > > Many thanks to all of you and have a nice week-end.
> > >
> > > Kind regards,
> > >
> > > Eric
> > >
> > > Eric Mannie
> > > Technology & Standards Strategy Manager
> > > Network Engineering Strategy
> > > EBONE
> > >
> > > Terhulpsesteenweg 6A
> > > 1560 Hoeilaart - Belgium
> > >
> > > Tel:    +32 2 658 56 52
> > > Mobile: +32 496 58 56 52
> > > Fax:    +32 2 658 51 18
> > > E-mail: [email-masked]
> > >
> > >
> >

Delivery-date: Fri, 18 May 2001 15:32:54 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: GMPLS Message Structures : Authors : Please Speak Up ......  
Date: Fri, 18 May 2001 15:31:50 -0700

Hi Yuri,
           Thanx for the response. Actually, connection Id is the term 
defined by OIF but Lightpath Id is used in the IETF draft "LDP extensions 
for O-UNI". Both are actually same.

I am still confused about the operation of waveband Id and waveband Labels.

Authors : Please speak up for waveband related doubts.

Thanks,
manoj.

>From: "Yuri Landry" <[email-masked]>
>To: [email-masked], [email-masked], [email-masked]
>Subject: Re: GMPLS Message Structures
>Date: Fri, 18 May 2001 18:08:13 -0000
>
>Mano,
>
>>            Can someone tell me the message structure of Label Request and
>>Label Mapping in GMPLS ?
>>I am confused about the presence of LightPath Id in O-UNI messages and LSP
>>Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
>>it like that both lightPath Id and LSP Id will be carried in GMPLS 
>>messages
>>? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped 
>>to
>>multiple LSP Ids or vice versa ?
>
>I think you mean Connection ID and LSP ID. A connection ID is an ID for 
>network connection, which may consist many LSPs. For example, the virtual 
>concatenation case.
>
>A LSP may tunnel through multiple pre-established connections.
>
>
>>Also, for waveband switching, the genralized label has the format
>>(wavebandId - start label - end label).
>>When the label request message is received on incoming interface, how to
>>identify that the waveband label is requested ?
>>Is it the LSP encoding type or some other parameter in label request 
>>message
>>? If it is the Lambda encoding type then how to identify that whether a
>>lambda or waveband label is requested ?
>>
>>Also, it is mentioned that wavebandId (32 bits) is selected by the sender
>>and reused in all the subsequent messages. What all subsequent
>>messages is it mentioning to ?
>>
>>Can wavebandId be present in Label Withdraw/Release messages ?
>>
>>I am not able to workout the message structures for GMPLS.
>>
>
>To me waveband label defined in GMPLS drafts is a joke. The reason to have 
>the waveband label is that someone claimed that the waveband's order might 
>flip when going through a switch. My suggestion is don't take it seriously.
>
>>I am not sure how these drafts are at last call. Atleast it should mention
>>the message structures of various messages.
>>
>
>Agree.
>
>Regards,
>
>Yuri
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 18 May 2001 15:03:41 -0700
Date: Fri, 18 May 2001 15:00:17 -0700
From: Suresh Katukam <[email-masked]>
Organization: Cisco Systems
To: Cheenu Srinivasan <[email-masked]>
CC: [email-masked]
Subject: Re: GMPLS/RSVP-TE question

Cheenu,

Let me try to answer your questions to best of my knowledge..

Cheenu Srinivasan wrote:
> 
> Reading the GMPLS drafts I have a question about setting up a
> generalized LSP with RSVP-TE. Consider the following network where
> the control plane is distinct from a data plane which is IP unaware.
> 
>      D --- E
>    /   \ /   \
>   A =1= B =2= C
> 
>  --- represent control plane links
>  =n= represent data plane links which cannot originate/terminate IP;
>      n is the local ID for this link
> 
> We want to set up an LSP A-1-B-2-C and signal it via RSVP-TE. The ERO
> should be (A-1, B-2, C). However, a Path message can only be sent
> out link A-D and has to be routed towards B; it cannot be sent
> down link 1 since 1 is not IP-capable. Is this ok? 

Yes, This is completely OK. This is the reason why OIF has introduced
OF/OB  (Out-of-Fiber/Out-of-Band) where the data links may not be
able to terminate packets/understand IP.

> What kind of
> Path state is created on D? Or, do we need to tunnel the Path
> message to B directly? Will D change the PHOP object to point
> to itself (we do not want D to change the contents of the ERO)?

D and E should not be involved in creating LSP at all. These
should pass messages through. For this, A has to send a directed
message to B and then B has to send a directed message to C. 
There should not be any router alert option bit set - this avoids
D and E looking into RSVP packets.

> In
> this case when B receives this message it will find that the
> Path came to it from an interface that is not part of the ERO. Is
> this an error?

No. This is not an error. As long as you receive a PATH message on
an interface that will take you to the previous hop, I do not
think that it should cause ERO processing error. What you really
need to validate is that in ERO, do you have link that corresponds
to A and its interface ID as per draft on handling unnumbered interfaces
in RSVP.

Thanks,
Suresh

Delivery-date: Fri, 18 May 2001 14:38:27 -0700
From: Jonathan Lang <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, "Mannie, Eric" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Proposed text for the concatenation
Date: Fri, 18 May 2001 14:31:33 -0700

Stephen,
  The intent of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt is to define
signaling mechanisms, NOT to standardize SONET/SDH concatenation types --
there has been some confusion on the list about this.  Since vendors are
doing the "arbitrary concatenation" that Greg and Eric are describing, why
shouldn't we allow the signaling protocol to support this?  To me this seems
like fostering interoperability.

-Jonathan

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 2:06 PM
> To: Mannie, Eric
> Cc: [email-masked]; [email-masked]
> Subject: Re: Proposed text for the concatenation
> 
> 
> Eric,
> I think this goes against earlier email that says T1X1 and ITU-T
> are responsible for specification of SONET/SDH. There are two
> standardized forms of concatenation. Your proposal includes only
> one of the standardized forms and two that are, for the moment,
> proprietary. If we accept that SONET/SDH is the responsibility
> of T1X1/ITU-T, then for the moment I think the options can only
> be:
> - No concatenation
> - Standard Contiguous concatenation
> - Standard Virtual concatenation
> - (all others are, for the moment proprietary) vendor specific
>   concatenation types
> The other concatenation proposals must go to T1X1/ITU-T before
> they can be considered standardized.
> Regards,
> Steve Trowbridge
> 
> "Mannie, Eric" wrote:
> > 
> > Dear All,
> > 
> > I am pleased to see so many people discussing so much on 
> these mailing
> > lists, but now as an editor of 
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> > 
> > Please, carefully read the following text that clarifies 
> the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> > 
> > "This field indicates the type of SONET/SDH contiguous 
> concatenation to
> > apply on the Elementary Signal. It is set to zero to 
> indicate that no
> > contiguous concatenation is requested (default value). The 
> values are
> > defined in the following table:
> > 
> >        Bits   Contiguous Concatenation Type
> >       -----   ----------------------------------
> >        000     No contiguous concatenation requested
> >        001     Standard contiguous concatenation
> >        010     Arbitrary contiguous concatenation
> >        011     Flexible arbitrary contiguous concatenation
> >       others   Vendor specific concatenation types
> > 
> > Standard contiguous concatenation refers to the contiguous 
> concatenation as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary 
> contiguous
> > concatenation relaxes the limitations of these standards in 
> terms of the
> > location where a contiguous signal can start, and in terms 
> of the number of
> > concatenated VC's/SPE's that can compose this signal.
> > 
> > Flexible arbitrary contiguous concatenation is an 
> optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse 
> multiplex" a
> > contiguously concatenated signal on a per multiplex 
> section/line basis. In
> > order to be effectively used, an upstream node must 
> indicate that its
> > supports this feature to its immediate downstream node, 
> using the CCT field.
> > The downstream node can in that case use that feature and 
> return a list of
> > labels, one for each element of the "inverse multiplex"; 
> instead of one
> > single label indicating the beginning of the contiguous signal.
> > 
> > The three types of contiguous concatenation defined here 
> before defines
> > indeed a hierarchy of flexibility in the contiguous 
> concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, 
> indicates that
> > any of the three types of contiguous concatenation can be 
> chosen by the
> > downstream node. It is up to the downstream node to choose 
> the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> > 
> > Please send me your technical comments about the technical 
> correctness of
> > this text only. Please, delay discussions about the 
> usefulness of these
> > features and the way to implement them to another time. 
> What is important is
> > that each feature works. Your profile, implementation, or 
> configuration
> > should determine what you like and what you want to 
> support, not this
> > signalling.
> > 
> > Take your time to read the text and to answer, it is 10PM 
> in my time zone
> > and I will leave my office. I'll be back on Monday morning 
> to read your
> > answers.
> > 
> > Many thanks to all of you and have a nice week-end.
> > 
> > Kind regards,
> > 
> > Eric
> > 
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> > 
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> > 
> > Tel:    +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax:    +32 2 658 51 18
> > E-mail: [email-masked]
> > 
> >
> 

Delivery-date: Fri, 18 May 2001 14:28:57 -0700
Date: Fri, 18 May 2001 23:26:30 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Stephen Trowbridge <[email-masked]>
CC: "Mannie, Eric" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for the concatenation

This is a multi-part message in MIME format.
--------------321DE579D310B8BD8D5C8D3E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Stephen,

Within the e-mail of Eric it is clearly mentioned:
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.

I don't think you meet the Eric's wishes here... you should take the
last sentence as the real purpose of this proposed text. I think that
Eric would like to know if the technical description he gives on 
contiguous concatenation is technically correct.

FYI: Standard virtual concatenation is part of the NVC field (i.e. not
determined by the CCT field). So GMPLS for SDH/Sonet includes standard
virtual concatenation.

Hope this helps you to understand a little bit more the purpose of the
Eric's e-mail.

Kind regards,
Dimitri.

Stephen Trowbridge wrote:
> 
> Eric,
> I think this goes against earlier email that says T1X1 and ITU-T
> are responsible for specification of SONET/SDH. There are two
> standardized forms of concatenation. Your proposal includes only
> one of the standardized forms and two that are, for the moment,
> proprietary. If we accept that SONET/SDH is the responsibility
> of T1X1/ITU-T, then for the moment I think the options can only
> be:
> - No concatenation
> - Standard Contiguous concatenation
> - Standard Virtual concatenation
> - (all others are, for the moment proprietary) vendor specific
>   concatenation types
> The other concatenation proposals must go to T1X1/ITU-T before
> they can be considered standardized.
> Regards,
> Steve Trowbridge
> 
> "Mannie, Eric" wrote:
> >
> > Dear All,
> >
> > I am pleased to see so many people discussing so much on these mailing
> > lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> > would like to make some progress.
> >
> > Please, carefully read the following text that clarifies the contiguous
> > concatenation part of the draft and that introduces one simple new
> > concatenation type.
> >
> > "This field indicates the type of SONET/SDH contiguous concatenation to
> > apply on the Elementary Signal. It is set to zero to indicate that no
> > contiguous concatenation is requested (default value). The values are
> > defined in the following table:
> >
> >        Bits   Contiguous Concatenation Type
> >       -----   ----------------------------------
> >        000     No contiguous concatenation requested
> >        001     Standard contiguous concatenation
> >        010     Arbitrary contiguous concatenation
> >        011     Flexible arbitrary contiguous concatenation
> >       others   Vendor specific concatenation types
> >
> > Standard contiguous concatenation refers to the contiguous concatenation as
> > it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> > concatenation relaxes the limitations of these standards in terms of the
> > location where a contiguous signal can start, and in terms of the number of
> > concatenated VC's/SPE's that can compose this signal.
> >
> > Flexible arbitrary contiguous concatenation is an optimisation of the
> > arbitrary contiguous concatenation that allows to "inverse multiplex" a
> > contiguously concatenated signal on a per multiplex section/line basis. In
> > order to be effectively used, an upstream node must indicate that its
> > supports this feature to its immediate downstream node, using the CCT field.
> > The downstream node can in that case use that feature and return a list of
> > labels, one for each element of the "inverse multiplex"; instead of one
> > single label indicating the beginning of the contiguous signal.
> >
> > The three types of contiguous concatenation defined here before defines
> > indeed a hierarchy of flexibility in the contiguous concatenation. If
> > selected, the flexible arbitrary contiguous concatenation, indicates that
> > any of the three types of contiguous concatenation can be chosen by the
> > downstream node. It is up to the downstream node to choose the one that it
> > wants to use. The upstream node, when receiving the labels from the
> > downstream node, may accept or refuse what was proposed."
> >
> > Please send me your technical comments about the technical correctness of
> > this text only. Please, delay discussions about the usefulness of these
> > features and the way to implement them to another time. What is important is
> > that each feature works. Your profile, implementation, or configuration
> > should determine what you like and what you want to support, not this
> > signalling.
> >
> > Take your time to read the text and to answer, it is 10PM in my time zone
> > and I will leave my office. I'll be back on Monday morning to read your
> > answers.
> >
> > Many thanks to all of you and have a nice week-end.
> >
> > Kind regards,
> >
> > Eric
> >
> > Eric Mannie
> > Technology & Standards Strategy Manager
> > Network Engineering Strategy
> > EBONE
> >
> > Terhulpsesteenweg 6A
> > 1560 Hoeilaart - Belgium
> >
> > Tel:    +32 2 658 56 52
> > Mobile: +32 496 58 56 52
> > Fax:    +32 2 658 51 18
> > E-mail: [email-masked]
> >
> >
--------------321DE579D310B8BD8D5C8D3E
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------321DE579D310B8BD8D5C8D3E--

Delivery-date: Fri, 18 May 2001 14:06:47 -0700
Date: Fri, 18 May 2001 15:06:28 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Mannie, Eric" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Proposed text for the concatenation

Eric,
I think this goes against earlier email that says T1X1 and ITU-T
are responsible for specification of SONET/SDH. There are two
standardized forms of concatenation. Your proposal includes only
one of the standardized forms and two that are, for the moment,
proprietary. If we accept that SONET/SDH is the responsibility
of T1X1/ITU-T, then for the moment I think the options can only
be:
- No concatenation
- Standard Contiguous concatenation
- Standard Virtual concatenation
- (all others are, for the moment proprietary) vendor specific
  concatenation types
The other concatenation proposals must go to T1X1/ITU-T before
they can be considered standardized.
Regards,
Steve Trowbridge

"Mannie, Eric" wrote:
> 
> Dear All,
> 
> I am pleased to see so many people discussing so much on these mailing
> lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
> would like to make some progress.
> 
> Please, carefully read the following text that clarifies the contiguous
> concatenation part of the draft and that introduces one simple new
> concatenation type.
> 
> "This field indicates the type of SONET/SDH contiguous concatenation to
> apply on the Elementary Signal. It is set to zero to indicate that no
> contiguous concatenation is requested (default value). The values are
> defined in the following table:
> 
>        Bits   Contiguous Concatenation Type
>       -----   ----------------------------------
>        000     No contiguous concatenation requested
>        001     Standard contiguous concatenation
>        010     Arbitrary contiguous concatenation
>        011     Flexible arbitrary contiguous concatenation
>       others   Vendor specific concatenation types
> 
> Standard contiguous concatenation refers to the contiguous concatenation as
> it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
> concatenation relaxes the limitations of these standards in terms of the
> location where a contiguous signal can start, and in terms of the number of
> concatenated VC's/SPE's that can compose this signal.
> 
> Flexible arbitrary contiguous concatenation is an optimisation of the
> arbitrary contiguous concatenation that allows to "inverse multiplex" a
> contiguously concatenated signal on a per multiplex section/line basis. In
> order to be effectively used, an upstream node must indicate that its
> supports this feature to its immediate downstream node, using the CCT field.
> The downstream node can in that case use that feature and return a list of
> labels, one for each element of the "inverse multiplex"; instead of one
> single label indicating the beginning of the contiguous signal.
> 
> The three types of contiguous concatenation defined here before defines
> indeed a hierarchy of flexibility in the contiguous concatenation. If
> selected, the flexible arbitrary contiguous concatenation, indicates that
> any of the three types of contiguous concatenation can be chosen by the
> downstream node. It is up to the downstream node to choose the one that it
> wants to use. The upstream node, when receiving the labels from the
> downstream node, may accept or refuse what was proposed."
> 
> Please send me your technical comments about the technical correctness of
> this text only. Please, delay discussions about the usefulness of these
> features and the way to implement them to another time. What is important is
> that each feature works. Your profile, implementation, or configuration
> should determine what you like and what you want to support, not this
> signalling.
> 
> Take your time to read the text and to answer, it is 10PM in my time zone
> and I will leave my office. I'll be back on Monday morning to read your
> answers.
> 
> Many thanks to all of you and have a nice week-end.
> 
> Kind regards,
> 
> Eric
> 
> Eric Mannie
> Technology & Standards Strategy Manager
> Network Engineering Strategy
> EBONE
> 
> Terhulpsesteenweg 6A
> 1560 Hoeilaart - Belgium
> 
> Tel:    +32 2 658 56 52
> Mobile: +32 496 58 56 52
> Fax:    +32 2 658 51 18
> E-mail: [email-masked]
> 
>

Delivery-date: Fri, 18 May 2001 13:28:53 -0700
From: "Mannie, Eric" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Proposed text for the concatenation
Date: Fri, 18 May 2001 22:27:48 +0200

Dear All,

I am pleased to see so many people discussing so much on these mailing
lists, but now as an editor of draft-ietf-ccamp-gmpls-sonet-sdh-00.txt I
would like to make some progress.

Please, carefully read the following text that clarifies the contiguous
concatenation part of the draft and that introduces one simple new
concatenation type.

"This field indicates the type of SONET/SDH contiguous concatenation to
apply on the Elementary Signal. It is set to zero to indicate that no
contiguous concatenation is requested (default value). The values are
defined in the following table:

       Bits   Contiguous Concatenation Type
      -----   ----------------------------------
       000     No contiguous concatenation requested
       001     Standard contiguous concatenation
       010     Arbitrary contiguous concatenation
       011     Flexible arbitrary contiguous concatenation
      others   Vendor specific concatenation types

Standard contiguous concatenation refers to the contiguous concatenation as
it is defined in SDH G.707 and SONET ANSI T1.105. Arbitrary contiguous
concatenation relaxes the limitations of these standards in terms of the
location where a contiguous signal can start, and in terms of the number of
concatenated VC's/SPE's that can compose this signal.

Flexible arbitrary contiguous concatenation is an optimisation of the
arbitrary contiguous concatenation that allows to "inverse multiplex" a
contiguously concatenated signal on a per multiplex section/line basis. In
order to be effectively used, an upstream node must indicate that its
supports this feature to its immediate downstream node, using the CCT field.
The downstream node can in that case use that feature and return a list of
labels, one for each element of the "inverse multiplex"; instead of one
single label indicating the beginning of the contiguous signal.

The three types of contiguous concatenation defined here before defines
indeed a hierarchy of flexibility in the contiguous concatenation. If
selected, the flexible arbitrary contiguous concatenation, indicates that
any of the three types of contiguous concatenation can be chosen by the
downstream node. It is up to the downstream node to choose the one that it
wants to use. The upstream node, when receiving the labels from the
downstream node, may accept or refuse what was proposed."

Please send me your technical comments about the technical correctness of
this text only. Please, delay discussions about the usefulness of these
features and the way to implement them to another time. What is important is
that each feature works. Your profile, implementation, or configuration
should determine what you like and what you want to support, not this
signalling.

Take your time to read the text and to answer, it is 10PM in my time zone
and I will leave my office. I'll be back on Monday morning to read your
answers.

Many thanks to all of you and have a nice week-end.

Kind regards,

Eric

Eric Mannie
Technology & Standards Strategy Manager
Network Engineering Strategy
EBONE

Terhulpsesteenweg 6A
1560 Hoeilaart - Belgium

Tel:    +32 2 658 56 52
Mobile: +32 496 58 56 52
Fax:    +32 2 658 51 18
E-mail: [email-masked]

	

Delivery-date: Fri, 18 May 2001 11:57:17 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Huub van Helvoort' <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked],  [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] Re: [IP-Optical] concatenation extensions in sonet/s dh
Date: Fri, 18 May 2001 11:55:37 -0700

Hi Huub, see the comments in line below. But first, a couple of points (as
usual):
(1)	Virtual Concatenation is a great feature in SONET/SDH and I'm very
much for it and I think it has a lot to offer.
(2)	Arbitrary Concatenation means (to me) three things: (a) arbitrary
size - don't know that this is that useful in a general network-(b)
arbitrary starting time slot, (c) arbitrary locations of successive
timeslots.
(3)	If we use arbitrary concatenation but restrict to standard sizes,
then we have the capability to avoid regrooming on a link by link basis
(note that the arbitrary placement doesn't preclude a restriction to
standard timeslot usage.
(4)	In line with Eric's comment do we want the signaling protocol to
include standard practice, possibly standard practice, features offered by
one quarter of the vendors, etc... Or strictly what is standardized?
Switching based on path groups certainly isn't in any standard (its not
precluded)but a few vendors provide it so we put it in. The additional
transparency feature was requested so we put it in (some of us put in a
bunch of work to fix it up from its initial form, even if we would have
preferred its deferal).  Hence it was my notion that we were making the
signaling specification a common language and not trying to redefine
SONET/SDH standards (which should aim for the least common denominator in
some sense.  BTW how did that extreme layer violation of in-band FEC get in
the OC-192 spec?).

Greg B.
I'll be taking a one week break from Sub-IP in exchange for Sub-Optic 2001
in Japan (that's submarine optics...).

	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Huub van Helvoort [mailto:[email-masked]]
		Sent:	Friday, May 18, 2001 4:28 AM
		To:	Zhi-Wei Lin
		Cc:	Bernstein, Greg; 'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	Re: [T1X1.5] Re: [IP-Optical] concatenation
extensions in sonet/sdh

		Greg, 

		Would you please provide a little more detail:

		Are the timeslots in an arbitrary concatenated signal
contiguous? No, that's the point.

		-1- if they are not contiguous:
		    what is the difference with a virtual concatenated
signal with
		    the members following exactly the same path trough the
network? Well to get technical, these are still treated as a concatenated
signal at each switch (a weakness compared to virtual concatenation). On the
other hand this doesn't need to involve path overhead (I think of virtual
concatenation as a service offered by PTE boxes).

		-2- if they are contiguous: 
		    suppose we have an OC-48 filled with: A: an STS-9c, B:
an STS-11c,
		    C: an STS-13c, D: an STS-15c in that order.
		    At a certai time A and B are not needed anymore freeing
capacity 
		    of 22 STS-1.
		    Now if a new STS-17c is required, how would one proceed
without
		    grooming (as you claim under (2) below?

		Regards, Huub.

===============================================================
		"Bernstein, Greg" wrote:

		> (2)     Arbitrary concatenation offers a solution to a
		> real problem, i.e.,
		> eliminates the need for re-grooming on lines that support
		> it.  For those who
		> have invested non-trivial amounts of money in transoceanic
		> links this can be
		> a significant savings.

		and in the same email:

		> To be precise in the definition of arbitrary
concatenation:
		> As a concatenated signal within a single SONET Line (SDH
MS), with
		> potentially arbitrary timeslots used for its components.
		>
		> The current main application is: avoiding the need for
service impacting
		> re-grooming. Note that this applies to standard sized
		> signals and is a per link property.
		>
		> Other applications do exist and are somewhat competitive
with non-LCAS
		> virtual concatenation since the implementation of
arbitrary concatenation
		> for odd sized signals is simpler than that of virtual
concatenation.  Once
		> "odd" sized signals are used an entire path through the
network must exist
		> that supports them.

		-- 
	
------------------------------------------------------------------------
		| Huub van Helvoort    |     Lucent Technologies     | PO
Box 18       |
		| TEL: +31 35 687 4393 |     ONG Systems Engineer    | 1270
AA  Huizen |
		| FAX: +31 35 687 5964 | mailto:[email-masked] | The
Netherlands |
	
------------------------------------------------------------------------
		   Always remember that you are unique...    Just like
everyone else.

		_______________________________________________
		IP-Optical mailing list
		[email-masked]
		http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Fri, 18 May 2001 11:09:50 -0700
From: "Yuri Landry" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: GMPLS Message Structures
Date: Fri, 18 May 2001 18:08:13 -0000

Mano,

>            Can someone tell me the message structure of Label Request and
>Label Mapping in GMPLS ?
>I am confused about the presence of LightPath Id in O-UNI messages and LSP
>Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is
>it like that both lightPath Id and LSP Id will be carried in GMPLS messages
>? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped 
>to
>multiple LSP Ids or vice versa ?

I think you mean Connection ID and LSP ID. A connection ID is an ID for 
network connection, which may consist many LSPs. For example, the virtual 
concatenation case.

A LSP may tunnel through multiple pre-established connections.

>Also, for waveband switching, the genralized label has the format
>(wavebandId - start label - end label).
>When the label request message is received on incoming interface, how to
>identify that the waveband label is requested ?
>Is it the LSP encoding type or some other parameter in label request 
>message
>? If it is the Lambda encoding type then how to identify that whether a
>lambda or waveband label is requested ?
>
>Also, it is mentioned that wavebandId (32 bits) is selected by the sender
>and reused in all the subsequent messages. What all subsequent
>messages is it mentioning to ?
>
>Can wavebandId be present in Label Withdraw/Release messages ?
>
>I am not able to workout the message structures for GMPLS.
>

To me waveband label defined in GMPLS drafts is a joke. The reason to have 
the waveband label is that someone claimed that the waveband's order might 
flip when going through a switch. My suggestion is don't take it seriously.

>I am not sure how these drafts are at last call. Atleast it should mention
>the message structures of various messages.
>

Agree.

Regards,

Yuri
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Fri, 18 May 2001 08:50:32 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: Is IETF redefining SONET/SDH?
Date: Fri, 18 May 2001 17:50:01 +0200

Well... from some of the emails posted to a few of the subIP area WGs
it may seem like that. However, it should be clear to everyone that we are
not.
     
	It seems that the discussion is moving into that direction, but,
	let us be clear, we in the IETF shouldNOT be defining things
	that already have been defined or tried in the ITU. So we will not
	redefine SONET/SDH. We'd rather be in sync with what the ITU is
	defining in this area. It would be best to focus on defining the 
> the use of signaling/routing protocols to do provisioning and 
> restoration.
> 
Bert and Scott

Delivery-date: Fri, 18 May 2001 08:29:03 -0700
From: Hai Vodinh <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Fri, 18 May 2001 08:04:27 -0700

Maarten,

I agree with your summary and with the general goal of keeping link 
local signaling from general network wide signaling. However this would 
still involved defining a mechanism for this signaling either:

- as part of the GMPLS signaling, but to be used only between adjacent nodes
- or another local link only signaling protocol, or perhaps an extension
  to LMP, maybe we can call it G-LMP :)

I'm not sure which is more appropriate.

Regards,
Hai

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 3:05 PM
To: Zhi-Wei Lin
Cc: Steve West; 'Stephen Trowbridge'; Bernstein, Greg; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Virtual concatenation is intended to offer the support of new ("odd
sized") service signals by the existing network.

Arbitrary concatenation (at least per "real problem" described by Greg)
is intended to offer "non blocking" links (connection between two
adjacent SDH/SONET equipment) without the need to perform a bandwidth
defragmentation action once every ... days.

The link which can't have this defragmenation, is surrounded by
arbitrary concatenation capable STM-N/OC-N line ports. A simple and
local upgrade in the existing network (replace/install 2 port units).

The network which want to offer the new ("odd sized") service is
surrounded by virtual concatenation capable client signal tributary
ports (e.g. 1GE port). A simple and local upgrade in the existing
network (install 2 port units).

As long as arbitrary concatenation isn't sold as a means to introduce
new ("odd sized") services, arbitrary concatenation and virtual
concatenation provide additional capabilities to the existing network
with local upgrades only, and without introducing new interworking
problems.

Hope this is a fair summary up to here.

Now lets have a look at the signalling impact.

- Virtual concatenation most likely doesn't need any special treatment
(in first instance) in the signalling for connection setup (latest
understanding by me). If a virtual concatenated trail is to be set up,
actually a set of X basic VC-n/STS/VT network connections are to be set
up. This may be done as the set up of X individual connections, the set
up of one group of X (co-routed) connections, the set up of n subgroups
with X1, X2, .., Xn connections each. 
The group of network connections is to be set up between two Access
Groups (AG) of the same type (virtual concatenated and same client (i.e.
G-PID)).

- Arbitrary concatenation most likely doesn't need any special treatment
in the signalling for the STM-N/OC-N trail to be set up. The STM-N/OC-N
connection can be a (virtual) fiber, and in this case STM-N/OC-N trail
setup is manual (connecting fibers). The STM-N/OC-N connection can be
created via a WDM/OTN network, and in this case the OCh/ODUk trail set
up can be performed as normal; i.e. between two access groups of the
same type and with the same G-PID (indicating STM-N/OC-N with arbitrary
concatenation support).

The use of this HOVC/STS link with arbitrary concatenation is the same
as any other HOVC/STS link (without arbitrary concatenation); at least
from the outside. Between the two SDH/SONET equipments however (i.e.
internal to the link), the signalling message will have to include the
list of timeslots. But this can be kept local to the link.

In G.ason/G.dcm the assumption is to use a link connection identifier
(i.e. address), hiding the multiplexing details during the connection
setup. The link connections have been discovered during the service
discovery phase of the creation of the link. Only in this service
discovery phase the multiplex numbers play a role. Also for arbitrary
concatenation this two step approach can be used, preventing any need to
include in the connection creation signaling message on the link the
list of timeslots allocated to this link connection. I.e. any possible
link connection allocation has its own identifier/address, which is
assigned during service discovery.

I am not sure if I am completely correct in this second part... but at
the moment it looks positive to me.

Regards,

Maarten

Delivery-date: Fri, 18 May 2001 07:58:26 -0700
From: Paul Bonenfant <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>,  "'t1x1.5'" <[email-masked]>, 'q11/15' <[email-masked]>
Subject: RESEND: Re: [IP-Optical] concatenation extensions in sonet/sdh
Date: Fri, 18 May 2001 10:53:08 -0400

Apologies for the re-send...sent this last message 
from my non-standard account ;)

Paul

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Friday, May 18, 2001 10:31 AM
To: Paul Bonenfant
Subject: BOUNCE [email-masked]: Non-member submission from [Paul
Bonenfant <[email-masked]>] 

you must post from your subscription address

randy

------- start of forwarded message -------
From: Paul Bonenfant <[email-masked]>
To: Zhi-Wei Lin <[email-masked]>
CC: Paul Bonenfant <[email-masked]>,
 	"'Bernstein, Greg'" <[email-masked]>,
 	'Steve West' <[email-masked]>,
 	'Stephen Trowbridge' <[email-masked]>,
 	[email-masked], [email-masked],
 	"t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi Zhi,

Well, misplaced/disgusting metaphors notwithstanding (my apologies,
must have been the waning hours of a long day!), I think we agree.

This is about what to include, and not to include, in the GMPLS 
signaling spec for SONET/SDH.  This isn't an issue of crystal ball 
gazing, it's an issue of pre- "standard" (transparent service) and 
perhaps even "re-visited"/post-standard (arbitrary concatenation)
commercial implementations. 

Let's not get lost in standards purism -- if full interoperability
were always required, we never would have standardized SONET BLSRs 
and SDH MS/SPRINGs.  Standardize to a level of commonality among
vendors and allow proprietary extensions for differentiation, but
don't preclude commercially implemented features in that vein. If
this is in keeping with your option (4), great.  If not, either we 
need another option, or the utility of the spec will be lessened, 
in my view -- call me a "reformed" standards purist (smile). 

Paul   

Zhi-Wei Lin wrote:
> 
> Hi Paul,
> 
> I'll have to disagree. I thought the discussion thus far have been what
> is arbitrary and what is virtual, its capabilities, how to handle
> support, what actions need to be taken to allow support.
> 
> I don't see that as hurling dung in Greg's direction. If this were the
> case or if some folks interpret it that way, then let me be the first to
> apologize to Greg (sorry!). There was no intention in my part to hurl
> dung (I think that's disgusting, yuk...I'll have to go wash my hands
> just thinking about it ;-)
> 
> As for transparency and the rest, right. So as you said, the question we
> should ask ourselves is:
> 
> 1) Should we add extensions to GMPLS for capabilities not standardized
> 2) Should we pre-empt standards and add capabilities that are not yet
> standardized
> 3) If 2) is yes, should we add capabilities that we "think" will be
> standardized. What about capabilities where we have no opinion or we
> think will not be standardized (folks, bring out your crystal ball!)
> 4) Should we stick strictly with standards-compliant capabilities and
> include extensions to allow ease of extending the signalling mechanism
> (Deborah's point). Add these in the future once it is standardized.
> 
> OK. Now let's hurl some dung in some other direction other than Greg!
> ;-)
> 
> Zhi
> 
> Paul Bonenfant wrote:
> >
> > We seem to be hurling generous amounts of dung
> > in Greg's general direction for proposing that
> > GMPLS handle "non-standard" SONET/SDH features.
> > This begs a question (well, at least one)...
> >
> > Mind you, I've not been _actively_ engaged in
> > the T1X1 & ITU discussions of late, but where,
> > for example, is the the notion of "transparency"
> > defined in T1X1/ITU SONET/SDH specs, c.f. the
> > discussion of various transparency flags in
> > section 2.1 of draft-ietf-ccamp-gmpls-sonet-sdh-00?
> >
> > By the same arguments, should this too be removed
> > from the spec and left to "proprietary" extensions,
> > until such time as the experts have validated its
> > applicability (as opposed to, let's say, the market)?
> >
> > Paul
> >
> > -----Original Message-----
> > From: Bernstein, Greg [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2001 5:58 PM
> > To: 'Steve West'; 'Stephen Trowbridge'
> > Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
> > [email-masked]; [email-masked]; t1x1.5; q11/15
> > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> >
> > Why don't we just remove the contiguous arbitrary concatenation from the
> > GMPLS specification  since it's not standard and doesn't offer any value
> > that I can see.  Anything else could be left for peoples proprietary
> > extensions:-)
> >
> > Greg B.
> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >         New phone: (510) 573-2237
> >

------- end of forwarded message -------

Delivery-date: Fri, 18 May 2001 06:41:56 -0700
From: "Cheenu Srinivasan" <[email-masked]>
To: <[email-masked]>
Subject: GMPLS/RSVP-TE question
Date: Fri, 18 May 2001 09:40:54 -0400

Reading the GMPLS drafts I have a question about setting up a
generalized LSP with RSVP-TE. Consider the following network where
the control plane is distinct from a data plane which is IP unaware.

     D --- E
   /   \ /   \
  A =1= B =2= C

 --- represent control plane links
 =n= represent data plane links which cannot originate/terminate IP;
     n is the local ID for this link

We want to set up an LSP A-1-B-2-C and signal it via RSVP-TE. The ERO
should be (A-1, B-2, C). However, a Path message can only be sent
out link A-D and has to be routed towards B; it cannot be sent
down link 1 since 1 is not IP-capable. Is this ok? What kind of
Path state is created on D? Or, do we need to tunnel the Path
message to B directly? Will D change the PHOP object to point
to itself (we do not want D to change the contents of the ERO)? In
this case when B receives this message it will find that the
Path came to it from an interface that is not part of the ERO. Is
this an error?

Thanks,
Cheenu

Delivery-date: Fri, 18 May 2001 02:43:13 -0700
From: "Mak, L (Leen)" <[email-masked]>
To: "'Zhi-Wei Lin'" <[email-masked]>, Paul Bonenfant <[email-masked]>
Cc: "'Bernstein, Greg'" <[email-masked]>, "'Steve West'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>, "Mak, L (Leen)" <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Fri, 18 May 2001 11:42:25 +0200

I think Zhi brings us back to the question which started
this debate in the first place.
I would support Zhi's option 4).

That is, in the IETF doc(s), make a clear distinction between
the stuff supporting currently standardised SONET/SDH
transport capabilities and the stuff aimed at possible future 
extensions. The latter could be in an informational Annex 
or alike, and once ITU and/or T1 standardise a new 
transport capability, its related control stuff can easily be 
moved from the Annex to the body of the RFC.

We should avoid blurring the roles of the various standards 
bodies. This is not in the interest of the operators nor in 
the interest of the vendors, because spreading subjects 
over more bodies will only increase the risk of 
inconsistencies, misunderstandings etc, etc.

So ITU-T and T1X1 should remain the bodies where 
SONET/SDH transport capabilities are being proposed,
discussed, and standardised.
The IETF should remain the body where the GMPLS
capabilities, required to control those transport capabilities
are standardised. 
Their relation should be: "the transport capability gets
the control capability it needs", and not the other way
around. 

Leen Mak.

> -----Original Message-----
> From: Zhi-Wei Lin [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 1:46
>[...]
> As for transparency and the rest, right. So as you said, the 
> question we
> should ask ourselves is:
> 
> 1) Should we add extensions to GMPLS for capabilities not standardized
> 2) Should we pre-empt standards and add capabilities that are not yet
> standardized
> 3) If 2) is yes, should we add capabilities that we "think" will be
> standardized. What about capabilities where we have no opinion or we
> think will not be standardized (folks, bring out your crystal ball!)
> 4) Should we stick strictly with standards-compliant capabilities and
> include extensions to allow ease of extending the signalling mechanism
> (Deborah's point). Add these in the future once it is standardized.
> 
>[..]
> Zhi

Delivery-date: Fri, 18 May 2001 02:32:19 -0700
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [T1X1.5] Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes
Date: Fri, 18 May 2001 11:31:52 +0200

The interaction between control and management plane isn't defined yet (See the ongoing discussion). It is questionable for me if the traditional error performance and availability parameters are usefull for switched networks.
The ITU is working on G.optperf "Error and availability performance parameters and objectives for international paths within the Optical Transport Network (OTN)". I will sent you a copy directly.

Juergen

> -----Original Message-----
> From:	Richard W. Tibbs [SMTP:[email-masked]]
> Sent:	Friday, May 18, 2001 12:14 AM
> To:	Maarten Vissers
> Cc:	Alan J Weissberger; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject:	[T1X1.5] Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes
> 
> I am looking at failure/restoration issues in SDH/Sonet and optical.
> I am familiar with G.821, G.822 and G.826 which define delineation of available state
> for a link,
> and G.805/803/872.
> I am wondering several things, and any pointers in the right direction are
> appreciated:
> 1) Upon Mgmt plane deciding whether a link (trail, etc.) is down (e.g. via 10 SES per
> G.826) where is the interaction with the control plane defined in the ITU and/or IETF
> standards?
> 2) What are the relevant ITU specs for optical for availability "declaration" as well
> as mgmt-ctrl plane interaction? (G.8xx is for SDH/Sonet, but there seems to be a
> separate O.xxx series emerging.)
> 
> Thanks very much all. >>>> RWT
> 
> Maarten Vissers wrote:
> 
> > Alan,
> >
> > Concerning your 3rd item (TCM activation), the control plane should be
> > able to control this also for the case of SPCs and SCs. The control
> > plane will also have to control the TCM endpoint related MI_XXX
> > parameters.
> >
> > Regards,
> >
> > Maarten
> >
> > Alan J Weissberger wrote:
> > >
> > > All
> > >
> > > I agree with Tammy's remarks below regarding the jurisdiction of the control
> > > plane.  We do have a G.874 LL item on Interworking between Mgt and Control
> > > planes and this takes on more importance with soft PC's.  I see 3 critical
> > > interactions between these two planes:
> > >
> > > 1.  SPCs: management plane initiates connection, control plane (NNI sig &
> > > Routing) executes, then informs mgt plane of outcome of connection setup request
> > > (see attached illustration).  PM and fault management done in management plane
> > >
> > >
> > > 2.  Resiliency/ self healing: Management plane sets up connection, but control
> > > plane is notified of the path to do restoration on a hard failure.  Conversely,
> > > control plane sets up the connection, but management plane notified to do
> > > protection on a SONET/SDH path or line layer basis
> > >
> > > 3.  Control plane sets up an OTN connection, management plane is notified to
> > > activate G.709 TCM sessions (or they may be pre-allocated along predefined paths
> > >
> > > There are others as well, but I believe the above three are most important
> > >
> > > I suggest we address this "co-ordination between planes" issue on May 21-22,
> > > when we have the ASON discussions in Caracas.
> > >
> > > rgds
> > >
> > > alan W
> > >
> > > Quoting [email-masked]:
> > >
> > > > Shiva,
> > > > Traditionally, often different systems are responsible for different
> > > > management functions relating to the same resources.
> > > >
> > > > I think it is important to define and keep in mind scope.  For example,
> > > > as I currently understand it, the control plane is only required to
> > > > control path set-up within a single layer network (while interacting
> > > > with other layers as needed to do its job).
> > > >
> > > > Network/Service management (management plane) needs scope of all layers
> > > > and interfaces that cross administrative boundaries.
> > > >
> > > > My current view is that the control plane is mainly responsible for> 
> > > > connection set-up and tear-down (network engineering) and traffic
> > > > management for those resources it has been allocated.  If, for some
> > > > reason, it cannot do its' job (e.g. failure of a control channel), it
> > > > should be reporting such failures to the management plane.
> > > > Tammy
> > > > -----Original Message-----
> > > > From: ssnarayanan [mailto:[email-masked]]
> > > > Sent: Thursday, May 17, 2001 08:47
> > > > To: zwlin
> > > > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > > > tsg15q12; tsg15q14
> > > > Subject: Re: ASTN Layer Network Architecture
> > > >
> > > >
> > > > Tammy, Maarten and Zhi,
> > > >   Along the lines of Zhi's question, it is also fundamental to know
> > > > which plane "owns" the management responsibility for the connection,
> > > > e.g., if a SPC is setup, then is it the management plane which owns this
> > > > or the control plane.  The management plane initiates the request, but
> > > > the control plane executes the request via NNI signaling.  As far as I
> > > > see, if we resolve this issue, then we can get a better understanding of
> > > > what is meant by "migrating" a connection from the management plane to
> > > > the control plane control.
> > > >
> > > > Regards,
> > > > Shiva
> > > > ------------------
> > > > Sivakumar Sankaranarayanan
> > > > Member of Technical Staff
> > > > HO 3C-508A
> > > > Lucent Technologies,
> > > > 101 Crawfords Corner Road,
> > > > Holmdel, NJ 07733.
> > > >
> > > > Phone:        +1 732 949 5762
> > > > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > > > Email:        [email-masked]
> > > >
> > >
> > > Alan J Weissberger
> > > DCT
> > > 2013 Acacia CT
> > > Santa Clara, CA 95050-3482
> > > 1 408 588 6493
> > > Home email: [email-masked]
> > >
> > >   ------------------------------------------------------------------------
> > >                Name: SPCs.ppt
> > >    SPCs.ppt    Type: Microsoft PowerPoint Show (application/vnd.ms-powerpoint)
> > >            Encoding: base64
> 
> --
> Come to the networking industry's premier conference,
> OPNETWORK 2001 August 27 - August 31
> (http://www.opnet.com/opnetwork2001/home.html)
> and to OPNET's cutting-edge seminars
> (http://www.opnet.com/seminars.html)
>  << File: Card for Richard W. Tibbs >> 

Delivery-date: Fri, 18 May 2001 02:11:34 -0700
From: Heiles Juergen <[email-masked]>
To: "'Alan J Weissberger'" <[email-masked]>, Carmine Daloia <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: : ASTN Layer Network Architecture- Co-ordiantion between Cont rol &  Mgt Planes
Date: Fri, 18 May 2001 11:11:01 +0200

Akan,

I don't see your scenario that the management plane sets up explicitly a connection (configuration of each cross-connect) and the control plane does the restoration. As the control plane has to know about the apth in any case i norder to do restoration it should also setup the original apth as SPC. Your approach introduces unnecessary complexity.

Juergen

> -----Original Message-----
> From:	Alan J Weissberger [SMTP:[email-masked]]
> Sent:	Thursday, May 17, 2001 10:24 PM
> To:	Carmine Daloia
> Cc:	Alan J Weissberger; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject:	Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes
> 
> Hi Carmine
> 
> Thanks for your reply
> 
> 1.  There is a scenario where the Management plane (e.g. EMS  and/or NMS) sets 
> up the connection, but the control plane then does re-routing based restoration 
> over the NNI.  At least one network operator told me that they wanted to do that
> 
> 2.  What I meant to say was that the protection triggers would come from the 
> management plane (e.g. TCM threshold crossings, Loss of light/ loss of signal, 
> etc).  Restoration triggers could come from Physical layer or a higher layer
> 
> Carmine, are you going to Caracas?  I will be there, but not at June 4-7 Turin 
> meeting
> 
> rgds
> 
> alan W
> 
> Quoting Carmine Daloia <[email-masked]>:
> 
> > Hi Alan,
> > 
> > I agree there is need for management plane and control plane
> > interactions.  I am
> > a bit confused with your second example (Resiliency/Self-Healing)
> > though.
> > 
> > You indicate that Mangement Plane sets up connection, but control plane
> > is
> > notified of the path to do restoration on a hard failure. Are you
> > suggesting
> > that the control plane in this scenario would only be responsible for
> > restoration and not setting up the initial connection?
> > 
> > Also, you indicate that the control plane sets up the connection, but
> > the
> > management plane is notified to do protection on a SONET/SDH path or
> > line.  The
> > management plane is never notified to do protection. Protection (e.g.,
> > SNCP,
> > MS-SPRING) occurs in the transport plane.  So in this scenario, I am not
> > sure
> > what you mean by control plane and management plane interactions.
> > 
> > Carmine
> > 
> > Alan J Weissberger wrote:
> > > 
> > > All
> > > 
> > > I agree with Tammy's remarks below regarding the jurisdiction of the
> > control
> > > plane.  We do have a G.874 LL item on Interworking between Mgt and
> > Control
> > > planes and this takes on more importance with soft PC's.  I see 3
> > critical
> > > interactions between these two planes:
> > > 
> > > 1.  SPCs: management plane initiates connection, control plane (NNI
> > sig &
> > > Routing) executes, then informs mgt plane of outcome of connection
> > setup request
> > > (see attached illustration).  PM and fault management done in
> > management plane
> > > 
> > > 
> > > 2.  Resiliency/ self healing: Management plane sets up connection, but
> > control
> > > plane is notified of the path to do restoration on a hard failure. 
> > Conversely,
> > > control plane sets up the connection, but management plane notified to
> > do
> > > protection on a SONET/SDH path or line layer basis
> > > 
> > > 3.  Control plane sets up an OTN connection, management plane is
> > notified to
> > > activate G.709 TCM sessions (or they may be pre-allocated along
> > predefined paths
> > > 
> > > There are others as well, but I believe the above three are most
> > important
> > > 
> > > I suggest we address this "co-ordination between planes" issue on May
> > 21-22,
> > > when we have the ASON discussions in Caracas.
> > > 
> > > rgds
> > > 
> > > alan W
> > > 
> > > Quoting [email-masked]:> 
> > > 
> > > > Shiva,
> > > > Traditionally, often different systems are responsible for different
> > > > management functions relating to the same resources.
> > > >
> > > > I think it is important to define and keep in mind scope.  For
> > example,
> > > > as I currently understand it, the control plane is only required to
> > > > control path set-up within a single layer network (while interacting
> > > > with other layers as needed to do its job).
> > > >
> > > > Network/Service management (management plane) needs scope of all
> > layers
> > > > and interfaces that cross administrative boundaries.
> > > >
> > > > My current view is that the control plane is mainly responsible for
> > > > connection set-up and tear-down (network engineering) and traffic
> > > > management for those resources it has been allocated.  If, for some
> > > > reason, it cannot do its' job (e.g. failure of a control channel),
> > it
> > > > should be reporting such failures to the management plane.
> > > > Tammy
> > > > -----Original Message-----
> > > > From: ssnarayanan [mailto:[email-masked]]
> > > > Sent: Thursday, May 17, 2001 08:47
> > > > To: zwlin
> > > > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > > > tsg15q12; tsg15q14
> > > > Subject: Re: ASTN Layer Network Architecture
> > > >
> > > >
> > > > Tammy, Maarten and Zhi,
> > > >   Along the lines of Zhi's question, it is also fundamental to know
> > > > which plane "owns" the management responsibility for the connection,
> > > > e.g., if a SPC is setup, then is it the management plane which owns
> > this
> > > > or the control plane.  The management plane initiates the request,
> > but
> > > > the control plane executes the request via NNI signaling.  As far as
> > I
> > > > see, if we resolve this issue, then we can get a better
> > understanding of
> > > > what is meant by "migrating" a connection from the management plane
> > to
> > > > the control plane control.
> > > >
> > > > Regards,
> > > > Shiva
> > > > ------------------
> > > > Sivakumar Sankaranarayanan
> > > > Member of Technical Staff
> > > > HO 3C-508A
> > > > Lucent Technologies,
> > > > 101 Crawfords Corner Road,
> > > > Holmdel, NJ 07733.
> > > >
> > > > Phone:        +1 732 949 5762
> > > > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > > > Email:        [email-masked]
> > > >
> > > 
> > > Alan J Weissberger
> > > DCT
> > > 2013 Acacia CT
> > > Santa Clara, CA 95050-3482
> > > 1 408 588 6493
> > > Home email: [email-masked]
> > > 
> > >  
> > ------------------------------------------------------------------------------
> --
> > >                Name: SPCs.ppt
> > >    SPCs.ppt    Type: Microsoft PowerPoint Show
> > (application/vnd.ms-powerpoint)
> > >            Encoding: base64
> > 
> 
> 
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: [email-masked]
> 1 408 588 6493
> [email-masked]

Delivery-date: Fri, 18 May 2001 01:57:51 -0700
From: Heiles Juergen <[email-masked]>
To: "'Krishna Pattabhiraman'" <[email-masked]>, "'Bernstein, Greg'" <[email-masked]>, "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Fri, 18 May 2001 10:57:11 +0200

Krishna,

your proposal applies to virtual concatenation I assume.
First concatenation of mixed size signals can get tricky due to the non-uniform distribution of the client signal over these signals, specially if the bandwidth factor between these signals is a non-integer number.
As one can use virtual cocnatenation of 7 STS-1-SPE instead of virtual cocnatenation of 2 STS-3c-SPE + 1 STS-1 SPE I don't see an advantage in your proposal.

Juergen

> -----Original Message-----
> From:	Krishna Pattabhiraman [SMTP:[email-masked]]
> Sent:	Thursday, May 17, 2001 9:19 PM
> To:	'Bernstein, Greg'; 'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'
> Cc:	'Maarten Vissers'; Anup Tirumala; [email-masked]; [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:	RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
> 
> Hello Gents,
> I agree that arbitrary concatenation would be the most preferrable, however
> that requires change in the framers at the intermediate nodes along the
> path. 
> 
> How about this compromise option: 
> Currently a SONET VC path has "same-sized" signals making up the
> concatenated streams - i.e., 
> For a HO vc stream VC-N-Xc, 
>  for all i, s.t., 1 <= i <= X, N is the same.
> 
> I was wondering what stops us from making it more generic and allow N to be
> {1 or 3} This will provide much more flexibility with a little modification
> in the H4 header - where for each member stream, we assign a byte (or some
> bits) to identify whether this member stream is a
> STS-1 or STS-3c ....
>  
> I see this especially useful when applied in the context of LCAS - where
> increase/decrease in BW could happen in STS-1 or STS-3c chunks? It also will
> be helpful in "path selection". For example, if we needed a STS-3c path
> across the network, and there were no single path available with that
> capacity, it may be possible to distribute it across 3 STS-1s. Of course,
> there is a mismatch in the capacity of a STS-3c and 3 STS-1s. Care has to be
> taken when we use one to replace the other.
> 
> Of course, mixing is not possible for SDH, VC3 being in LO and VC4 being in
> HO requires Hi-LO crossconnect functions. I was thinking more about SONET.
> 
> Support for mix VC scheme requires changes only at the end nodes of a path. 
> 
> Krishna 
> 
> 
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 2:52 PM
> To: 'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'
> Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in
> sonet/s dh
> 
> 
> Are we having fun for a Thursday, or what?
> Zhi, had me convinced that I should do a "start up" specializing in virtual
> concatenation for link bandwidth optimization, then Monica asked me about
> overhead use in arbitrary concatenation...
> Here are some more points:
> (1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE equipment
> and has nice consequences for avoiding re-grooming.
> (2)	Virtual concatenation is a whole new and useful feature that uses
> path level overhead, in particular the H4 byte.  Hence the path level BIP B3
> needs to recalculated.  This is more a PTE (path termination equipment) kind
> of thing to do.  Not something that a typical switch would necessarily want
> to do for compatibility purposes. This was intended for a much more
> sophisticated application, i.e., a path level "bonding" or inverse> 
> multiplexing, but it lacks path level transparency if used to avoid
> regrooming.
> 
> Hope this puts some more gasoline (petrol) onto the fire.
> 
> Greg B.
> 
> 	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
> 	New phone: (510) 573-2237
> 
> 
> 		-----Original Message-----
> 		From:	Lazer, Monica A, NNAD [mailto:[email-masked]]
> 		Sent:	Thursday, May 17, 2001 11:01 AM
> 		To:	Bernstein, Greg; 'Zhi-Wei Lin'
> 		Cc:	'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
> 		Subject:	RE: [T1X1.5] RE: [IP-Optical] concatenation
> extensions in sonet/s dh
> 
> 		Why wouldn't the 2 boxes in option 2 use virtual
> concatenation instead of
> 		arbitrary concatenation, though?
> 
> 		Monica A. Lazer
> 		Advanced Transport Technology and Architecture Planning
> 
> 		908 234 8462
> 		[email-masked]
> 
> 
> 		-----Original Message-----
> 		From: Bernstein, Greg [mailto:[email-masked]]
> 		Sent: Thursday, May 17, 2001 12:27 PM
> 		To: 'Zhi-Wei Lin'
> 		Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> 		[email-masked]; [email-masked]; t1x1.5;
> q11/15
> 		Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions
> in sonet/sdh
> 
> 		To avoid re-grooming either virtual concatenation or
> arbitrary concatenation
> 		can help, but the implications are quite different.
> 		Say we have a particularly valuable (expensive) link that we
> can't or don't
> 		want to re-groom then we have two options:
> 		(1)     Require that ALL end systems that could potentially
> use this link
> 		convert over to virtual concatenation from standard
> concatenation.
> 		(2)     Or, install boxes at both ends of the link that
> support the
> 		arbitrary concatenation that we've been discussing.
> 
> 		Which of these seems more realistic and practical?
> 		Greg B.
> 		        Dr. Greg M. Bernstein, Senior Scientist, Ciena
> 		        New phone: (510) 573-2237
> 
> 
> 		                -----Original Message-----
> 		                From:   Zhi-Wei Lin
> [mailto:[email-masked]]
> 		                Sent:   Thursday, May 17, 2001 8:41 AM
> 		                To:     Bernstein, Greg
> 		                Cc:     'Maarten Vissers'; Anup Tirumala;
> 		[email-masked]; [email-masked];
> [email-masked];
> 		t1x1.5; q11/15
> 		                Subject:        Re: [IP-Optical]
> concatenation extensions in
> 		sonet/sdh
> 
> 		                Hi,
> 
> 		                some observations:
> 
> 		                in terms of re-grooming and such, I believe
> both virtual
> 		concatenation
> 		                and arbitrary concatenation can perform
> this. One method is
> 		                standardized, the other is proprietary.
> 
> 		                In terms of routing of the individual
> connections that make
> 		up the
> 		                concatenated signal, virtual concatenation
> is more flexible
> 		than
> 		                arbitrary concatenation, since you can put
> each component VC
> 		in
> 		                different lines, and each component can be
> routed
> 		differently.
> 
> 		                In terms of interworking, yes the SIGNALLING
> can defnititely
> 		be made to
> 		                interwork. However, the larger issue for
> interworking is
> 		support by the
> 		                transport equipment themselves. Thus
> interworking involves
> 		TWO parts:
> 		                signaling interworking and transport
> interworking. Having
> 		one without
> 		                the other doesn't really help...
> 
> 		                Thus, in terms of solving real problems,
> either virtual or
> 		arbitrary can
> 		                accomplish that, but IMO, virtual seems more
> flexible...and
> 		                standardized...
> 
> 		                In terms of standards as fostering
> interoperability and
> 		stifling of
> 		                innovation, in principle yes I agree. And
> therefore if
> 		> arbitrary
> 		                concatenation should be standardized, it
> should be
> 		standardized in the
> 		                correct standards body. As Maarten
> mentioned, the relevant
> 		standards
> 		                bodies discussed arbitrary concatenation
> years ago, and
> 		decided
> 		                (hopefully based on their expert technical
> opinion - I
> 		wasn't involved)
> 		                not to include arbitrary but instead to
> include virtual.
> 		IMO, there must
> 		                be good reasons, and from what I can tell, I
> see virtual as
> 		been more
> 		                flexible so that is a pretty good
> reason...we at IETF, being
> 		protocol
> 		                experts (and budding transport experts?)
> should not try to
> 		second-guess
> 		                the decisions without fully understanding
> the
> 		ramifications...
> 
> 		                As for stifling innovation, anytime you
> standardize anything
> 		there is
> 		                always some factor of development that gets
> fixed (is this
> 		something
> 		                that should not be said in a public forum???
> -- sorry!!).
> 		Therefore
> 		                there is always a tradeoff between
> innovation and
> 		standardization. I
> 		                think the job of standards bodies is to try
> to balance these
> 		two factors
> 		                such that the industry in general can live
> with the result
> 		without
> 		                unduly burdening...
> 
> 		                agree?
> 
> 		                Zhi
> 
> 
> 
> 		                "Bernstein, Greg" wrote:
> 		                >
> 		                > A couple more points.
> 		                > (1)     GMPLS works well with arbitrary
> concatenations
> 		need to specify the
> 		                > time slots since it provides a signaling
> protocol that can
> 		do just that,
> 		                > i.e., GMPLS actually enables this feature
> to interoperate.
> 		                > (2)     Arbitrary concatenation offers a
> solution to a
> 		real problem, i.e.,
> 		                > eliminates the need for re-grooming on
> lines that support
> 		it.  For those who
> 		                > have invested non-trivial amounts of money
> in transoceanic
> 		links this can be
> 		                > a significant savings.
> 		                > (3)     The goal is interoperability and
> to solve real
> 		problems.  We've got
> 		                > a real problem and with a minor edit to
> the GMPLS SONET
> 		specification we can
> 		                > have an interoperable method for solving
> it.
> 		                >
> 		                > To be precise in the definition of
> arbitrary
> 		concatenation:
> 		                > As a concatenated signal within a single
> SONET Line (SDH
> 		MS), with
> 		                > potentially arbitrary timeslots used for
> its components.
> 		                >
> 		                > The current main application is: avoiding
> the need for
> 		service impacting
> 		                > re-grooming. Note that this applies to
> standard sized
> 		signals and is a per
> 		                > link property.
> 		                >
> 		                > Other applications do exist and are
> somewhat competitive
> 		with non-LCAS
> 		                > virtual concatenation since the
> implementation of
> 		arbitrary concatenation
> 		                > for odd sized signals is simpler than that
> of virtual
> 		concatenation.  Once
> 		                > "odd" sized signals are used an entire
> path through the
> 		network must exist
> 		                > that supports them.
> 		                >
> 		                > Folks I thought the role of standards
> organizations was to
> 		foster
> 		                > interoperability that enables the industry
> to move forward
> 		rather than as a
> 		                > means to stifle innovation. I think it is
> better for the> 
> 		> marketplace to
> 		                > decide which features are desirable.
> 		                >
> 		                > Greg B.
> 		                >
> 		                >         Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
> 		                >         New phone: (510) 573-2237
> 		                >

Delivery-date: Fri, 18 May 2001 01:48:18 -0700
From: Heiles Juergen <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Fri, 18 May 2001 10:46:06 +0200

Hi,

it seems I missed a lively discussion due to early knock off work. Instead I had a lively babysitter job at home;-)
Greg, one question about arbitrary concatenation configuration below.

Juergen

> -----Original Message-----
> From:	Bernstein, Greg [SMTP:[email-masked]]
> Sent:	Thursday, May 17, 2001 8:52 PM
> To:	'Lazer, Monica A, NNAD'; 'Zhi-Wei Lin'
> Cc:	'Maarten Vissers'; Anup Tirumala; [email-masked]; [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject:	RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
> 
> Are we having fun for a Thursday, or what?
> Zhi, had me convinced that I should do a "start up" specializing in virtual
> concatenation for link bandwidth optimization, then Monica asked me about
> overhead use in arbitrary concatenation...
> Here are some more points:
> (1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE equipment
> and has nice consequences for avoiding re-grooming.
	[Juergen Heiles]  How will you tell the framer the starting time slot and the remaining timeslots? Via TMN cnfiguration or GMPLS signaling? Not in-band using some SOH? If you also want to support the STS Group, AUG or partially transparent signal type defined in GMPLS you need the in-band information.

> (2)	Virtual concatenation is a whole new and useful feature that uses
> path level overhead, in particular the H4 byte.  Hence the path level BIP B3
> needs to recalculated.  This is more a PTE (path termination equipment) kind
> of thing to do.  Not something that a typical switch would necessarily want
> to do for compatibility purposes. This was intended for a much more
> sophisticated application, i.e., a path level "bonding" or inverse
> multiplexing, but it lacks path level transparency if used to avoid
> regrooming.
> 
> Hope this puts some more gasoline (petrol) onto the fire.
> 
> Greg B.
> 
> 	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
> 	New phone: (510) 573-2237
> 
> 
> 		-----Original Message-----
> 		From:	Lazer, Monica A, NNAD [mailto:[email-masked]]
> 		Sent:	Thursday, May 17, 2001 11:01 AM
> 		To:	Bernstein, Greg; 'Zhi-Wei Lin'
> 		Cc:	'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
> 		Subject:	RE: [T1X1.5] RE: [IP-Optical] concatenation
> extensions in sonet/s dh
> 
> 		Why wouldn't the 2 boxes in option 2 use virtual
> concatenation instead of
> 		arbitrary concatenation, though?
> 
> 		Monica A. Lazer
> 		Advanced Transport Technology and Architecture Planning
> 
> 		908 234 8462
> 		[email-masked]
> 
> 
> 		-----Original Message-----
> 		From: Bernstein, Greg [mailto:[email-masked]]
> 		Sent: Thursday, May 17, 2001 12:27 PM
> 		To: 'Zhi-Wei Lin'
> 		Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
> 		[email-masked]; [email-masked]; t1x1.5;
> q11/15
> 		Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions
> in sonet/sdh
> 
> 		To avoid re-grooming either virtual concatenation or
> arbitrary concatenation
> 		can help, but the implications are quite different.
> 		Say we have a particularly valuable (expensive) link that we
> can't or don't
> 		want to re-groom then we have two options:
> 		(1)     Require that ALL end systems that could potentially
> use this link
> 		convert over to virtual concatenation from standard
> concatenation.
> 		(2)     Or, install boxes at both ends of the link that
> support the
> 		arbitrary concatenation that we've been discussing.> 
> 
> 		Which of these seems more realistic and practical?
> 		Greg B.
> 		        Dr. Greg M. Bernstein, Senior Scientist, Ciena
> 		        New phone: (510) 573-2237
> 
> 
> 		                -----Original Message-----
> 		                From:   Zhi-Wei Lin
> [mailto:[email-masked]]
> 		                Sent:   Thursday, May 17, 2001 8:41 AM
> 		                To:     Bernstein, Greg
> 		                Cc:     'Maarten Vissers'; Anup Tirumala;
> 		[email-masked]; [email-masked];
> [email-masked];
> 		t1x1.5; q11/15
> 		                Subject:        Re: [IP-Optical]
> concatenation extensions in
> 		sonet/sdh
> 
> 		                Hi,
> 
> 		                some observations:
> 
> 		                in terms of re-grooming and such, I believe
> both virtual
> 		concatenation
> 		                and arbitrary concatenation can perform
> this. One method is
> 		                standardized, the other is proprietary.
> 
> 		                In terms of routing of the individual
> connections that make
> 		up the
> 		                concatenated signal, virtual concatenation
> is more flexible
> 		than
> 		                arbitrary concatenation, since you can put
> each component VC
> 		in
> 		                different lines, and each component can be
> routed
> 		differently.
> 
> 		                In terms of interworking, yes the SIGNALLING
> can defnititely
> 		be made to
> 		                interwork. However, the larger issue for
> interworking is
> 		support by the
> 		                transport equipment themselves. Thus
> interworking involves
> 		TWO parts:
> 		                signaling interworking and transport
> interworking. Having
> 		one without
> 		                the other doesn't really help...
> 
> 		                Thus, in terms of solving real problems,
> either virtual or
> 		arbitrary can
> 		                accomplish that, but IMO, virtual seems more
> flexible...and
> 		                standardized...
> 
> 		                In terms of standards as fostering
> interoperability and
> 		stifling of
> 		                innovation, in principle yes I agree. And
> therefore if
> 		arbitrary
> 		                concatenation should be standardized, it
> should be
> 		standardized in the
> 		                correct standards body. As Maarten
> mentioned, the relevant
> 		standards
> 		                bodies discussed arbitrary concatenation
> years ago, and
> 		decided
> 		                (hopefully based on their expert technical
> opinion - I
> 		wasn't involved)
> 		                not to include arbitrary but instead to
> include virtual.
> 		IMO, there must
> 		                be good reasons, and from what I can tell, I
> see virtual as
> 		been more
> 		                flexible so that is a pretty good
> reason...we at IETF, being
> 		protocol
> 		                experts (and budding transport experts?)
> should not try to
> 		second-guess
> 		                the decisions without fully understanding
> the
> 		ramifications...
> 
> 		                As for stifling innovation, anytime you
> standardize anything
> 		there is
> 		                always some factor of development that gets
> fixed (is this
> 		something
> 		                that should not be said in a public forum???
> -- sorry!!).
> 		Therefore
> 		                there is always a tradeoff between
> innovation and
> 		standardization. I
> 		                think the job of standards bodies is to try
> to balance these
> 		two factors
> 		                such that the industry in general can live
> with the result
> 		without
> 		                unduly burdening...
> 
> 		                agree?
> 
> 		                Zhi
> 
> 
> 
> 		                "Bernstein, Greg" wrote:
> 		                >
> 		                > A couple more points.
> 		                > (1)     GMPLS works well with arbitrary
> concatenations
> 		need to specify the
> 		                > time slots since it provides a signaling> 
> protocol that can
> 		do just that,
> 		                > i.e., GMPLS actually enables this feature
> to interoperate.
> 		                > (2)     Arbitrary concatenation offers a
> solution to a
> 		real problem, i.e.,
> 		                > eliminates the need for re-grooming on
> lines that support
> 		it.  For those who
> 		                > have invested non-trivial amounts of money
> in transoceanic
> 		links this can be
> 		                > a significant savings.
> 		                > (3)     The goal is interoperability and
> to solve real
> 		problems.  We've got
> 		                > a real problem and with a minor edit to
> the GMPLS SONET
> 		specification we can
> 		                > have an interoperable method for solving
> it.
> 		                >
> 		                > To be precise in the definition of
> arbitrary
> 		concatenation:
> 		                > As a concatenated signal within a single
> SONET Line (SDH
> 		MS), with
> 		                > potentially arbitrary timeslots used for
> its components.
> 		                >
> 		                > The current main application is: avoiding
> the need for
> 		service impacting
> 		                > re-grooming. Note that this applies to
> standard sized
> 		signals and is a per
> 		                > link property.
> 		                >
> 		                > Other applications do exist and are
> somewhat competitive
> 		with non-LCAS
> 		                > virtual concatenation since the
> implementation of
> 		arbitrary concatenation
> 		                > for odd sized signals is simpler than that
> of virtual
> 		concatenation.  Once
> 		                > "odd" sized signals are used an entire
> path through the
> 		network must exist
> 		                > that supports them.
> 		                >
> 		                > Folks I thought the role of standards
> organizations was to
> 		foster
> 		                > interoperability that enables the industry
> to move forward
> 		rather than as a
> 		                > means to stifle innovation. I think it is
> better for the
> 		marketplace to
> 		                > decide which features are desirable.
> 		                >
> 		                > Greg B.
> 		                >
> 		                >         Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
> 		                >         New phone: (510) 573-2237
> 		                >
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Thu, 17 May 2001 16:46:38 -0700
Date: Thu, 17 May 2001 19:45:57 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Paul Bonenfant <[email-masked]>
CC: "'Bernstein, Greg'" <[email-masked]>, "'Steve West'" <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi Paul,

I'll have to disagree. I thought the discussion thus far have been what
is arbitrary and what is virtual, its capabilities, how to handle
support, what actions need to be taken to allow support. 

I don't see that as hurling dung in Greg's direction. If this were the
case or if some folks interpret it that way, then let me be the first to
apologize to Greg (sorry!). There was no intention in my part to hurl
dung (I think that's disgusting, yuk...I'll have to go wash my hands
just thinking about it ;-)

As for transparency and the rest, right. So as you said, the question we
should ask ourselves is:

1) Should we add extensions to GMPLS for capabilities not standardized
2) Should we pre-empt standards and add capabilities that are not yet
standardized
3) If 2) is yes, should we add capabilities that we "think" will be
standardized. What about capabilities where we have no opinion or we
think will not be standardized (folks, bring out your crystal ball!)
4) Should we stick strictly with standards-compliant capabilities and
include extensions to allow ease of extending the signalling mechanism
(Deborah's point). Add these in the future once it is standardized.

OK. Now let's hurl some dung in some other direction other than Greg!
;-)

Zhi

Paul Bonenfant wrote:
> 
> We seem to be hurling generous amounts of dung
> in Greg's general direction for proposing that
> GMPLS handle "non-standard" SONET/SDH features.
> This begs a question (well, at least one)...
> 
> Mind you, I've not been _actively_ engaged in
> the T1X1 & ITU discussions of late, but where,
> for example, is the the notion of "transparency"
> defined in T1X1/ITU SONET/SDH specs, c.f. the
> discussion of various transparency flags in
> section 2.1 of draft-ietf-ccamp-gmpls-sonet-sdh-00?
> 
> By the same arguments, should this too be removed
> from the spec and left to "proprietary" extensions,
> until such time as the experts have validated its
> applicability (as opposed to, let's say, the market)?
> 
> Paul
> 
> -----Original Message-----
> From: Bernstein, Greg [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 5:58 PM
> To: 'Steve West'; 'Stephen Trowbridge'
> Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
> [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> 
> Why don't we just remove the contiguous arbitrary concatenation from the
> GMPLS specification  since it's not standard and doesn't offer any value
> that I can see.  Anything else could be left for peoples proprietary
> extensions:-)
> 
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Steve West [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 12:52 PM
>                 To:     'Stephen Trowbridge'; Bernstein, Greg
>                 Cc:     'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        RE: [IP-Optical] concatenation extensions in
> sonet/sdh
> 
>                 Greg:
> 
>                 It seems that you have a scheme that allows better
> utilization of a link by
>                 including a new type of concatenation hardware, just at the
> ends of that
>                 link.  If I understand, the concatenation method allows you
> to remove the
>                 requirement for "contiguous" sts1/columns in the SONET/SDH
> payload, by
>                 "leap-frogging" over columns that are in-use and thus
> "in-the-way" ?
> 
>                 If my read is right, why not also present this "leap-frog"
> arbitrary
>                 concatenation scheme to the relevent standards authorities
> (ANSI/ETSI/ITU),
>                 so that the experts there can validate its applicability?
> 
>                 Steve West
> 
>                 -----Original Message-----
>                 From: Stephen Trowbridge [mailto:[email-masked]]
>                 Sent: Thursday, May 17, 2001 11:39 AM
>                 To: Bernstein, Greg
>                 Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
> [email-masked];
>                 [email-masked]; [email-masked]; t1x1.5;
> q11/15
>                 Subject: Re: [IP-Optical] concatenation extensions in
> sonet/sdh
> 
>                 There is no intent in any of the standardization bodies to
> stifle
>                 innovation. Standards are contribution driven, and what you
> find
>                 in the documents as written are the product of those
> contributions.
> 
>                 If the desire is to extend current SONET/SDH with an
> arbitrary
>                 concatenation feature, there is no problem to contribute to
> T1X1
>                 and/or ITU-T to propose this extension. This is the correct
> way to
>                 approach it. The INCORRECT way is to confuse the market by
> producing
>                 an IETF version of SONET/SDH specs that is different from
> T1X1/ITU-T.
> 
>                 Let me add some background on how we ended up with the
> current
>                 situation recommending virtual concatenation in SONET/SDH:
> 
>                 1. Contiguous or Arbitrary concatenation requires
> implementation
>                 of the concatenation method at every NE along the chosen
> path
>                 through the network to provide a service. At the time we
> began
>                 these discussions, we had the problem that ATM wanted to use
>                 VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
>                 links in the network and NEs that didn't support trails
>                 bigger than VC-4 (STS-3c). By now, of course, VC-4-4c
> (STS-12c)
>                 and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
>                 but as has been observed in previous emails, it will be a
>                 long time before you replace all of the 2.5G links in the
>                 network, so contiguous/arbitrary concatenation to greater
>                 than VC-4-16c/STS-48c is still a problem for some time to
>                 come. The endpoints in a network always seem to evolve ahead
>                 of and faster than links and equipment in the core network
>                 can be replaced, so it was important to define a
> concatenation
>                 method that could be implemented only by the endpoints.
> 
>                 2. Contiguous/arbitrary concatenation is not as elgant for
>                 lower order paths as for higher order paths. We saw in
>                 a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
>                 into an STM-1, but most equipment does not provide the
>                 ability to concatenate lower order paths. For certain
>                 payloads, lower order paths fit better, e.g., 5 x VC-12
>                 to carry 10Mb Ethernet.
> 
>                 3. Different payloads to not fit ideally into "standard"
>                 multiples found in contiguous concatenation (4, 16, 64,
>                 256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
>                 fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.
> 
>                 4. As paths are set up or taken down in a network, there is
>                 a tendency for capacity to become fragmented. Contiguous/
>                 arbitrary concatenation cannot always take advantage of
>                 free timeslots along a span if they are not adjacent on
>                 the same fiber or if they are on different fibers.
> 
>                 5. LCAS was easier to envision in a virtual concatenation
>                 environment. Many of the new services are not inherently
>                 constant bit rate, and it can be useful to dynamically
>                 add or remove components of the bundle to adjust link
>                 capacity. It is also useful to be able to handle failures
>                 of individual components of the concatenated trail by
>                 just reducing the capacity rather than by having to
>                 protection switch the entire path.
> 
>                 Virtual concatenation was designed to solve all of the above
>                 problems. Arbitrary concatenation is another way to solve
>                 problem (3) above, but it doesn't solve the others. Given
>                 that virtual concatenation is standardized to solve all
>                 of the problems, it reduces the pressure to implement
>                 arbitrary concatenation throughout the network to solve
>                 only problem (3).
> 
>                 If problem (3) is the only one you are trying to solve,
>                 arbitrary concatenation has the advantage of not requiring
>                 so much buffer space at the endpoints to accomodate
>                 differential delay. But with trends in memory costs, this
>                 is not so much of an issue, and this needs to be traded
>                 off against the need to provide support for the contiguous/
>                 arbitrary rate and all associated protection mechanisms at
>                 EVERY NE along the chosen path in the network in order for
>                 this to work.
> 
>                 If there is a significant market for applications where
>                 solving (3) is vital but (1,2,4,5) are not so important,
>                 then it may be worth pushing arbitrary concatenation as
>                 a way to optimize how those services are provided over
>                 what you get with virtual concatenation.
> 
>                 Regards,
>                 Steve Trowbridge
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > To avoid re-grooming either virtual concatenation or
> arbitrary
>                 concatenation
>                 > can help, but the implications are quite different.
>                 > Say we have a particularly valuable (expensive) link that
> we can't or
>                 don't
>                 > want to re-groom then we have two options:
>                 > (1)     Require that ALL end systems that could
> potentially use this link
>                 > convert over to virtual concatenation from standard
> concatenation.
>                 > (2)     Or, install boxes at both ends of the link that
> support the
>                 > arbitrary concatenation that we've been discussing.
>                 >
>                 > Which of these seems more realistic and practical?
>                 > Greg B.
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >
>                 >                 -----Original Message-----
>                 >                 From:   Zhi-Wei Lin
> [mailto:[email-masked]]
>                 >                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 >                 To:     Bernstein, Greg
>                 >                 Cc:     'Maarten Vissers'; Anup Tirumala;
>                 > [email-masked]; [email-masked];
> [email-masked];
>                 > t1x1.5; q11/15
>                 >                 Subject:        Re: [IP-Optical]
> concatenation extensions
>                 in
>                 > sonet/sdh
>                 >
>                 >                 Hi,
>                 >
>                 >                 some observations:
>                 >
>                 >                 in terms of re-grooming and such, I
> believe both virtual
>                 > concatenation
>                 >                 and arbitrary concatenation can perform
> this. One method
>                 is
>                 >                 standardized, the other is proprietary.
>                 >
>                 >                 In terms of routing of the individual
> connections that
>                 make
>                 > up the
>                 >                 concatenated signal, virtual concatenation
> is more
>                 flexible
>                 > than
>                 >                 arbitrary concatenation, since you can put
> each component
>                 VC
>                 > in
>                 >                 different lines, and each component can be
> routed
>                 > differently.
>                 >
>                 >                 In terms of interworking, yes the
> SIGNALLING can
>                 defnititely
>                 > be made to
>                 >                 interwork. However, the larger issue for
> interworking is
>                 > support by the
>                 >                 transport equipment themselves. Thus
> interworking involves
>                 > TWO parts:
>                 >                 signaling interworking and transport
> interworking. Having
>                 > one without
>                 >                 the other doesn't really help...
>                 >
>                 >                 Thus, in terms of solving real problems,
> either virtual or
>                 > arbitrary can
>                 >                 accomplish that, but IMO, virtual seems
> more
>                 flexible...and
>                 >                 standardized...
>                 >
>                 >                 In terms of standards as fostering
> interoperability and
>                 > stifling of
>                 >                 innovation, in principle yes I agree. And
> therefore if
>                 > arbitrary
>                 >                 concatenation should be standardized, it
> should be
>                 > standardized in the
>                 >                 correct standards body. As Maarten
> mentioned, the relevant
>                 > standards
>                 >                 bodies discussed arbitrary concatenation
> years ago, and
>                 > decided
>                 >                 (hopefully based on their expert technical
> opinion - I
>                 > wasn't involved)
>                 >                 not to include arbitrary but instead to
> include virtual.
>                 > IMO, there must
>                 >                 be good reasons, and from what I can tell,
> I see virtual
>                 as
>                 > been more
>                 >                 flexible so that is a pretty good
> reason...we at IETF,
>                 being
>                 > protocol
>                 >                 experts (and budding transport experts?)
> should not try to
>                 > second-guess
>                 >                 the decisions without fully understanding
> the
>                 > ramifications...
>                 >
>                 >                 As for stifling innovation, anytime you
> standardize
>                 anything
>                 > there is
>                 >                 always some factor of development that
> gets fixed (is this
>                 > something
>                 >                 that should not be said in a public
> forum??? -- sorry!!).
>                 > Therefore
>                 >                 there is always a tradeoff between
> innovation and
>                 > standardization. I
>                 >                 think the job of standards bodies is to
> try to balance
>                 these
>                 > two factors
>                 >                 such that the industry in general can live
> with the result
>                 > without
>                 >                 unduly burdening...
>                 >
>                 >                 agree?
>                 >
>                 >                 Zhi
>                 >
>                 >                 "Bernstein, Greg" wrote:
>                 >                 >
>                 >                 > A couple more points.
>                 >                 > (1)     GMPLS works well with arbitrary
> concatenations
>                 > need to specify the
>                 >                 > time slots since it provides a signaling
> protocol that
>                 can
>                 > do just that,
>                 >                 > i.e., GMPLS actually enables this
> feature to
>                 interoperate.
>                 >                 > (2)     Arbitrary concatenation offers a
> solution to a
>                 > real problem, i.e.,
>                 >                 > eliminates the need for re-grooming on
> lines that
>                 support
>                 > it.  For those who
>                 >                 > have invested non-trivial amounts of
> money in
>                 transoceanic
>                 > links this can be
>                 >                 > a significant savings.
>                 >                 > (3)     The goal is interoperability and
> to solve real
>                 > problems.  We've got
>                 >                 > a real problem and with a minor edit to
> the GMPLS SONET
>                 > specification we can
>                 >                 > have an interoperable method for solving
> it.
>                 >                 >
>                 >                 > To be precise in the definition of
> arbitrary
>                 > concatenation:
>                 >                 > As a concatenated signal within a single
> SONET Line (SDH
>                 > MS), with
>                 >                 > potentially arbitrary timeslots used for
> its components.
>                 >                 >
>                 >                 > The current main application is:
> avoiding the need for
>                 > service impacting
>                 >                 > re-grooming. Note that this applies to
> standard sized
>                 > signals and is a per
>                 >                 > link property.
>                 >                 >
>                 >                 > Other applications do exist and are
> somewhat competitive
>                 > with non-LCAS
>                 >                 > virtual concatenation since the
> implementation of
>                 > arbitrary concatenation
>                 >                 > for odd sized signals is simpler than
> that of virtual
>                 > concatenation.  Once
>                 >                 > "odd" sized signals are used an entire
> path through the
>                 > network must exist
>                 >                 > that supports them.
>                 >                 >
>                 >                 > Folks I thought the role of standards
> organizations was
>                 to
>                 > foster
>                 >                 > interoperability that enables the
> industry to move
>                 forward
>                 > rather than as a
>                 >                 > means to stifle innovation. I think it
> is better for the
>                 > marketplace to
>                 >                 > decide which features are desirable.
>                 >                 >
>                 >                 > Greg B.
>                 >                 >
>                 >                 >         Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
>                 >                 >         New phone: (510) 573-2237
>                 >                 >
> 
> _______________________________________________
> IP-Optical mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Thu, 17 May 2001 16:30:04 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: GMPLS Message Structures
Date: Thu, 17 May 2001 16:29:05 -0700

Hi All,

            Can someone tell me the message structure of Label Request and 
Label Mapping in GMPLS ?
I am confused about the presence of LightPath Id in O-UNI messages and LSP 
Id in GMPLS messages ? Is there one-to-one mapping between these Ids or Is 
it like that both lightPath Id and LSP Id will be carried in GMPLS messages 
? LSP Id is not present in O-UNI messages. Can one LightPath Id be mapped to 
multiple LSP Ids or vice versa ?

Also, for waveband switching, the genralized label has the format 
(wavebandId - start label - end label).
When the label request message is received on incoming interface, how to 
identify that the waveband label is requested ?
Is it the LSP encoding type or some other parameter in label request message 
? If it is the Lambda encoding type then how to identify that whether a 
lambda or waveband label is requested ?

Also, it is mentioned that wavebandId (32 bits) is selected by the sender 
and reused in all the subsequent messages. What all subsequent
messages is it mentioning to ?

Can wavebandId be present in Label Withdraw/Release messages ?

I am not able to workout the message structures for GMPLS.

I am not sure how these drafts are at last call. Atleast it should mention 
the message structures of various messages.

Please help.

Thanks,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Thu, 17 May 2001 15:43:29 -0700
From: Paul Bonenfant <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, 'Steve West' <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 18:41:52 -0400

We seem to be hurling generous amounts of dung
in Greg's general direction for proposing that
GMPLS handle "non-standard" SONET/SDH features.
This begs a question (well, at least one)...  

Mind you, I've not been _actively_ engaged in 
the T1X1 & ITU discussions of late, but where,
for example, is the the notion of "transparency" 
defined in T1X1/ITU SONET/SDH specs, c.f. the 
discussion of various transparency flags in 
section 2.1 of draft-ietf-ccamp-gmpls-sonet-sdh-00?  

By the same arguments, should this too be removed
from the spec and left to "proprietary" extensions, 
until such time as the experts have validated its 
applicability (as opposed to, let's say, the market)? 

Paul

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 5:58 PM
To: 'Steve West'; 'Stephen Trowbridge'
Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
[email-masked]; [email-masked]; t1x1.5; q11/15
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh

Why don't we just remove the contiguous arbitrary concatenation from the
GMPLS specification  since it's not standard and doesn't offer any value
that I can see.  Anything else could be left for peoples proprietary
extensions:-)

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Steve West [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 12:52 PM
		To:	'Stephen Trowbridge'; Bernstein, Greg
		Cc:	'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	RE: [IP-Optical] concatenation extensions in
sonet/sdh

		Greg:

		It seems that you have a scheme that allows better
utilization of a link by
		including a new type of concatenation hardware, just at the
ends of that
		link.  If I understand, the concatenation method allows you
to remove the
		requirement for "contiguous" sts1/columns in the SONET/SDH
payload, by
		"leap-frogging" over columns that are in-use and thus
"in-the-way" ?  

		If my read is right, why not also present this "leap-frog"
arbitrary
		concatenation scheme to the relevent standards authorities
(ANSI/ETSI/ITU),
		so that the experts there can validate its applicability?

		Steve West

		-----Original Message-----
		From: Stephen Trowbridge [mailto:[email-masked]]
		Sent: Thursday, May 17, 2001 11:39 AM
		To: Bernstein, Greg
		Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
[email-masked];
		[email-masked]; [email-masked]; t1x1.5;
q11/15
		Subject: Re: [IP-Optical] concatenation extensions in
sonet/sdh

		There is no intent in any of the standardization bodies to
stifle
		innovation. Standards are contribution driven, and what you
find
		in the documents as written are the product of those
contributions.

		If the desire is to extend current SONET/SDH with an
arbitrary
		concatenation feature, there is no problem to contribute to
T1X1
		and/or ITU-T to propose this extension. This is the correct
way to
		approach it. The INCORRECT way is to confuse the market by
producing
		an IETF version of SONET/SDH specs that is different from
T1X1/ITU-T.

		Let me add some background on how we ended up with the
current
		situation recommending virtual concatenation in SONET/SDH:

		1. Contiguous or Arbitrary concatenation requires
implementation
		of the concatenation method at every NE along the chosen
path
		through the network to provide a service. At the time we
began
		these discussions, we had the problem that ATM wanted to use
		VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
		links in the network and NEs that didn't support trails
		bigger than VC-4 (STS-3c). By now, of course, VC-4-4c
(STS-12c)
		and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
		but as has been observed in previous emails, it will be a
		long time before you replace all of the 2.5G links in the
		network, so contiguous/arbitrary concatenation to greater
		than VC-4-16c/STS-48c is still a problem for some time to
		come. The endpoints in a network always seem to evolve ahead
		of and faster than links and equipment in the core network
		can be replaced, so it was important to define a
concatenation
		method that could be implemented only by the endpoints.

		2. Contiguous/arbitrary concatenation is not as elgant for
		lower order paths as for higher order paths. We saw in
		a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
		into an STM-1, but most equipment does not provide the
		ability to concatenate lower order paths. For certain
		payloads, lower order paths fit better, e.g., 5 x VC-12
		to carry 10Mb Ethernet.

		3. Different payloads to not fit ideally into "standard"
		multiples found in contiguous concatenation (4, 16, 64,
		256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
		fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

		4. As paths are set up or taken down in a network, there is
		a tendency for capacity to become fragmented. Contiguous/
		arbitrary concatenation cannot always take advantage of
		free timeslots along a span if they are not adjacent on
		the same fiber or if they are on different fibers.

		5. LCAS was easier to envision in a virtual concatenation
		environment. Many of the new services are not inherently
		constant bit rate, and it can be useful to dynamically
		add or remove components of the bundle to adjust link
		capacity. It is also useful to be able to handle failures
		of individual components of the concatenated trail by
		just reducing the capacity rather than by having to
		protection switch the entire path.

		Virtual concatenation was designed to solve all of the above
		problems. Arbitrary concatenation is another way to solve
		problem (3) above, but it doesn't solve the others. Given
		that virtual concatenation is standardized to solve all
		of the problems, it reduces the pressure to implement
		arbitrary concatenation throughout the network to solve
		only problem (3).

		If problem (3) is the only one you are trying to solve,
		arbitrary concatenation has the advantage of not requiring
		so much buffer space at the endpoints to accomodate
		differential delay. But with trends in memory costs, this
		is not so much of an issue, and this needs to be traded
		off against the need to provide support for the contiguous/
		arbitrary rate and all associated protection mechanisms at
		EVERY NE along the chosen path in the network in order for
		this to work.

		If there is a significant market for applications where
		solving (3) is vital but (1,2,4,5) are not so important,
		then it may be worth pushing arbitrary concatenation as
		a way to optimize how those services are provided over
		what you get with virtual concatenation.

		Regards,
		Steve Trowbridge

		"Bernstein, Greg" wrote:
		> 
		> To avoid re-grooming either virtual concatenation or
arbitrary
		concatenation
		> can help, but the implications are quite different.
		> Say we have a particularly valuable (expensive) link that
we can't or
		don't
		> want to re-groom then we have two options:
		> (1)     Require that ALL end systems that could
potentially use this link
		> convert over to virtual concatenation from standard
concatenation.
		> (2)     Or, install boxes at both ends of the link that
support the
		> arbitrary concatenation that we've been discussing.
		> 
		> Which of these seems more realistic and practical?
		> Greg B.
		>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
		>         New phone: (510) 573-2237
		> 
		>                 -----Original Message-----
		>                 From:   Zhi-Wei Lin
[mailto:[email-masked]]
		>                 Sent:   Thursday, May 17, 2001 8:41 AM
		>                 To:     Bernstein, Greg
		>                 Cc:     'Maarten Vissers'; Anup Tirumala;
		> [email-masked]; [email-masked];
[email-masked];
		> t1x1.5; q11/15
		>                 Subject:        Re: [IP-Optical]
concatenation extensions
		in
		> sonet/sdh
		> 
		>                 Hi,
		> 
		>                 some observations:
		> 
		>                 in terms of re-grooming and such, I
believe both virtual
		> concatenation
		>                 and arbitrary concatenation can perform
this. One method
		is
		>                 standardized, the other is proprietary.
		> 
		>                 In terms of routing of the individual
connections that
		make
		> up the
		>                 concatenated signal, virtual concatenation
is more
		flexible
		> than
		>                 arbitrary concatenation, since you can put
each component
		VC
		> in
		>                 different lines, and each component can be
routed
		> differently.
		> 
		>                 In terms of interworking, yes the
SIGNALLING can
		defnititely
		> be made to
		>                 interwork. However, the larger issue for
interworking is
		> support by the
		>                 transport equipment themselves. Thus
interworking involves
		> TWO parts:
		>                 signaling interworking and transport
interworking. Having
		> one without
		>                 the other doesn't really help...
		> 
		>                 Thus, in terms of solving real problems,
either virtual or
		> arbitrary can
		>                 accomplish that, but IMO, virtual seems
more
		flexible...and
		>                 standardized...
		> 
		>                 In terms of standards as fostering
interoperability and
		> stifling of
		>                 innovation, in principle yes I agree. And
therefore if
		> arbitrary
		>                 concatenation should be standardized, it
should be
		> standardized in the
		>                 correct standards body. As Maarten
mentioned, the relevant
		> standards
		>                 bodies discussed arbitrary concatenation
years ago, and
		> decided
		>                 (hopefully based on their expert technical
opinion - I
		> wasn't involved)
		>                 not to include arbitrary but instead to
include virtual.
		> IMO, there must
		>                 be good reasons, and from what I can tell,
I see virtual
		as
		> been more
		>                 flexible so that is a pretty good
reason...we at IETF,
		being
		> protocol
		>                 experts (and budding transport experts?)
should not try to
		> second-guess
		>                 the decisions without fully understanding
the
		> ramifications...
		> 
		>                 As for stifling innovation, anytime you
standardize
		anything
		> there is
		>                 always some factor of development that
gets fixed (is this
		> something
		>                 that should not be said in a public
forum??? -- sorry!!).
		> Therefore
		>                 there is always a tradeoff between
innovation and
		> standardization. I
		>                 think the job of standards bodies is to
try to balance
		these
		> two factors
		>                 such that the industry in general can live
with the result
		> without
		>                 unduly burdening...
		> 
		>                 agree?
		> 
		>                 Zhi
		> 
		>                 "Bernstein, Greg" wrote:
		>                 >
		>                 > A couple more points.
		>                 > (1)     GMPLS works well with arbitrary
concatenations
		> need to specify the
		>                 > time slots since it provides a signaling
protocol that
		can
		> do just that,
		>                 > i.e., GMPLS actually enables this
feature to
		interoperate.
		>                 > (2)     Arbitrary concatenation offers a
solution to a
		> real problem, i.e.,
		>                 > eliminates the need for re-grooming on
lines that
		support
		> it.  For those who
		>                 > have invested non-trivial amounts of
money in
		transoceanic
		> links this can be
		>                 > a significant savings.
		>                 > (3)     The goal is interoperability and
to solve real
		> problems.  We've got
		>                 > a real problem and with a minor edit to
the GMPLS SONET
		> specification we can
		>                 > have an interoperable method for solving
it.
		>                 >
		>                 > To be precise in the definition of
arbitrary
		> concatenation:
		>                 > As a concatenated signal within a single
SONET Line (SDH
		> MS), with
		>                 > potentially arbitrary timeslots used for
its components.
		>                 >
		>                 > The current main application is:
avoiding the need for
		> service impacting
		>                 > re-grooming. Note that this applies to
standard sized
		> signals and is a per
		>                 > link property.
		>                 >
		>                 > Other applications do exist and are
somewhat competitive
		> with non-LCAS
		>                 > virtual concatenation since the
implementation of
		> arbitrary concatenation
		>                 > for odd sized signals is simpler than
that of virtual
		> concatenation.  Once
		>                 > "odd" sized signals are used an entire
path through the
		> network must exist
		>                 > that supports them.
		>                 >
		>                 > Folks I thought the role of standards
organizations was
		to
		> foster
		>                 > interoperability that enables the
industry to move
		forward
		> rather than as a
		>                 > means to stifle innovation. I think it
is better for the
		> marketplace to
		>                 > decide which features are desirable.
		>                 >
		>                 > Greg B.
		>                 >
		>                 >         Dr. Greg M. Bernstein, Senior
Scientist, Ciena
		>                 >         New phone: (510) 573-2237
		>                 >

Delivery-date: Thu, 17 May 2001 15:24:07 -0700
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 18 May 2001 00:23:31 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Alan J Weissberger <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &   Mgt Planes

This is a multi-part message in MIME format.
--------------FF1322A41599B95ACB4C410F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan,

I will not be in Caracas, but I will be in Turin.

In my (sometimes) simple vision, I expect TCM endpoints to be activated
already at the E-NNI and UNI points in the network before any actual
connection is being requested. Once the decision is made that an
interface port is an E-NNI/UNI for the ODUk layer network, management
plane can activate the TCM endpoint immediately. It isn't important that
there is no signal yet connected to it, like it isn't important for a
path termination point that it is not the endpoint of a path yet. So in
this case, the control plane has only to assign the appropriate values
to the other MI_XXX signals (like MI_ExTI, see annex % of my ASTN layer
network architecture document).

Regards,

Maarten

Alan J Weissberger wrote:
> 
> Hi Martin
> 
> Agree with your comment below, but what primitives/ parameters are passed
> between planes to facilitate TCM activation/ de-activation
> 
> Wouldn't it be possible to activate TCM sesstions in the core of the network in
> advance?  That would speed up the complete provisioning process
> 
> Are you going to Caracas meeting?
> 
> alan W
> 
> Quoting Maarten Vissers <[email-masked]>:
> 
> > Alan,
> >
> > Concerning your 3rd item (TCM activation), the control plane should be
> > able to control this also for the case of SPCs and SCs. The control
> > plane will also have to control the TCM endpoint related MI_XXX
> > parameters.
> >
> > Regards,
> >
> > Maarten
> >
> > Alan J Weissberger wrote:
> > >
> > > All
> > >
> > > I agree with Tammy's remarks below regarding the jurisdiction of the
> > control
> > > plane.  We do have a G.874 LL item on Interworking between Mgt and
> > Control
> > > planes and this takes on more importance with soft PC's.  I see 3
> > critical
> > > interactions between these two planes:
> > >
> > > 1.  SPCs: management plane initiates connection, control plane (NNI
> > sig &
> > > Routing) executes, then informs mgt plane of outcome of connection
> > setup request
> > > (see attached illustration).  PM and fault management done in
> > management plane
> > >
> > >
> > > 2.  Resiliency/ self healing: Management plane sets up connection, but
> > control
> > > plane is notified of the path to do restoration on a hard failure.
> > Conversely,
> > > control plane sets up the connection, but management plane notified to
> > do
> > > protection on a SONET/SDH path or line layer basis
> > >
> > > 3.  Control plane sets up an OTN connection, management plane is
> > notified to
> > > activate G.709 TCM sessions (or they may be pre-allocated along
> > predefined paths
> > >
> > > There are others as well, but I believe the above three are most
> > important
> > >
> > > I suggest we address this "co-ordination between planes" issue on May
> > 21-22,
> > > when we have the ASON discussions in Caracas.
> > >
> > > rgds
> > >
> > > alan W
> > >
> > > Quoting [email-masked]:
> > >
> > > > Shiva,
> > > > Traditionally, often different systems are responsible for different
> > > > management functions relating to the same resources.
> > > >
> > > > I think it is important to define and keep in mind scope.  For
> > example,
> > > > as I currently understand it, the control plane is only required to
> > > > control path set-up within a single layer network (while interacting
> > > > with other layers as needed to do its job).
> > > >
> > > > Network/Service management (management plane) needs scope of all
> > layers
> > > > and interfaces that cross administrative boundaries.
> > > >
> > > > My current view is that the control plane is mainly responsible for
> > > > connection set-up and tear-down (network engineering) and traffic
> > > > management for those resources it has been allocated.  If, for some
> > > > reason, it cannot do its' job (e.g. failure of a control channel),
> > it
> > > > should be reporting such failures to the management plane.
> > > > Tammy
> > > > -----Original Message-----
> > > > From: ssnarayanan [mailto:[email-masked]]
> > > > Sent: Thursday, May 17, 2001 08:47
> > > > To: zwlin
> > > > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > > > tsg15q12; tsg15q14
> > > > Subject: Re: ASTN Layer Network Architecture
> > > >
> > > >
> > > > Tammy, Maarten and Zhi,
> > > >   Along the lines of Zhi's question, it is also fundamental to know
> > > > which plane "owns" the management responsibility for the connection,
> > > > e.g., if a SPC is setup, then is it the management plane which owns
> > this
> > > > or the control plane.  The management plane initiates the request,
> > but
> > > > the control plane executes the request via NNI signaling.  As far as
> > I
> > > > see, if we resolve this issue, then we can get a better
> > understanding of
> > > > what is meant by "migrating" a connection from the management plane
> > to
> > > > the control plane control.
> > > >
> > > > Regards,
> > > > Shiva
> > > > ------------------
> > > > Sivakumar Sankaranarayanan
> > > > Member of Technical Staff
> > > > HO 3C-508A
> > > > Lucent Technologies,
> > > > 101 Crawfords Corner Road,
> > > > Holmdel, NJ 07733.
> > > >
> > > > Phone:        +1 732 949 5762
> > > > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > > > Email:        [email-masked]
> > > >
> > >
> > > Alan J Weissberger
> > > DCT
> > > 2013 Acacia CT
> > > Santa Clara, CA 95050-3482
> > > 1 408 588 6493
> > > Home email: [email-masked]
> > >
> > >
> > ------------------------------------------------------------------------
> > >                Name: SPCs.ppt
> > >    SPCs.ppt    Type: Microsoft PowerPoint Show
> > (application/vnd.ms-powerpoint)
> > >            Encoding: base64
> >
> >
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: [email-masked]
> 1 408 588 6493
> [email-masked]
--------------FF1322A41599B95ACB4C410F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------FF1322A41599B95ACB4C410F--

Delivery-date: Thu, 17 May 2001 15:09:37 -0700
Cc: Carmine Daloia <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 18 May 2001 00:09:12 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Alan J Weissberger <[email-masked]>
Original-CC: Carmine Daloia <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &   Mgt Planes

This is a multi-part message in MIME format.
--------------374B1550D40ABB0082C2507D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan,

Loss of signal comes from the transport plane as part of the AI_TSF
signal towards protection and control plance restoration engines. PM
based threshold crossings are up to now never used to trigger
protection. It is the degraded signal (DEG) defect that is used so far,
which contributes as AI_TSD to protection/restorarion from the transport
plane.

Regards,

Maarten

Alan J Weissberger wrote:
> 
> Hi Carmine
> 
> Thanks for your reply
> 
> 1.  There is a scenario where the Management plane (e.g. EMS  and/or NMS) sets
> up the connection, but the control plane then does re-routing based restoration
> over the NNI.  At least one network operator told me that they wanted to do that
> 
> 2.  What I meant to say was that the protection triggers would come from the
> management plane (e.g. TCM threshold crossings, Loss of light/ loss of signal,
> etc).  Restoration triggers could come from Physical layer or a higher layer
> 
> Carmine, are you going to Caracas?  I will be there, but not at June 4-7 Turin
> meeting
> 
> rgds
> 
> alan W
> 
> Quoting Carmine Daloia <[email-masked]>:
> 
> > Hi Alan,
> >
> > I agree there is need for management plane and control plane
> > interactions.  I am
> > a bit confused with your second example (Resiliency/Self-Healing)
> > though.
> >
> > You indicate that Mangement Plane sets up connection, but control plane
> > is
> > notified of the path to do restoration on a hard failure. Are you
> > suggesting
> > that the control plane in this scenario would only be responsible for
> > restoration and not setting up the initial connection?
> >
> > Also, you indicate that the control plane sets up the connection, but
> > the
> > management plane is notified to do protection on a SONET/SDH path or
> > line.  The
> > management plane is never notified to do protection. Protection (e.g.,
> > SNCP,
> > MS-SPRING) occurs in the transport plane.  So in this scenario, I am not
> > sure
> > what you mean by control plane and management plane interactions.
> >
> > Carmine
> >
> > Alan J Weissberger wrote:
> > >
> > > All
> > >
> > > I agree with Tammy's remarks below regarding the jurisdiction of the
> > control
> > > plane.  We do have a G.874 LL item on Interworking between Mgt and
> > Control
> > > planes and this takes on more importance with soft PC's.  I see 3
> > critical
> > > interactions between these two planes:
> > >
> > > 1.  SPCs: management plane initiates connection, control plane (NNI
> > sig &
> > > Routing) executes, then informs mgt plane of outcome of connection
> > setup request
> > > (see attached illustration).  PM and fault management done in
> > management plane
> > >
> > >
> > > 2.  Resiliency/ self healing: Management plane sets up connection, but
> > control
> > > plane is notified of the path to do restoration on a hard failure.
> > Conversely,
> > > control plane sets up the connection, but management plane notified to
> > do
> > > protection on a SONET/SDH path or line layer basis
> > >
> > > 3.  Control plane sets up an OTN connection, management plane is
> > notified to
> > > activate G.709 TCM sessions (or they may be pre-allocated along
> > predefined paths
> > >
> > > There are others as well, but I believe the above three are most
> > important
> > >
> > > I suggest we address this "co-ordination between planes" issue on May
> > 21-22,
> > > when we have the ASON discussions in Caracas.
> > >
> > > rgds
> > >
> > > alan W
> > >
> > > Quoting [email-masked]:
> > >
> > > > Shiva,
> > > > Traditionally, often different systems are responsible for different
> > > > management functions relating to the same resources.
> > > >
> > > > I think it is important to define and keep in mind scope.  For
> > example,
> > > > as I currently understand it, the control plane is only required to
> > > > control path set-up within a single layer network (while interacting
> > > > with other layers as needed to do its job).
> > > >
> > > > Network/Service management (management plane) needs scope of all
> > layers
> > > > and interfaces that cross administrative boundaries.
> > > >
> > > > My current view is that the control plane is mainly responsible for
> > > > connection set-up and tear-down (network engineering) and traffic
> > > > management for those resources it has been allocated.  If, for some
> > > > reason, it cannot do its' job (e.g. failure of a control channel),
> > it
> > > > should be reporting such failures to the management plane.
> > > > Tammy
> > > > -----Original Message-----
> > > > From: ssnarayanan [mailto:[email-masked]]
> > > > Sent: Thursday, May 17, 2001 08:47
> > > > To: zwlin
> > > > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > > > tsg15q12; tsg15q14
> > > > Subject: Re: ASTN Layer Network Architecture
> > > >
> > > >
> > > > Tammy, Maarten and Zhi,
> > > >   Along the lines of Zhi's question, it is also fundamental to know
> > > > which plane "owns" the management responsibility for the connection,
> > > > e.g., if a SPC is setup, then is it the management plane which owns
> > this
> > > > or the control plane.  The management plane initiates the request,
> > but
> > > > the control plane executes the request via NNI signaling.  As far as
> > I
> > > > see, if we resolve this issue, then we can get a better
> > understanding of
> > > > what is meant by "migrating" a connection from the management plane
> > to
> > > > the control plane control.
> > > >
> > > > Regards,
> > > > Shiva
> > > > ------------------
> > > > Sivakumar Sankaranarayanan
> > > > Member of Technical Staff
> > > > HO 3C-508A
> > > > Lucent Technologies,
> > > > 101 Crawfords Corner Road,
> > > > Holmdel, NJ 07733.
> > > >
> > > > Phone:        +1 732 949 5762
> > > > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > > > Email:        [email-masked]
> > > >
> > >
> > > Alan J Weissberger
> > > DCT
> > > 2013 Acacia CT
> > > Santa Clara, CA 95050-3482
> > > 1 408 588 6493
> > > Home email: [email-masked]
> > >
> > >
> > ------------------------------------------------------------------------------
> --
> > >                Name: SPCs.ppt
> > >    SPCs.ppt    Type: Microsoft PowerPoint Show
> > (application/vnd.ms-powerpoint)
> > >            Encoding: base64
> >
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: [email-masked]
> 1 408 588 6493
> [email-masked]
--------------374B1550D40ABB0082C2507D
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------374B1550D40ABB0082C2507D--

Delivery-date: Thu, 17 May 2001 15:06:32 -0700
Cc: Steve West <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Fri, 18 May 2001 00:05:00 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Zhi-Wei Lin <[email-masked]>
Original-CC: Steve West <[email-masked]>, "'Stephen Trowbridge'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------1132463CCAC263875E64C325
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Virtual concatenation is intended to offer the support of new ("odd
sized") service signals by the existing network.

Arbitrary concatenation (at least per "real problem" described by Greg)
is intended to offer "non blocking" links (connection between two
adjacent SDH/SONET equipment) without the need to perform a bandwidth
defragmentation action once every ... days.

The link which can't have this defragmenation, is surrounded by
arbitrary concatenation capable STM-N/OC-N line ports. A simple and
local upgrade in the existing network (replace/install 2 port units).

The network which want to offer the new ("odd sized") service is
surrounded by virtual concatenation capable client signal tributary
ports (e.g. 1GE port). A simple and local upgrade in the existing
network (install 2 port units).

As long as arbitrary concatenation isn't sold as a means to introduce
new ("odd sized") services, arbitrary concatenation and virtual
concatenation provide additional capabilities to the existing network
with local upgrades only, and without introducing new interworking
problems.

Hope this is a fair summary up to here.

Now lets have a look at the signalling impact.

- Virtual concatenation most likely doesn't need any special treatment
(in first instance) in the signalling for connection setup (latest
understanding by me). If a virtual concatenated trail is to be set up,
actually a set of X basic VC-n/STS/VT network connections are to be set
up. This may be done as the set up of X individual connections, the set
up of one group of X (co-routed) connections, the set up of n subgroups
with X1, X2, .., Xn connections each. 
The group of network connections is to be set up between two Access
Groups (AG) of the same type (virtual concatenated and same client (i.e.
G-PID)).

- Arbitrary concatenation most likely doesn't need any special treatment
in the signalling for the STM-N/OC-N trail to be set up. The STM-N/OC-N
connection can be a (virtual) fiber, and in this case STM-N/OC-N trail
setup is manual (connecting fibers). The STM-N/OC-N connection can be
created via a WDM/OTN network, and in this case the OCh/ODUk trail set
up can be performed as normal; i.e. between two access groups of the
same type and with the same G-PID (indicating STM-N/OC-N with arbitrary
concatenation support).

The use of this HOVC/STS link with arbitrary concatenation is the same
as any other HOVC/STS link (without arbitrary concatenation); at least
from the outside. Between the two SDH/SONET equipments however (i.e.
internal to the link), the signalling message will have to include the
list of timeslots. But this can be kept local to the link.

In G.ason/G.dcm the assumption is to use a link connection identifier
(i.e. address), hiding the multiplexing details during the connection
setup. The link connections have been discovered during the service
discovery phase of the creation of the link. Only in this service
discovery phase the multiplex numbers play a role. Also for arbitrary
concatenation this two step approach can be used, preventing any need to
include in the connection creation signaling message on the link the
list of timeslots allocated to this link connection. I.e. any possible
link connection allocation has its own identifier/address, which is
assigned during service discovery.

I am not sure if I am completely correct in this second part... but at
the moment it looks positive to me.

Regards,

Maarten
--------------1132463CCAC263875E64C325
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------1132463CCAC263875E64C325--

Delivery-date: Thu, 17 May 2001 14:58:54 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Steve West' <[email-masked]>, 'Stephen Trowbridge' <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>,  [email-masked], [email-masked], [email-masked],  "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 14:57:36 -0700

Why don't we just remove the contiguous arbitrary concatenation from the
GMPLS specification  since it's not standard and doesn't offer any value
that I can see.  Anything else could be left for peoples proprietary
extensions:-)

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Steve West [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 12:52 PM
		To:	'Stephen Trowbridge'; Bernstein, Greg
		Cc:	'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	RE: [IP-Optical] concatenation extensions in
sonet/sdh

		Greg:

		It seems that you have a scheme that allows better
utilization of a link by
		including a new type of concatenation hardware, just at the
ends of that
		link.  If I understand, the concatenation method allows you
to remove the
		requirement for "contiguous" sts1/columns in the SONET/SDH
payload, by
		"leap-frogging" over columns that are in-use and thus
"in-the-way" ?  

		If my read is right, why not also present this "leap-frog"
arbitrary
		concatenation scheme to the relevent standards authorities
(ANSI/ETSI/ITU),
		so that the experts there can validate its applicability?

		Steve West

		-----Original Message-----
		From: Stephen Trowbridge [mailto:[email-masked]]
		Sent: Thursday, May 17, 2001 11:39 AM
		To: Bernstein, Greg
		Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala;
[email-masked];
		[email-masked]; [email-masked]; t1x1.5;
q11/15
		Subject: Re: [IP-Optical] concatenation extensions in
sonet/sdh

		There is no intent in any of the standardization bodies to
stifle
		innovation. Standards are contribution driven, and what you
find
		in the documents as written are the product of those
contributions.

		If the desire is to extend current SONET/SDH with an
arbitrary
		concatenation feature, there is no problem to contribute to
T1X1
		and/or ITU-T to propose this extension. This is the correct
way to
		approach it. The INCORRECT way is to confuse the market by
producing
		an IETF version of SONET/SDH specs that is different from
T1X1/ITU-T.

		Let me add some background on how we ended up with the
current
		situation recommending virtual concatenation in SONET/SDH:

		1. Contiguous or Arbitrary concatenation requires
implementation
		of the concatenation method at every NE along the chosen
path
		through the network to provide a service. At the time we
began
		these discussions, we had the problem that ATM wanted to use
		VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
		links in the network and NEs that didn't support trails
		bigger than VC-4 (STS-3c). By now, of course, VC-4-4c
(STS-12c)
		and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
		but as has been observed in previous emails, it will be a
		long time before you replace all of the 2.5G links in the
		network, so contiguous/arbitrary concatenation to greater
		than VC-4-16c/STS-48c is still a problem for some time to
		come. The endpoints in a network always seem to evolve ahead
		of and faster than links and equipment in the core network
		can be replaced, so it was important to define a
concatenation
		method that could be implemented only by the endpoints.

		2. Contiguous/arbitrary concatenation is not as elgant for
		lower order paths as for higher order paths. We saw in
		a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
		into an STM-1, but most equipment does not provide the
		ability to concatenate lower order paths. For certain
		payloads, lower order paths fit better, e.g., 5 x VC-12
		to carry 10Mb Ethernet.

		3. Different payloads to not fit ideally into "standard"
		multiples found in contiguous concatenation (4, 16, 64,
		256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
		fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

		4. As paths are set up or taken down in a network, there is
		a tendency for capacity to become fragmented. Contiguous/
		arbitrary concatenation cannot always take advantage of
		free timeslots along a span if they are not adjacent on
		the same fiber or if they are on different fibers.

		5. LCAS was easier to envision in a virtual concatenation
		environment. Many of the new services are not inherently
		constant bit rate, and it can be useful to dynamically
		add or remove components of the bundle to adjust link
		capacity. It is also useful to be able to handle failures
		of individual components of the concatenated trail by
		just reducing the capacity rather than by having to
		protection switch the entire path.

		Virtual concatenation was designed to solve all of the above
		problems. Arbitrary concatenation is another way to solve
		problem (3) above, but it doesn't solve the others. Given
		that virtual concatenation is standardized to solve all
		of the problems, it reduces the pressure to implement
		arbitrary concatenation throughout the network to solve
		only problem (3).

		If problem (3) is the only one you are trying to solve,
		arbitrary concatenation has the advantage of not requiring
		so much buffer space at the endpoints to accomodate
		differential delay. But with trends in memory costs, this
		is not so much of an issue, and this needs to be traded
		off against the need to provide support for the contiguous/
		arbitrary rate and all associated protection mechanisms at
		EVERY NE along the chosen path in the network in order for
		this to work.

		If there is a significant market for applications where
		solving (3) is vital but (1,2,4,5) are not so important,
		then it may be worth pushing arbitrary concatenation as
		a way to optimize how those services are provided over
		what you get with virtual concatenation.

		Regards,
		Steve Trowbridge

		"Bernstein, Greg" wrote:
		> 
		> To avoid re-grooming either virtual concatenation or
arbitrary
		concatenation
		> can help, but the implications are quite different.
		> Say we have a particularly valuable (expensive) link that
we can't or
		don't
		> want to re-groom then we have two options:
		> (1)     Require that ALL end systems that could
potentially use this link
		> convert over to virtual concatenation from standard
concatenation.
		> (2)     Or, install boxes at both ends of the link that
support the
		> arbitrary concatenation that we've been discussing.
		> 
		> Which of these seems more realistic and practical?
		> Greg B.
		>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
		>         New phone: (510) 573-2237
		> 
		>                 -----Original Message-----
		>                 From:   Zhi-Wei Lin
[mailto:[email-masked]]
		>                 Sent:   Thursday, May 17, 2001 8:41 AM
		>                 To:     Bernstein, Greg
		>                 Cc:     'Maarten Vissers'; Anup Tirumala;
		> [email-masked]; [email-masked];
[email-masked];
		> t1x1.5; q11/15
		>                 Subject:        Re: [IP-Optical]
concatenation extensions
		in
		> sonet/sdh
		> 
		>                 Hi,
		> 
		>                 some observations:
		> 
		>                 in terms of re-grooming and such, I
believe both virtual
		> concatenation
		>                 and arbitrary concatenation can perform
this. One method
		is
		>                 standardized, the other is proprietary.
		> 
		>                 In terms of routing of the individual
connections that
		make
		> up the
		>                 concatenated signal, virtual concatenation
is more
		flexible
		> than
		>                 arbitrary concatenation, since you can put
each component
		VC
		> in
		>                 different lines, and each component can be
routed
		> differently.
		> 
		>                 In terms of interworking, yes the
SIGNALLING can
		defnititely
		> be made to
		>                 interwork. However, the larger issue for
interworking is
		> support by the
		>                 transport equipment themselves. Thus
interworking involves
		> TWO parts:
		>                 signaling interworking and transport
interworking. Having
		> one without
		>                 the other doesn't really help...
		> 
		>                 Thus, in terms of solving real problems,
either virtual or
		> arbitrary can
		>                 accomplish that, but IMO, virtual seems
more
		flexible...and
		>                 standardized...
		> 
		>                 In terms of standards as fostering
interoperability and
		> stifling of
		>                 innovation, in principle yes I agree. And
therefore if
		> arbitrary
		>                 concatenation should be standardized, it
should be
		> standardized in the
		>                 correct standards body. As Maarten
mentioned, the relevant
		> standards
		>                 bodies discussed arbitrary concatenation
years ago, and
		> decided
		>                 (hopefully based on their expert technical
opinion - I
		> wasn't involved)
		>                 not to include arbitrary but instead to
include virtual.
		> IMO, there must
		>                 be good reasons, and from what I can tell,
I see virtual
		as
		> been more
		>                 flexible so that is a pretty good
reason...we at IETF,
		being
		> protocol
		>                 experts (and budding transport experts?)
should not try to
		> second-guess
		>                 the decisions without fully understanding
the
		> ramifications...
		> 
		>                 As for stifling innovation, anytime you
standardize
		anything
		> there is
		>                 always some factor of development that
gets fixed (is this
		> something
		>                 that should not be said in a public
forum??? -- sorry!!).
		> Therefore
		>                 there is always a tradeoff between
innovation and
		> standardization. I
		>                 think the job of standards bodies is to
try to balance
		these
		> two factors
		>                 such that the industry in general can live
with the result
		> without
		>                 unduly burdening...
		> 
		>                 agree?
		> 
		>                 Zhi
		> 
		>                 "Bernstein, Greg" wrote:
		>                 >
		>                 > A couple more points.
		>                 > (1)     GMPLS works well with arbitrary
concatenations
		> need to specify the
		>                 > time slots since it provides a signaling
protocol that
		can
		> do just that,
		>                 > i.e., GMPLS actually enables this
feature to
		interoperate.
		>                 > (2)     Arbitrary concatenation offers a
solution to a
		> real problem, i.e.,
		>                 > eliminates the need for re-grooming on
lines that
		support
		> it.  For those who
		>                 > have invested non-trivial amounts of
money in
		transoceanic
		> links this can be
		>                 > a significant savings.
		>                 > (3)     The goal is interoperability and
to solve real
		> problems.  We've got
		>                 > a real problem and with a minor edit to
the GMPLS SONET
		> specification we can
		>                 > have an interoperable method for solving
it.
		>                 >
		>                 > To be precise in the definition of
arbitrary
		> concatenation:
		>                 > As a concatenated signal within a single
SONET Line (SDH
		> MS), with
		>                 > potentially arbitrary timeslots used for
its components.
		>                 >
		>                 > The current main application is:
avoiding the need for
		> service impacting
		>                 > re-grooming. Note that this applies to
standard sized
		> signals and is a per
		>                 > link property.
		>                 >
		>                 > Other applications do exist and are
somewhat competitive
		> with non-LCAS
		>                 > virtual concatenation since the
implementation of
		> arbitrary concatenation
		>                 > for odd sized signals is simpler than
that of virtual
		> concatenation.  Once
		>                 > "odd" sized signals are used an entire
path through the
		> network must exist
		>                 > that supports them.
		>                 >
		>                 > Folks I thought the role of standards
organizations was
		to
		> foster
		>                 > interoperability that enables the
industry to move
		forward
		> rather than as a
		>                 > means to stifle innovation. I think it
is better for the
		> marketplace to
		>                 > decide which features are desirable.
		>                 >
		>                 > Greg B.
		>                 >
		>                 >         Dr. Greg M. Bernstein, Senior
Scientist, Ciena
		>                 >         New phone: (510) 573-2237
		>                 >

Delivery-date: Thu, 17 May 2001 14:16:28 -0700
Cc: "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Thu, 17 May 2001 23:14:15 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: "'Lazer, Monica A, NNAD'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------FEFDAC4E346B3859F8080DE2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

I got the impression that there was some misunderstanding with respect
to your 2nd alternative. The "link" you refer to is (if my understanding
is correct) e.g. the connection between two adjacent SONET/SDH (cross
connect) equipments; e.g. a transoceanic connection.

If you do not want to have the need to ever perform bandwidth
defragmentation on this "link", arbitrary concatenation support in the
STM-N/OC-N line ports facing the transoceanic cable is the only
alternative in my opinion. Virtual concatenation is not intended to
support this requirement.

As I wrote in an earlier email this evening (at least in this timezone),
arbitrary concatenation used in this application can be treated similar
to standard contiguous concatenation, if the igress signals are only
standard contiguous concatenated signals and the basic signals (STS1,
VC-4). The transoceanic HOVC/STS link will simply have less "blocking".
In this application there is no need to reflect any arbitrary
concatenation capability in the signalling.

If you however want to have the SONET/SDH network support interworking
of STS-Xa and VC-4-Xa signals for other values of X than the contiguous
concatenated ones, the signalling specifications need to reflect the
arbitrary concatenated capabilities.

But to prevent inconsistency between transport plane and control plane
standards, either both standards need to include arbitrary concatenation
or have it both not included.

For the case the agreement in the transport plane standardisation is to
extend the current SONET/SDH networks with interworking capabilities for
STS-Xa (X=1..N) and VC-4-Xa (X=1..N) signals, the development of a
complete set of STS-Xa and VC-4-Xa requirements can be generated; e.g.
including 
- STS-Xa/VC-4-Xa with LCAS to allow hitless capacity adjustment to be
supported,
- addition of multiplex structure identifier in the MSOH/LOH to support
AUG-X/STSG-X,
- payload mapping specifications
- virtual concatenation/arbitrary concatenation interworking functions
- etc.

Regards,

Maarten

"Bernstein, Greg" wrote:
> 
> Are we having fun for a Thursday, or what?
> Zhi, had me convinced that I should do a "start up" specializing in virtual
> concatenation for link bandwidth optimization, then Monica asked me about
> overhead use in arbitrary concatenation...
> Here are some more points:
> (1)     Arbitrary concatenation (assuming standard sizes) is fairly minor
> tweak of standard contiguous concatenation, i.e., the framer just needs to
> be told the starting time slot (which has the pointer) and the remaining
> (arbitrary) time slots (which have the concatenation indication set).  No
> path overhead is used for this process.  It is strictly a line level
> operation, e.g., B3 is not recalculated.  This is suitable for LTE equipment
> and has nice consequences for avoiding re-grooming.
> (2)     Virtual concatenation is a whole new and useful feature that uses
> path level overhead, in particular the H4 byte.  Hence the path level BIP B3
> needs to recalculated.  This is more a PTE (path termination equipment) kind
> of thing to do.  Not something that a typical switch would necessarily want
> to do for compatibility purposes. This was intended for a much more
> sophisticated application, i.e., a path level "bonding" or inverse
> multiplexing, but it lacks path level transparency if used to avoid
> regrooming.
> 
> Hope this puts some more gasoline (petrol) onto the fire.
> 
> Greg B.
> 
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Lazer, Monica A, NNAD [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 11:01 AM
>                 To:     Bernstein, Greg; 'Zhi-Wei Lin'
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        RE: [T1X1.5] RE: [IP-Optical] concatenation
> extensions in sonet/s dh
> 
>                 Why wouldn't the 2 boxes in option 2 use virtual
> concatenation instead of
>                 arbitrary concatenation, though?
> 
>                 Monica A. Lazer
>                 Advanced Transport Technology and Architecture Planning
> 
>                 908 234 8462
>                 [email-masked]
> 
>                 -----Original Message-----
>                 From: Bernstein, Greg [mailto:[email-masked]]
>                 Sent: Thursday, May 17, 2001 12:27 PM
>                 To: 'Zhi-Wei Lin'
>                 Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
>                 [email-masked]; [email-masked]; t1x1.5;
> q11/15
>                 Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions
> in sonet/sdh
> 
>                 To avoid re-grooming either virtual concatenation or
> arbitrary concatenation
>                 can help, but the implications are quite different.
>                 Say we have a particularly valuable (expensive) link that we
> can't or don't
>                 want to re-groom then we have two options:
>                 (1)     Require that ALL end systems that could potentially
> use this link
>                 convert over to virtual concatenation from standard
> concatenation.
>                 (2)     Or, install boxes at both ends of the link that
> support the
>                 arbitrary concatenation that we've been discussing.
> 
>                 Which of these seems more realistic and practical?
>                 Greg B.
>                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                         New phone: (510) 573-2237
> 
>                                 -----Original Message-----
>                                 From:   Zhi-Wei Lin
> [mailto:[email-masked]]
>                                 Sent:   Thursday, May 17, 2001 8:41 AM
>                                 To:     Bernstein, Greg
>                                 Cc:     'Maarten Vissers'; Anup Tirumala;
>                 [email-masked]; [email-masked];
> [email-masked];
>                 t1x1.5; q11/15
>                                 Subject:        Re: [IP-Optical]
> concatenation extensions in
>                 sonet/sdh
> 
>                                 Hi,
> 
>                                 some observations:
> 
>                                 in terms of re-grooming and such, I believe
> both virtual
>                 concatenation
>                                 and arbitrary concatenation can perform
> this. One method is
>                                 standardized, the other is proprietary.
> 
>                                 In terms of routing of the individual
> connections that make
>                 up the
>                                 concatenated signal, virtual concatenation
> is more flexible
>                 than
>                                 arbitrary concatenation, since you can put
> each component VC
>                 in
>                                 different lines, and each component can be
> routed
>                 differently.
> 
>                                 In terms of interworking, yes the SIGNALLING
> can defnititely
>                 be made to
>                                 interwork. However, the larger issue for
> interworking is
>                 support by the
>                                 transport equipment themselves. Thus
> interworking involves
>                 TWO parts:
>                                 signaling interworking and transport
> interworking. Having
>                 one without
>                                 the other doesn't really help...
> 
>                                 Thus, in terms of solving real problems,
> either virtual or
>                 arbitrary can
>                                 accomplish that, but IMO, virtual seems more
> flexible...and
>                                 standardized...
> 
>                                 In terms of standards as fostering
> interoperability and
>                 stifling of
>                                 innovation, in principle yes I agree. And
> therefore if
>                 arbitrary
>                                 concatenation should be standardized, it
> should be
>                 standardized in the
>                                 correct standards body. As Maarten
> mentioned, the relevant
>                 standards
>                                 bodies discussed arbitrary concatenation
> years ago, and
>                 decided
>                                 (hopefully based on their expert technical
> opinion - I
>                 wasn't involved)
>                                 not to include arbitrary but instead to
> include virtual.
>                 IMO, there must
>                                 be good reasons, and from what I can tell, I
> see virtual as
>                 been more
>                                 flexible so that is a pretty good
> reason...we at IETF, being
>                 protocol
>                                 experts (and budding transport experts?)
> should not try to
>                 second-guess
>                                 the decisions without fully understanding
> the
>                 ramifications...
> 
>                                 As for stifling innovation, anytime you
> standardize anything
>                 there is
>                                 always some factor of development that gets
> fixed (is this
>                 something
>                                 that should not be said in a public forum???
> -- sorry!!).
>                 Therefore
>                                 there is always a tradeoff between
> innovation and
>                 standardization. I
>                                 think the job of standards bodies is to try
> to balance these
>                 two factors
>                                 such that the industry in general can live
> with the result
>                 without
>                                 unduly burdening...
> 
>                                 agree?
> 
>                                 Zhi
> 
>                                 "Bernstein, Greg" wrote:
>                                 >
>                                 > A couple more points.
>                                 > (1)     GMPLS works well with arbitrary
> concatenations
>                 need to specify the
>                                 > time slots since it provides a signaling
> protocol that can
>                 do just that,
>                                 > i.e., GMPLS actually enables this feature
> to interoperate.
>                                 > (2)     Arbitrary concatenation offers a
> solution to a
>                 real problem, i.e.,
>                                 > eliminates the need for re-grooming on
> lines that support
>                 it.  For those who
>                                 > have invested non-trivial amounts of money
> in transoceanic
>                 links this can be
>                                 > a significant savings.
>                                 > (3)     The goal is interoperability and
> to solve real
>                 problems.  We've got
>                                 > a real problem and with a minor edit to
> the GMPLS SONET
>                 specification we can
>                                 > have an interoperable method for solving
> it.
>                                 >
>                                 > To be precise in the definition of
> arbitrary
>                 concatenation:
>                                 > As a concatenated signal within a single
> SONET Line (SDH
>                 MS), with
>                                 > potentially arbitrary timeslots used for
> its components.
>                                 >
>                                 > The current main application is: avoiding
> the need for
>                 service impacting
>                                 > re-grooming. Note that this applies to
> standard sized
>                 signals and is a per
>                                 > link property.
>                                 >
>                                 > Other applications do exist and are
> somewhat competitive
>                 with non-LCAS
>                                 > virtual concatenation since the
> implementation of
>                 arbitrary concatenation
>                                 > for odd sized signals is simpler than that
> of virtual
>                 concatenation.  Once
>                                 > "odd" sized signals are used an entire
> path through the
>                 network must exist
>                                 > that supports them.
>                                 >
>                                 > Folks I thought the role of standards
> organizations was to
>                 foster
>                                 > interoperability that enables the industry
> to move forward
>                 rather than as a
>                                 > means to stifle innovation. I think it is
> better for the
>                 marketplace to
>                                 > decide which features are desirable.
>                                 >
>                                 > Greg B.
>                                 >
>                                 >         Dr. Greg M. Bernstein, Senior
> Scientist, Ciena
>                                 >         New phone: (510) 573-2237
>                                 >
--------------FEFDAC4E346B3859F8080DE2
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------FEFDAC4E346B3859F8080DE2--

Delivery-date: Thu, 17 May 2001 13:50:51 -0700
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 17 May 2001 22:49:07 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Alan J Weissberger <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes

This is a multi-part message in MIME format.
--------------883962148C987F9837682A74
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan,

Concerning your 3rd item (TCM activation), the control plane should be
able to control this also for the case of SPCs and SCs. The control
plane will also have to control the TCM endpoint related MI_XXX
parameters.

Regards,

Maarten

Alan J Weissberger wrote:
> 
> All
> 
> I agree with Tammy's remarks below regarding the jurisdiction of the control
> plane.  We do have a G.874 LL item on Interworking between Mgt and Control
> planes and this takes on more importance with soft PC's.  I see 3 critical
> interactions between these two planes:
> 
> 1.  SPCs: management plane initiates connection, control plane (NNI sig &
> Routing) executes, then informs mgt plane of outcome of connection setup request
> (see attached illustration).  PM and fault management done in management plane
> 
> 
> 2.  Resiliency/ self healing: Management plane sets up connection, but control
> plane is notified of the path to do restoration on a hard failure.  Conversely,
> control plane sets up the connection, but management plane notified to do
> protection on a SONET/SDH path or line layer basis
> 
> 3.  Control plane sets up an OTN connection, management plane is notified to
> activate G.709 TCM sessions (or they may be pre-allocated along predefined paths
> 
> There are others as well, but I believe the above three are most important
> 
> I suggest we address this "co-ordination between planes" issue on May 21-22,
> when we have the ASON discussions in Caracas.
> 
> rgds
> 
> alan W
> 
> Quoting [email-masked]:
> 
> > Shiva,
> > Traditionally, often different systems are responsible for different
> > management functions relating to the same resources.
> >
> > I think it is important to define and keep in mind scope.  For example,
> > as I currently understand it, the control plane is only required to
> > control path set-up within a single layer network (while interacting
> > with other layers as needed to do its job).
> >
> > Network/Service management (management plane) needs scope of all layers
> > and interfaces that cross administrative boundaries.
> >
> > My current view is that the control plane is mainly responsible for
> > connection set-up and tear-down (network engineering) and traffic
> > management for those resources it has been allocated.  If, for some
> > reason, it cannot do its' job (e.g. failure of a control channel), it
> > should be reporting such failures to the management plane.
> > Tammy
> > -----Original Message-----
> > From: ssnarayanan [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2001 08:47
> > To: zwlin
> > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > tsg15q12; tsg15q14
> > Subject: Re: ASTN Layer Network Architecture
> >
> >
> > Tammy, Maarten and Zhi,
> >   Along the lines of Zhi's question, it is also fundamental to know
> > which plane "owns" the management responsibility for the connection,
> > e.g., if a SPC is setup, then is it the management plane which owns this
> > or the control plane.  The management plane initiates the request, but
> > the control plane executes the request via NNI signaling.  As far as I
> > see, if we resolve this issue, then we can get a better understanding of
> > what is meant by "migrating" a connection from the management plane to
> > the control plane control.
> >
> > Regards,
> > Shiva
> > ------------------
> > Sivakumar Sankaranarayanan
> > Member of Technical Staff
> > HO 3C-508A
> > Lucent Technologies,
> > 101 Crawfords Corner Road,
> > Holmdel, NJ 07733.
> >
> > Phone:        +1 732 949 5762
> > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > Email:        [email-masked]
> >
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: [email-masked]
> 
>   ------------------------------------------------------------------------
>                Name: SPCs.ppt
>    SPCs.ppt    Type: Microsoft PowerPoint Show (application/vnd.ms-powerpoint)
>            Encoding: base64
--------------883962148C987F9837682A74
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------883962148C987F9837682A74--

Delivery-date: Thu, 17 May 2001 13:47:32 -0700
From: "Brungard, Deborah A" <[email-masked]>
To: "'Stephen Trowbridge'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Cc: "'Zhi-Wei Lin'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 16:44:53 -0400

Wow - what a discussion - and everyone was thinking SONET/SDH was boring -

I second what Steve, our ITU-T WP3/15 chair, says below. Speaking as
T1X1.5's chair, we welcome contributions/discussion over our exploder.
T1X1.5 is open to any company to contribute/attend meetings (no fees!). Our
next meeting is the week of June 25. Actually the hotel reservation cut-off
date for the preferred rate is very soon (next week?).
Our web page:
http://www.t1.org/t1x1/t1x1.htm
exploder signup:
http://www.t1.org/cgi-bin/makemail

If a login window appears, just hit cancel. The exploder does not accept
attachments; to discuss, upload it as a contribution and refer to it in the
mail.

The latest approved T1.105:
ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC

Section 7 contains definitions of virtual concatenation, LCAS (hitless link
capacity adjustment scheme), LCAS to non-LCAS interworking.

A suggestion from myself :-), it's easier to understand if use specific
examples/figures with functional descriptions vs. "links" and "boxes" e.g.
is the "link" between two LTEs/STS path XCs (SDH: HOVC_C), does the link
contain intermediate equipment((a)"new" equipment supporting arb. conc
(b)"legacy" equipment (3)mixture). What is the (edge)box: (1) mapper,
(2)line card with pointer processing.

Also, it helps everyone to understand if can differentiate proposed new
funtionality from existing standards e.g. arb. conc in my confused
interpretation would be a new Multiplexer Section Adaptation (MS_A)
functionality i.e. pointer processor. SO distinguish it differently e.g.
MS_Aa (Greg, the fun is when we can define new names/symbols - we all think
we can do a better job than our PR depts :-)) And, if you are not familiar
with the ITU/T1X1 terminology, we can help - (my fee is a beer for easy
stuff/scotch for more difficult).

If you need any help with signing up/uploading contributions, just contact
me.

Deborah Brungard
AT&T
[email-masked]
732 420 1573

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 2:39 PM
To: Bernstein, Greg
Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
[email-masked]; [email-masked]; t1x1.5; q11/15
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

There is no intent in any of the standardization bodies to stifle
innovation. Standards are contribution driven, and what you find
in the documents as written are the product of those contributions.

If the desire is to extend current SONET/SDH with an arbitrary
concatenation feature, there is no problem to contribute to T1X1
and/or ITU-T to propose this extension. This is the correct way to
approach it. The INCORRECT way is to confuse the market by producing
an IETF version of SONET/SDH specs that is different from T1X1/ITU-T.

Let me add some background on how we ended up with the current
situation recommending virtual concatenation in SONET/SDH:

1. Contiguous or Arbitrary concatenation requires implementation
of the concatenation method at every NE along the chosen path
through the network to provide a service. At the time we began
these discussions, we had the problem that ATM wanted to use
VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
links in the network and NEs that didn't support trails
bigger than VC-4 (STS-3c). By now, of course, VC-4-4c (STS-12c)
and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
but as has been observed in previous emails, it will be a
long time before you replace all of the 2.5G links in the
network, so contiguous/arbitrary concatenation to greater
than VC-4-16c/STS-48c is still a problem for some time to
come. The endpoints in a network always seem to evolve ahead
of and faster than links and equipment in the core network
can be replaced, so it was important to define a concatenation
method that could be implemented only by the endpoints.

2. Contiguous/arbitrary concatenation is not as elgant for
lower order paths as for higher order paths. We saw in
a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
into an STM-1, but most equipment does not provide the
ability to concatenate lower order paths. For certain
payloads, lower order paths fit better, e.g., 5 x VC-12
to carry 10Mb Ethernet.

3. Different payloads to not fit ideally into "standard"
multiples found in contiguous concatenation (4, 16, 64,
256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

4. As paths are set up or taken down in a network, there is
a tendency for capacity to become fragmented. Contiguous/
arbitrary concatenation cannot always take advantage of
free timeslots along a span if they are not adjacent on
the same fiber or if they are on different fibers.

5. LCAS was easier to envision in a virtual concatenation
environment. Many of the new services are not inherently
constant bit rate, and it can be useful to dynamically
add or remove components of the bundle to adjust link
capacity. It is also useful to be able to handle failures
of individual components of the concatenated trail by
just reducing the capacity rather than by having to
protection switch the entire path.

Virtual concatenation was designed to solve all of the above
problems. Arbitrary concatenation is another way to solve
problem (3) above, but it doesn't solve the others. Given
that virtual concatenation is standardized to solve all
of the problems, it reduces the pressure to implement
arbitrary concatenation throughout the network to solve
only problem (3).

If problem (3) is the only one you are trying to solve,
arbitrary concatenation has the advantage of not requiring
so much buffer space at the endpoints to accomodate
differential delay. But with trends in memory costs, this
is not so much of an issue, and this needs to be traded
off against the need to provide support for the contiguous/
arbitrary rate and all associated protection mechanisms at
EVERY NE along the chosen path in the network in order for
this to work.

If there is a significant market for applications where
solving (3) is vital but (1,2,4,5) are not so important,
then it may be worth pushing arbitrary concatenation as
a way to optimize how those services are provided over
what you get with virtual concatenation.

Regards,
Steve Trowbridge

"Bernstein, Greg" wrote:
> 
> To avoid re-grooming either virtual concatenation or arbitrary
concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we can't or
don't
> want to re-groom then we have two options:
> (1)     Require that ALL end systems that could potentially use this link
> convert over to virtual concatenation from standard concatenation.
> (2)     Or, install boxes at both ends of the link that support the
> arbitrary concatenation that we've been discussing.
> 
> Which of these seems more realistic and practical?
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Zhi-Wei Lin [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 To:     Bernstein, Greg
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        Re: [IP-Optical] concatenation extensions
in
> sonet/sdh
> 
>                 Hi,
> 
>                 some observations:
> 
>                 in terms of re-grooming and such, I believe both virtual
> concatenation
>                 and arbitrary concatenation can perform this. One method
is
>                 standardized, the other is proprietary.
> 
>                 In terms of routing of the individual connections that
make
> up the
>                 concatenated signal, virtual concatenation is more
flexible
> than
>                 arbitrary concatenation, since you can put each component
VC
> in
>                 different lines, and each component can be routed
> differently.
> 
>                 In terms of interworking, yes the SIGNALLING can
defnititely
> be made to
>                 interwork. However, the larger issue for interworking is
> support by the
>                 transport equipment themselves. Thus interworking involves
> TWO parts:
>                 signaling interworking and transport interworking. Having
> one without
>                 the other doesn't really help...
> 
>                 Thus, in terms of solving real problems, either virtual or
> arbitrary can
>                 accomplish that, but IMO, virtual seems more
flexible...and
>                 standardized...
> 
>                 In terms of standards as fostering interoperability and
> stifling of
>                 innovation, in principle yes I agree. And therefore if
> arbitrary
>                 concatenation should be standardized, it should be
> standardized in the
>                 correct standards body. As Maarten mentioned, the relevant
> standards
>                 bodies discussed arbitrary concatenation years ago, and
> decided
>                 (hopefully based on their expert technical opinion - I
> wasn't involved)
>                 not to include arbitrary but instead to include virtual.
> IMO, there must
>                 be good reasons, and from what I can tell, I see virtual
as
> been more
>                 flexible so that is a pretty good reason...we at IETF,
being
> protocol
>                 experts (and budding transport experts?) should not try to
> second-guess
>                 the decisions without fully understanding the
> ramifications...
> 
>                 As for stifling innovation, anytime you standardize
anything
> there is
>                 always some factor of development that gets fixed (is this
> something
>                 that should not be said in a public forum??? -- sorry!!).
> Therefore
>                 there is always a tradeoff between innovation and
> standardization. I
>                 think the job of standards bodies is to try to balance
these
> two factors
>                 such that the industry in general can live with the result
> without
>                 unduly burdening...
> 
>                 agree?
> 
>                 Zhi
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > A couple more points.
>                 > (1)     GMPLS works well with arbitrary concatenations
> need to specify the
>                 > time slots since it provides a signaling protocol that
can
> do just that,
>                 > i.e., GMPLS actually enables this feature to
interoperate.
>                 > (2)     Arbitrary concatenation offers a solution to a
> real problem, i.e.,
>                 > eliminates the need for re-grooming on lines that
support
> it.  For those who
>                 > have invested non-trivial amounts of money in
transoceanic
> links this can be
>                 > a significant savings.
>                 > (3)     The goal is interoperability and to solve real
> problems.  We've got
>                 > a real problem and with a minor edit to the GMPLS SONET
> specification we can
>                 > have an interoperable method for solving it.
>                 >
>                 > To be precise in the definition of arbitrary
> concatenation:
>                 > As a concatenated signal within a single SONET Line (SDH
> MS), with
>                 > potentially arbitrary timeslots used for its components.
>                 >
>                 > The current main application is: avoiding the need for
> service impacting
>                 > re-grooming. Note that this applies to standard sized
> signals and is a per
>                 > link property.
>                 >
>                 > Other applications do exist and are somewhat competitive
> with non-LCAS
>                 > virtual concatenation since the implementation of
> arbitrary concatenation
>                 > for odd sized signals is simpler than that of virtual
> concatenation.  Once
>                 > "odd" sized signals are used an entire path through the
> network must exist
>                 > that supports them.
>                 >
>                 > Folks I thought the role of standards organizations was
to
> foster
>                 > interoperability that enables the industry to move
forward
> rather than as a
>                 > means to stifle innovation. I think it is better for the
> marketplace to
>                 > decide which features are desirable.
>                 >
>                 > Greg B.
>                 >
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >

Delivery-date: Thu, 17 May 2001 13:43:17 -0700
From: "Mannie, Eric" <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>,  [email-masked], [email-masked], [email-masked],  "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 22:42:04 +0200

Hello Ladies and Gentlemen,

>If the desire is to extend current SONET/SDH with an arbitrary
>concatenation feature, there is no problem to contribute to T1X1
>and/or ITU-T to propose this extension. This is the correct way to
>approach it. The INCORRECT way is to confuse the market by producing
>an IETF version of SONET/SDH specs that is different from T1X1/ITU-T.

Please note that the IETF is NOT producing any version of the SONET/SDH
specs. We should avoid such a misunderstanding because it is confusing the
market.

We are simply trying to define reasonable and simple signalling elements to
control some TDM features. These TDM features can be some that were
specified by ITU-T or T1X1, and/or some that are a common practice in the
industry (like transparency), and/or some that we think/envision that will
be important to control in the future. That's called creativity and that's
really cool !

Kind regards,

Eric

Eric Mannie
EBONE (GTS)

Delivery-date: Thu, 17 May 2001 13:15:44 -0700
From: Steve West <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Cc: 'Zhi-Wei Lin' <[email-masked]>, 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>,  [email-masked], [email-masked], [email-masked],  "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 12:51:36 -0700

Greg:

It seems that you have a scheme that allows better utilization of a link by
including a new type of concatenation hardware, just at the ends of that
link.  If I understand, the concatenation method allows you to remove the
requirement for "contiguous" sts1/columns in the SONET/SDH payload, by
"leap-frogging" over columns that are in-use and thus "in-the-way" ?  

If my read is right, why not also present this "leap-frog" arbitrary
concatenation scheme to the relevent standards authorities (ANSI/ETSI/ITU),
so that the experts there can validate its applicability?

Steve West

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 11:39 AM
To: Bernstein, Greg
Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
[email-masked]; [email-masked]; t1x1.5; q11/15
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

There is no intent in any of the standardization bodies to stifle
innovation. Standards are contribution driven, and what you find
in the documents as written are the product of those contributions.

If the desire is to extend current SONET/SDH with an arbitrary
concatenation feature, there is no problem to contribute to T1X1
and/or ITU-T to propose this extension. This is the correct way to
approach it. The INCORRECT way is to confuse the market by producing
an IETF version of SONET/SDH specs that is different from T1X1/ITU-T.

Let me add some background on how we ended up with the current
situation recommending virtual concatenation in SONET/SDH:

1. Contiguous or Arbitrary concatenation requires implementation
of the concatenation method at every NE along the chosen path
through the network to provide a service. At the time we began
these discussions, we had the problem that ATM wanted to use
VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
links in the network and NEs that didn't support trails
bigger than VC-4 (STS-3c). By now, of course, VC-4-4c (STS-12c)
and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
but as has been observed in previous emails, it will be a
long time before you replace all of the 2.5G links in the
network, so contiguous/arbitrary concatenation to greater
than VC-4-16c/STS-48c is still a problem for some time to
come. The endpoints in a network always seem to evolve ahead
of and faster than links and equipment in the core network
can be replaced, so it was important to define a concatenation
method that could be implemented only by the endpoints.

2. Contiguous/arbitrary concatenation is not as elgant for
lower order paths as for higher order paths. We saw in
a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
into an STM-1, but most equipment does not provide the
ability to concatenate lower order paths. For certain
payloads, lower order paths fit better, e.g., 5 x VC-12
to carry 10Mb Ethernet.

3. Different payloads to not fit ideally into "standard"
multiples found in contiguous concatenation (4, 16, 64,
256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

4. As paths are set up or taken down in a network, there is
a tendency for capacity to become fragmented. Contiguous/
arbitrary concatenation cannot always take advantage of
free timeslots along a span if they are not adjacent on
the same fiber or if they are on different fibers.

5. LCAS was easier to envision in a virtual concatenation
environment. Many of the new services are not inherently
constant bit rate, and it can be useful to dynamically
add or remove components of the bundle to adjust link
capacity. It is also useful to be able to handle failures
of individual components of the concatenated trail by
just reducing the capacity rather than by having to
protection switch the entire path.

Virtual concatenation was designed to solve all of the above
problems. Arbitrary concatenation is another way to solve
problem (3) above, but it doesn't solve the others. Given
that virtual concatenation is standardized to solve all
of the problems, it reduces the pressure to implement
arbitrary concatenation throughout the network to solve
only problem (3).

If problem (3) is the only one you are trying to solve,
arbitrary concatenation has the advantage of not requiring
so much buffer space at the endpoints to accomodate
differential delay. But with trends in memory costs, this
is not so much of an issue, and this needs to be traded
off against the need to provide support for the contiguous/
arbitrary rate and all associated protection mechanisms at
EVERY NE along the chosen path in the network in order for
this to work.

If there is a significant market for applications where
solving (3) is vital but (1,2,4,5) are not so important,
then it may be worth pushing arbitrary concatenation as
a way to optimize how those services are provided over
what you get with virtual concatenation.

Regards,
Steve Trowbridge

"Bernstein, Greg" wrote:
> 
> To avoid re-grooming either virtual concatenation or arbitrary
concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we can't or
don't
> want to re-groom then we have two options:
> (1)     Require that ALL end systems that could potentially use this link
> convert over to virtual concatenation from standard concatenation.
> (2)     Or, install boxes at both ends of the link that support the
> arbitrary concatenation that we've been discussing.
> 
> Which of these seems more realistic and practical?
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Zhi-Wei Lin [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 To:     Bernstein, Greg
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        Re: [IP-Optical] concatenation extensions
in
> sonet/sdh
> 
>                 Hi,
> 
>                 some observations:
> 
>                 in terms of re-grooming and such, I believe both virtual
> concatenation
>                 and arbitrary concatenation can perform this. One method
is
>                 standardized, the other is proprietary.
> 
>                 In terms of routing of the individual connections that
make
> up the
>                 concatenated signal, virtual concatenation is more
flexible
> than
>                 arbitrary concatenation, since you can put each component
VC
> in
>                 different lines, and each component can be routed
> differently.
> 
>                 In terms of interworking, yes the SIGNALLING can
defnititely
> be made to
>                 interwork. However, the larger issue for interworking is
> support by the
>                 transport equipment themselves. Thus interworking involves
> TWO parts:
>                 signaling interworking and transport interworking. Having
> one without
>                 the other doesn't really help...
> 
>                 Thus, in terms of solving real problems, either virtual or
> arbitrary can
>                 accomplish that, but IMO, virtual seems more
flexible...and
>                 standardized...
> 
>                 In terms of standards as fostering interoperability and
> stifling of
>                 innovation, in principle yes I agree. And therefore if
> arbitrary
>                 concatenation should be standardized, it should be
> standardized in the
>                 correct standards body. As Maarten mentioned, the relevant
> standards
>                 bodies discussed arbitrary concatenation years ago, and
> decided
>                 (hopefully based on their expert technical opinion - I
> wasn't involved)
>                 not to include arbitrary but instead to include virtual.
> IMO, there must
>                 be good reasons, and from what I can tell, I see virtual
as
> been more
>                 flexible so that is a pretty good reason...we at IETF,
being
> protocol
>                 experts (and budding transport experts?) should not try to
> second-guess
>                 the decisions without fully understanding the
> ramifications...
> 
>                 As for stifling innovation, anytime you standardize
anything
> there is
>                 always some factor of development that gets fixed (is this
> something
>                 that should not be said in a public forum??? -- sorry!!).
> Therefore
>                 there is always a tradeoff between innovation and
> standardization. I
>                 think the job of standards bodies is to try to balance
these
> two factors
>                 such that the industry in general can live with the result
> without
>                 unduly burdening...
> 
>                 agree?
> 
>                 Zhi
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > A couple more points.
>                 > (1)     GMPLS works well with arbitrary concatenations
> need to specify the
>                 > time slots since it provides a signaling protocol that
can
> do just that,
>                 > i.e., GMPLS actually enables this feature to
interoperate.
>                 > (2)     Arbitrary concatenation offers a solution to a
> real problem, i.e.,
>                 > eliminates the need for re-grooming on lines that
support
> it.  For those who
>                 > have invested non-trivial amounts of money in
transoceanic
> links this can be
>                 > a significant savings.
>                 > (3)     The goal is interoperability and to solve real
> problems.  We've got
>                 > a real problem and with a minor edit to the GMPLS SONET
> specification we can
>                 > have an interoperable method for solving it.
>                 >
>                 > To be precise in the definition of arbitrary
> concatenation:
>                 > As a concatenated signal within a single SONET Line (SDH
> MS), with
>                 > potentially arbitrary timeslots used for its components.
>                 >
>                 > The current main application is: avoiding the need for
> service impacting
>                 > re-grooming. Note that this applies to standard sized
> signals and is a per
>                 > link property.
>                 >
>                 > Other applications do exist and are somewhat competitive
> with non-LCAS
>                 > virtual concatenation since the implementation of
> arbitrary concatenation
>                 > for odd sized signals is simpler than that of virtual
> concatenation.  Once
>                 > "odd" sized signals are used an entire path through the
> network must exist
>                 > that supports them.
>                 >
>                 > Folks I thought the role of standards organizations was
to
> foster
>                 > interoperability that enables the industry to move
forward
> rather than as a
>                 > means to stifle innovation. I think it is better for the
> marketplace to
>                 > decide which features are desirable.
>                 >
>                 > Greg B.
>                 >
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >

Delivery-date: Thu, 17 May 2001 13:08:17 -0700
Date: Thu, 17 May 2001 16:03:50 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Steve West <[email-masked]>
CC: "'Stephen Trowbridge'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi Steve,

>From everything I've read of the emails, I think that's the wrong
assumption.

>From what folks are saying, arbitrary concatenation REQUIRES both
endpoints and intermediate nodes to be upgraded, while virtual
concatenation ONLY require endpoints to be upgraded.

Both arbitrary and virtual allows better utilization.

Hope I'm not saying anything completely wrong!

Zhi

Steve West wrote:
> 
> Greg:
> 
> It seems that you have a scheme that allows better utilization of a link by
> including a new type of concatenation hardware, just at the ends of that
> link.  If I understand, the concatenation method allows you to remove the
> requirement for "contiguous" sts1/columns in the SONET/SDH payload, by
> "leap-frogging" over columns that are in-use and thus "in-the-way" ?
> 
> If my read is right, why not also present this "leap-frog" arbitrary
> concatenation scheme to the relevent standards authorities (ANSI/ETSI/ITU),
> so that the experts there can validate its applicability?
> 
> Steve West
> 
> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Thursday, May 17, 2001 11:39 AM
> To: Bernstein, Greg
> Cc: 'Zhi-Wei Lin'; 'Maarten Vissers'; Anup Tirumala; [email-masked];
> [email-masked]; [email-masked]; t1x1.5; q11/15
> Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh
> 
> There is no intent in any of the standardization bodies to stifle
> innovation. Standards are contribution driven, and what you find
> in the documents as written are the product of those contributions.
> 
> If the desire is to extend current SONET/SDH with an arbitrary
> concatenation feature, there is no problem to contribute to T1X1
> and/or ITU-T to propose this extension. This is the correct way to
> approach it. The INCORRECT way is to confuse the market by producing
> an IETF version of SONET/SDH specs that is different from T1X1/ITU-T.
> 
> Let me add some background on how we ended up with the current
> situation recommending virtual concatenation in SONET/SDH:
> 
> 1. Contiguous or Arbitrary concatenation requires implementation
> of the concatenation method at every NE along the chosen path
> through the network to provide a service. At the time we began
> these discussions, we had the problem that ATM wanted to use
> VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
> links in the network and NEs that didn't support trails
> bigger than VC-4 (STS-3c). By now, of course, VC-4-4c (STS-12c)
> and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
> but as has been observed in previous emails, it will be a
> long time before you replace all of the 2.5G links in the
> network, so contiguous/arbitrary concatenation to greater
> than VC-4-16c/STS-48c is still a problem for some time to
> come. The endpoints in a network always seem to evolve ahead
> of and faster than links and equipment in the core network
> can be replaced, so it was important to define a concatenation
> method that could be implemented only by the endpoints.
> 
> 2. Contiguous/arbitrary concatenation is not as elgant for
> lower order paths as for higher order paths. We saw in
> a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
> into an STM-1, but most equipment does not provide the
> ability to concatenate lower order paths. For certain
> payloads, lower order paths fit better, e.g., 5 x VC-12
> to carry 10Mb Ethernet.
> 
> 3. Different payloads to not fit ideally into "standard"
> multiples found in contiguous concatenation (4, 16, 64,
> 256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
> fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.
> 
> 4. As paths are set up or taken down in a network, there is
> a tendency for capacity to become fragmented. Contiguous/
> arbitrary concatenation cannot always take advantage of
> free timeslots along a span if they are not adjacent on
> the same fiber or if they are on different fibers.
> 
> 5. LCAS was easier to envision in a virtual concatenation
> environment. Many of the new services are not inherently
> constant bit rate, and it can be useful to dynamically
> add or remove components of the bundle to adjust link
> capacity. It is also useful to be able to handle failures
> of individual components of the concatenated trail by
> just reducing the capacity rather than by having to
> protection switch the entire path.
> 
> Virtual concatenation was designed to solve all of the above
> problems. Arbitrary concatenation is another way to solve
> problem (3) above, but it doesn't solve the others. Given
> that virtual concatenation is standardized to solve all
> of the problems, it reduces the pressure to implement
> arbitrary concatenation throughout the network to solve
> only problem (3).
> 
> If problem (3) is the only one you are trying to solve,
> arbitrary concatenation has the advantage of not requiring
> so much buffer space at the endpoints to accomodate
> differential delay. But with trends in memory costs, this
> is not so much of an issue, and this needs to be traded
> off against the need to provide support for the contiguous/
> arbitrary rate and all associated protection mechanisms at
> EVERY NE along the chosen path in the network in order for
> this to work.
> 
> If there is a significant market for applications where
> solving (3) is vital but (1,2,4,5) are not so important,
> then it may be worth pushing arbitrary concatenation as
> a way to optimize how those services are provided over
> what you get with virtual concatenation.
> 
> Regards,
> Steve Trowbridge
> 
> "Bernstein, Greg" wrote:
> >
> > To avoid re-grooming either virtual concatenation or arbitrary
> concatenation
> > can help, but the implications are quite different.
> > Say we have a particularly valuable (expensive) link that we can't or
> don't
> > want to re-groom then we have two options:
> > (1)     Require that ALL end systems that could potentially use this link
> > convert over to virtual concatenation from standard concatenation.
> > (2)     Or, install boxes at both ends of the link that support the
> > arbitrary concatenation that we've been discussing.
> >
> > Which of these seems more realistic and practical?
> > Greg B.
> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >         New phone: (510) 573-2237
> >
> >                 -----Original Message-----
> >                 From:   Zhi-Wei Lin [mailto:[email-masked]]
> >                 Sent:   Thursday, May 17, 2001 8:41 AM
> >                 To:     Bernstein, Greg
> >                 Cc:     'Maarten Vissers'; Anup Tirumala;
> > [email-masked]; [email-masked]; [email-masked];
> > t1x1.5; q11/15
> >                 Subject:        Re: [IP-Optical] concatenation extensions
> in
> > sonet/sdh
> >
> >                 Hi,
> >
> >                 some observations:
> >
> >                 in terms of re-grooming and such, I believe both virtual
> > concatenation
> >                 and arbitrary concatenation can perform this. One method
> is
> >                 standardized, the other is proprietary.
> >
> >                 In terms of routing of the individual connections that
> make
> > up the
> >                 concatenated signal, virtual concatenation is more
> flexible
> > than
> >                 arbitrary concatenation, since you can put each component
> VC
> > in
> >                 different lines, and each component can be routed
> > differently.
> >
> >                 In terms of interworking, yes the SIGNALLING can
> defnititely
> > be made to
> >                 interwork. However, the larger issue for interworking is
> > support by the
> >                 transport equipment themselves. Thus interworking involves
> > TWO parts:
> >                 signaling interworking and transport interworking. Having
> > one without
> >                 the other doesn't really help...
> >
> >                 Thus, in terms of solving real problems, either virtual or
> > arbitrary can
> >                 accomplish that, but IMO, virtual seems more
> flexible...and
> >                 standardized...
> >
> >                 In terms of standards as fostering interoperability and
> > stifling of
> >                 innovation, in principle yes I agree. And therefore if
> > arbitrary
> >                 concatenation should be standardized, it should be
> > standardized in the
> >                 correct standards body. As Maarten mentioned, the relevant
> > standards
> >                 bodies discussed arbitrary concatenation years ago, and
> > decided
> >                 (hopefully based on their expert technical opinion - I
> > wasn't involved)
> >                 not to include arbitrary but instead to include virtual.
> > IMO, there must
> >                 be good reasons, and from what I can tell, I see virtual
> as
> > been more
> >                 flexible so that is a pretty good reason...we at IETF,
> being
> > protocol
> >                 experts (and budding transport experts?) should not try to
> > second-guess
> >                 the decisions without fully understanding the
> > ramifications...
> >
> >                 As for stifling innovation, anytime you standardize
> anything
> > there is
> >                 always some factor of development that gets fixed (is this
> > something
> >                 that should not be said in a public forum??? -- sorry!!).
> > Therefore
> >                 there is always a tradeoff between innovation and
> > standardization. I
> >                 think the job of standards bodies is to try to balance
> these
> > two factors
> >                 such that the industry in general can live with the result
> > without
> >                 unduly burdening...
> >
> >                 agree?
> >
> >                 Zhi
> >
> >                 "Bernstein, Greg" wrote:
> >                 >
> >                 > A couple more points.
> >                 > (1)     GMPLS works well with arbitrary concatenations
> > need to specify the
> >                 > time slots since it provides a signaling protocol that
> can
> > do just that,
> >                 > i.e., GMPLS actually enables this feature to
> interoperate.
> >                 > (2)     Arbitrary concatenation offers a solution to a
> > real problem, i.e.,
> >                 > eliminates the need for re-grooming on lines that
> support
> > it.  For those who
> >                 > have invested non-trivial amounts of money in
> transoceanic
> > links this can be
> >                 > a significant savings.
> >                 > (3)     The goal is interoperability and to solve real
> > problems.  We've got
> >                 > a real problem and with a minor edit to the GMPLS SONET
> > specification we can
> >                 > have an interoperable method for solving it.
> >                 >
> >                 > To be precise in the definition of arbitrary
> > concatenation:
> >                 > As a concatenated signal within a single SONET Line (SDH
> > MS), with
> >                 > potentially arbitrary timeslots used for its components.
> >                 >
> >                 > The current main application is: avoiding the need for
> > service impacting
> >                 > re-grooming. Note that this applies to standard sized
> > signals and is a per
> >                 > link property.
> >                 >
> >                 > Other applications do exist and are somewhat competitive
> > with non-LCAS
> >                 > virtual concatenation since the implementation of
> > arbitrary concatenation
> >                 > for odd sized signals is simpler than that of virtual
> > concatenation.  Once
> >                 > "odd" sized signals are used an entire path through the
> > network must exist
> >                 > that supports them.
> >                 >
> >                 > Folks I thought the role of standards organizations was
> to
> > foster
> >                 > interoperability that enables the industry to move
> forward
> > rather than as a
> >                 > means to stifle innovation. I think it is better for the
> > marketplace to
> >                 > decide which features are desirable.
> >                 >
> >                 > Greg B.
> >                 >
> >                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >                 >         New phone: (510) 573-2237
> >                 >

Delivery-date: Thu, 17 May 2001 12:54:24 -0700
Cc: [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Date: Thu, 17 May 2001 21:53:09 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
Original-CC: [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

This is a multi-part message in MIME format.
--------------D938371722455189C3761FCC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greg,

> Other applications do exist and are somewhat competitive with non-LCAS
> virtual concatenation since the implementation of arbitrary concatenation
> for odd sized signals is simpler than that of virtual concatenation.  Once
> "odd" sized signals are used an entire path through the network must exist
> that supports them.

I do not understand the sentence above. Using virtual concatenation,
"odd" sized signals (e.g. a VC-4-11v) require that only the two
endpoints (where you terminate the "odd" sized signal to access the
client signal in the payload) must be aware of the "odd size". All the
rest of the equipment inbetween the two endpoints doesn't have to be
aware of the odd size at all, as they only see a normal basic size (e.g.
11x VC-4).

Using arbitrary concatenation, "odd" sized signals (e.g. a VVC-4-11a
("a" to represent "arbitrary concatenation")) require that the two
endpoints and all intermediate STM-N/OC-N ports must be aware of the
"odd size". The AU/STS pointer processors in those STM-N/OC-N ports must
first support this arbitrary concatenation (AU-4-Xa, STS-Xa), and
besides this need to be provisioned specifically with the AU/STS time
slots that are occupied by the AU-4-Xa, STS-Xa.

For the network therefore virtual concatenation is simpler than
arbitrary concatenation. 

Other comments are below:

"Bernstein, Greg" wrote:
> 
> A couple more points.
> (1)     GMPLS works well with arbitrary concatenations need to specify the
> time slots since it provides a signaling protocol that can do just that,
> i.e., GMPLS actually enables this feature to interoperate.
> (2)     Arbitrary concatenation offers a solution to a real problem, i.e.,
> eliminates the need for re-grooming on lines that support it.  For those who
> have invested non-trivial amounts of money in transoceanic links this can be
> a significant savings.

I agree that a HOVC/STS cross connect supporting arbitrary concatenation
at its line ports facing the cable prevents the need for bandwidth
defragmentation. It's nice if you have it, but investigations I was
involved in in the past weren't seeing fragmentation as a real problem.
It wasn't something that had to be done on a daily basis... But the
situation may have been changed since then...

> (3)     The goal is interoperability and to solve real problems.  We've got
> a real problem and with a minor edit to the GMPLS SONET specification we can
> have an interoperable method for solving it.

The "real problem" seems to be focused on the transatlantic cable where
the grooming function in the head end cross connect takes the
standardised regular STS/HOVC signals from the terrestrial network and
forwards those onto the cable. This is a network internal optimisation,
in essense invisible to the "outside world"; i.e. the UNI or E-NNI would
not show the details of this to the other networks of
customers/operators.

> 
> To be precise in the definition of arbitrary concatenation:
> As a concatenated signal within a single SONET Line (SDH MS), with
> potentially arbitrary timeslots used for its components.
> 
> The current main application is: avoiding the need for service impacting
> re-grooming. Note that this applies to standard sized signals and is a per
> link property.

If it is per link proprietary, it is by definition not part of a
standard interface; and thus there is no need to show it in a standard
control plane message. The proprietary link simply supports the standard
STS/HOVC link connection types; in addition it will not have the
"blocking" effect a regular link may have when it gets fragmented and
isn't able to quickly perform a link defrag operation. It also implies
that the rules for the "pamXXX" link parameters (see G.85x and other
email correspondence) will be somewhat different.

> 
> Other applications do exist and are somewhat competitive with non-LCAS
> virtual concatenation since the implementation of arbitrary concatenation
> for odd sized signals is simpler than that of virtual concatenation.  Once
> "odd" sized signals are used an entire path through the network must exist
> that supports them.

See begin of this email.

> 
> Folks I thought the role of standards organizations was to foster
> interoperability that enables the industry to move forward rather than as a
> means to stifle innovation. I think it is better for the marketplace to
> decide which features are desirable.

Indeed standards are to foster interoperability. And it is a serious
interoperability concern that is causing this reaction from me. About a
year ago all members of ITU-T and T1 agreed to remove arbitrary
contiguous concatenation from the T1.105 and G.707 standards to prevent
another serious interoperability issue to be introduced into the world
wide SONET/SDH network. This to provide a clear indication to the client
equipment (e.g. IP router, ATM switch, ethernet switch) manufacturers
that the SONET/SDH network doesn't support such arbitrary contiguous
concatenated STS/VC-4 signals. And it is for this reason somewhat
"inappropriate" to revert this indication in a transport network control
plane specification. This would be a clear inconsistency, and
inconsistencies only cause trouble for all parties...

Regards,

Maarten
--------------D938371722455189C3761FCC
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------D938371722455189C3761FCC--

Delivery-date: Thu, 17 May 2001 12:05:43 -0700
Date: Thu, 17 May 2001 15:03:18 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Alan J Weissberger <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes

Hi Alan,

I agree with you. We should include this as an item for discussion next
week. If we cannot resolve, we have the upcoming June meeting to
continue, plus the email exchange...

Continuing the TCM discussion, I guess two scenarios could be
envisioned:

1) Control plane handles set up of TCM for control plane monitoring
2) Control coordinates with management plane for TCM set up. In this
case, two sub-scenarios are also possible:
  a) After TCM is set up by mgmt, control takes over monitoring (some
info exchange is needed between planes)
  b) After TCM is set up, mgmt monitors

Based on what Tammy stated that there will mostly likely always be a
mgmt plane in addition to control plane, and mgmt plane has TCM, do we
want to embark on defining monitoring/TCM setup using control? Which is
the better option: 1, 2a or 2b?

And if I were to be drastic (not that I would ;-), I might even state
that since we are designing this for a switched network where connection
could be set up quickly and state of a connection is measured with
different parameters (e.g., not just availability...??), maybe we can
even consider TCM as optional only for certain types of connections...

Regards,

Zhi

Alan J Weissberger wrote:
> 
> All
> 
> I agree with Tammy's remarks below regarding the jurisdiction of the control
> plane.  We do have a G.874 LL item on Interworking between Mgt and Control
> planes and this takes on more importance with soft PC's.  I see 3 critical
> interactions between these two planes:
> 
> 1.  SPCs: management plane initiates connection, control plane (NNI sig &
> Routing) executes, then informs mgt plane of outcome of connection setup request
> (see attached illustration).  PM and fault management done in management plane
> 
> 
> 2.  Resiliency/ self healing: Management plane sets up connection, but control
> plane is notified of the path to do restoration on a hard failure.  Conversely,
> control plane sets up the connection, but management plane notified to do
> protection on a SONET/SDH path or line layer basis
> 
> 3.  Control plane sets up an OTN connection, management plane is notified to
> activate G.709 TCM sessions (or they may be pre-allocated along predefined paths
> 
> There are others as well, but I believe the above three are most important
> 
> I suggest we address this "co-ordination between planes" issue on May 21-22,
> when we have the ASON discussions in Caracas.
> 
> rgds
> 
> alan W
> 
> Quoting [email-masked]:
> 
> > Shiva,
> > Traditionally, often different systems are responsible for different
> > management functions relating to the same resources.
> >
> > I think it is important to define and keep in mind scope.  For example,
> > as I currently understand it, the control plane is only required to
> > control path set-up within a single layer network (while interacting
> > with other layers as needed to do its job).
> >
> > Network/Service management (management plane) needs scope of all layers
> > and interfaces that cross administrative boundaries.
> >
> > My current view is that the control plane is mainly responsible for
> > connection set-up and tear-down (network engineering) and traffic
> > management for those resources it has been allocated.  If, for some
> > reason, it cannot do its' job (e.g. failure of a control channel), it
> > should be reporting such failures to the management plane.
> > Tammy
> > -----Original Message-----
> > From: ssnarayanan [mailto:[email-masked]]
> > Sent: Thursday, May 17, 2001 08:47
> > To: zwlin
> > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > tsg15q12; tsg15q14
> > Subject: Re: ASTN Layer Network Architecture
> >
> >
> > Tammy, Maarten and Zhi,
> >   Along the lines of Zhi's question, it is also fundamental to know
> > which plane "owns" the management responsibility for the connection,
> > e.g., if a SPC is setup, then is it the management plane which owns this
> > or the control plane.  The management plane initiates the request, but
> > the control plane executes the request via NNI signaling.  As far as I
> > see, if we resolve this issue, then we can get a better understanding of
> > what is meant by "migrating" a connection from the management plane to
> > the control plane control.
> >
> > Regards,
> > Shiva
> > ------------------
> > Sivakumar Sankaranarayanan
> > Member of Technical Staff
> > HO 3C-508A
> > Lucent Technologies,
> > 101 Crawfords Corner Road,
> > Holmdel, NJ 07733.
> >
> > Phone:        +1 732 949 5762
> > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > Email:        [email-masked]
> >
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: [email-masked]
> 
>   ------------------------------------------------------------------------
>                Name: SPCs.ppt
>    SPCs.ppt    Type: Microsoft PowerPoint Show (application/vnd.ms-powerpoint)
>            Encoding: base64

Delivery-date: Thu, 17 May 2001 12:04:14 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Mike Scholten' <[email-masked]>, Zhi-Wei Lin <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked],  [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 12:01:45 -0700

Hi Mike consider the case with standard sizes and but potentially
non-standard timeslots. A box that can use arbitrary concatenation and
restricts itself to standard concatenation when dealing with boxes that
don't support arbitrary concatenation. But links that do support arbitrary
concatenation (standard sizes, any slots) do not have to worry about
re-grooming.

I agree with you that for general interoperability when one wants
non-standard sizes one should use Virtual Concatenation.
GB
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Mike Scholten [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 10:14 AM
		To:	Zhi-Wei Lin
		Cc:	Bernstein, Greg; 'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	Re: [IP-Optical] concatenation extensions in
sonet/sdh

		 << File: Card for Michael Scholten >> Greg, Zhi:

		A more important consideration that seems to be lost
(although Maarten made the point), is that intermediate nodes may not
		accept and handle "arbitrary concatenation," where arbitrary
is defined as STS-nc with n != 3, 12, 48, 192, 768.  Many pointer
		processors in these intermediate nodes, upon examining the
H1, H2 bytes where the concatenation indicators exist, will declare
		Loss-of-Pointer (LOP) when an unrecognized "arbitrary
concatenation" pattern is seen, causing the path to be declared as failed,
		initiating a protection switch.  In order to support
arbitrary concatenation, equipment in these intermediate nodes would also
		have to be replaced.

		No intermediate node equipment needs to be replaced to
support virtual concatenation, since member paths are simply routed as
		STS-1 or STS-3c paths.

		All of the above comments apply to ITU equivalents (e.g.
arbitrary concatenation would be defined as VC-4-nc with n != 4, 16,
		64, 256;  VC-path member paths simply routed as VC-3 or VC-4
paths).

		Regards, Mike

		Zhi-Wei Lin wrote:

		> Hi Greg,
		>
		> Let me change a few words in your example:
		>
		> > (1)     Require that ALL end systems that could
potentially use this link
		> > convert over to arbitrary concatenation from standard
concatenation.
		>                   ^^^^^^^^^
		> > (2)     Or, install boxes at both ends of the link that
support the
		> > virtual concatenation that we've been discussing.
		>   ^^^^^^^
		>
		> I think the two example are different. #1 talks about
potentially use
		> the link. That's also true of arbitrary or virtual.
		>
		> #2 talks about only a pair of endpoints that support this.
That's also
		> true of either virtual or arbitrary.
		>
		> Another observation:
		>
		> Arbitrary or virtual concatenation only impacts the
endpoints, and for
		> any application either concatenation method would impact
the same
		> endpoints, and therefore would require the same amount of
change of the
		> endpoints.
		>
		> Example:
		>
		>  +-----+   +----+    +----+    +----+    +--------+
		>  | A   |---| B  |----| C  |----| D  |----|    Z   |
		>  +-----+   +----+    +----+    +----+    +--------+
		>      \                                    /
		>       \                                  /
		>        \   +----+    +----+    +----+   /
		>         \--| E  |----| F  |----| G  |--/
		>            +----+    +----+    +----+
		>
		> Assumes a VC-4-3c (or VC-4-3v) is requested.
		>
		> With arbitrary concatenation, each component can be placed
in any
		> timeslot, but they all traverse A-B-C-D-Z or A-E-F-G-Z. A
and Z needs
		> special functions. But since you mentioned that arbitrary
concat assumes
		> that the timeslots are sequential ordered (i.e., info in
timeslot 1-6-8
		> cannot be rearranged 1-8-6), the intermediate nodes need
certain
		> constraints on re-ordering (constraining the TSI
capability).
		>
		> With virtual concat, each component can be placed in any
timeslot, and
		> each component can travel different routes, so timeslot 1
& 8 can
		> traverse A-B-C-D-Z while timeslot 6 can traverse
A-E-F-G-Z. A and Z
		> needs special functions. However, as each timeslot is
treated as a
		> separate connection, the intermediate nodes do not need
any info or
		> constrained. The A node, when deciding the route (source
routing) will
		> take the differential delays into account. And according
to Maarten's
		> previous email, current state-of-the-art can handle
differential delays
		> where the differential path distance between two component
can be up to
		> 3000 km (was this the right figure???) -- 3000 km is quite
a bit
		> DIFFERENTIAL distance.
		>
		> Hope this helps with the discussion...
		>
		> Zhi
		>
		> "Bernstein, Greg" wrote:
		> >
		> > To avoid re-grooming either virtual concatenation or
arbitrary concatenation
		> > can help, but the implications are quite different.
		> > Say we have a particularly valuable (expensive) link
that we can't or don't
		> > want to re-groom then we have two options:
		> > (1)     Require that ALL end systems that could
potentially use this link
		> > convert over to virtual concatenation from standard
concatenation.
		> > (2)     Or, install boxes at both ends of the link that
support the
		> > arbitrary concatenation that we've been discussing.
		> >
		> > Which of these seems more realistic and practical?
		> > Greg B.
		> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
		> >         New phone: (510) 573-2237
		> >
		> >                 -----Original Message-----
		> >                 From:   Zhi-Wei Lin
[mailto:[email-masked]]
		> >                 Sent:   Thursday, May 17, 2001 8:41 AM
		> >                 To:     Bernstein, Greg
		> >                 Cc:     'Maarten Vissers'; Anup
Tirumala;
		> > [email-masked]; [email-masked];
[email-masked];
		> > t1x1.5; q11/15
		> >                 Subject:        Re: [IP-Optical]
concatenation extensions in
		> > sonet/sdh
		> >
		> >                 Hi,
		> >
		> >                 some observations:
		> >
		> >                 in terms of re-grooming and such, I
believe both virtual
		> > concatenation
		> >                 and arbitrary concatenation can perform
this. One method is
		> >                 standardized, the other is proprietary.
		> >
		> >                 In terms of routing of the individual
connections that make
		> > up the
		> >                 concatenated signal, virtual
concatenation is more flexible
		> > than
		> >                 arbitrary concatenation, since you can
put each component VC
		> > in
		> >                 different lines, and each component can
be routed
		> > differently.
		> >
		> >                 In terms of interworking, yes the
SIGNALLING can defnititely
		> > be made to
		> >                 interwork. However, the larger issue for
interworking is
		> > support by the
		> >                 transport equipment themselves. Thus
interworking involves
		> > TWO parts:
		> >                 signaling interworking and transport
interworking. Having
		> > one without
		> >                 the other doesn't really help...
		> >
		> >                 Thus, in terms of solving real problems,
either virtual or
		> > arbitrary can
		> >                 accomplish that, but IMO, virtual seems
more flexible...and
		> >                 standardized...
		> >
		> >                 In terms of standards as fostering
interoperability and
		> > stifling of
		> >                 innovation, in principle yes I agree.
And therefore if
		> > arbitrary
		> >                 concatenation should be standardized, it
should be
		> > standardized in the
		> >                 correct standards body. As Maarten
mentioned, the relevant
		> > standards
		> >                 bodies discussed arbitrary concatenation
years ago, and
		> > decided
		> >                 (hopefully based on their expert
technical opinion - I
		> > wasn't involved)
		> >                 not to include arbitrary but instead to
include virtual.
		> > IMO, there must
		> >                 be good reasons, and from what I can
tell, I see virtual as
		> > been more
		> >                 flexible so that is a pretty good
reason...we at IETF, being
		> > protocol
		> >                 experts (and budding transport experts?)
should not try to
		> > second-guess
		> >                 the decisions without fully
understanding the
		> > ramifications...
		> >
		> >                 As for stifling innovation, anytime you
standardize anything
		> > there is
		> >                 always some factor of development that
gets fixed (is this
		> > something
		> >                 that should not be said in a public
forum??? -- sorry!!).
		> > Therefore
		> >                 there is always a tradeoff between
innovation and
		> > standardization. I
		> >                 think the job of standards bodies is to
try to balance these
		> > two factors
		> >                 such that the industry in general can
live with the result
		> > without
		> >                 unduly burdening...
		> >
		> >                 agree?
		> >
		> >                 Zhi
		> >
		> >                 "Bernstein, Greg" wrote:
		> >                 >
		> >                 > A couple more points.
		> >                 > (1)     GMPLS works well with
arbitrary concatenations
		> > need to specify the
		> >                 > time slots since it provides a
signaling protocol that can
		> > do just that,
		> >                 > i.e., GMPLS actually enables this
feature to interoperate.
		> >                 > (2)     Arbitrary concatenation offers
a solution to a
		> > real problem, i.e.,
		> >                 > eliminates the need for re-grooming on
lines that support
		> > it.  For those who
		> >                 > have invested non-trivial amounts of
money in transoceanic
		> > links this can be
		> >                 > a significant savings.
		> >                 > (3)     The goal is interoperability
and to solve real
		> > problems.  We've got
		> >                 > a real problem and with a minor edit
to the GMPLS SONET
		> > specification we can
		> >                 > have an interoperable method for
solving it.
		> >                 >
		> >                 > To be precise in the definition of
arbitrary
		> > concatenation:
		> >                 > As a concatenated signal within a
single SONET Line (SDH
		> > MS), with
		> >                 > potentially arbitrary timeslots used
for its components.
		> >                 >
		> >                 > The current main application is:
avoiding the need for
		> > service impacting
		> >                 > re-grooming. Note that this applies to
standard sized
		> > signals and is a per
		> >                 > link property.
		> >                 >
		> >                 > Other applications do exist and are
somewhat competitive
		> > with non-LCAS
		> >                 > virtual concatenation since the
implementation of
		> > arbitrary concatenation
		> >                 > for odd sized signals is simpler than
that of virtual
		> > concatenation.  Once
		> >                 > "odd" sized signals are used an entire
path through the
		> > network must exist
		> >                 > that supports them.
		> >                 >
		> >                 > Folks I thought the role of standards
organizations was to
		> > foster
		> >                 > interoperability that enables the
industry to move forward
		> > rather than as a
		> >                 > means to stifle innovation. I think it
is better for the
		> > marketplace to
		> >                 > decide which features are desirable.
		> >                 >
		> >                 > Greg B.
		> >                 >
		> >                 >         Dr. Greg M. Bernstein, Senior
Scientist, Ciena
		> >                 >         New phone: (510) 573-2237
		> >                 >

Delivery-date: Thu, 17 May 2001 11:55:55 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Lazer, Monica A, NNAD'" <[email-masked]>, 'Zhi-Wei Lin' <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked],  [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Thu, 17 May 2001 11:52:25 -0700

Are we having fun for a Thursday, or what?
Zhi, had me convinced that I should do a "start up" specializing in virtual
concatenation for link bandwidth optimization, then Monica asked me about
overhead use in arbitrary concatenation...
Here are some more points:
(1)	Arbitrary concatenation (assuming standard sizes) is fairly minor
tweak of standard contiguous concatenation, i.e., the framer just needs to
be told the starting time slot (which has the pointer) and the remaining
(arbitrary) time slots (which have the concatenation indication set).  No
path overhead is used for this process.  It is strictly a line level
operation, e.g., B3 is not recalculated.  This is suitable for LTE equipment
and has nice consequences for avoiding re-grooming.
(2)	Virtual concatenation is a whole new and useful feature that uses
path level overhead, in particular the H4 byte.  Hence the path level BIP B3
needs to recalculated.  This is more a PTE (path termination equipment) kind
of thing to do.  Not something that a typical switch would necessarily want
to do for compatibility purposes. This was intended for a much more
sophisticated application, i.e., a path level "bonding" or inverse
multiplexing, but it lacks path level transparency if used to avoid
regrooming.

Hope this puts some more gasoline (petrol) onto the fire.

Greg B.

	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Lazer, Monica A, NNAD [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 11:01 AM
		To:	Bernstein, Greg; 'Zhi-Wei Lin'
		Cc:	'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	RE: [T1X1.5] RE: [IP-Optical] concatenation
extensions in sonet/s dh

		Why wouldn't the 2 boxes in option 2 use virtual
concatenation instead of
		arbitrary concatenation, though?

		Monica A. Lazer
		Advanced Transport Technology and Architecture Planning

		908 234 8462
		[email-masked]

		-----Original Message-----
		From: Bernstein, Greg [mailto:[email-masked]]
		Sent: Thursday, May 17, 2001 12:27 PM
		To: 'Zhi-Wei Lin'
		Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
		[email-masked]; [email-masked]; t1x1.5;
q11/15
		Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions
in sonet/sdh

		To avoid re-grooming either virtual concatenation or
arbitrary concatenation
		can help, but the implications are quite different.
		Say we have a particularly valuable (expensive) link that we
can't or don't
		want to re-groom then we have two options:
		(1)     Require that ALL end systems that could potentially
use this link
		convert over to virtual concatenation from standard
concatenation.
		(2)     Or, install boxes at both ends of the link that
support the
		arbitrary concatenation that we've been discussing.

		Which of these seems more realistic and practical?
		Greg B.
		        Dr. Greg M. Bernstein, Senior Scientist, Ciena
		        New phone: (510) 573-2237

		                -----Original Message-----
		                From:   Zhi-Wei Lin
[mailto:[email-masked]]
		                Sent:   Thursday, May 17, 2001 8:41 AM
		                To:     Bernstein, Greg
		                Cc:     'Maarten Vissers'; Anup Tirumala;
		[email-masked]; [email-masked];
[email-masked];
		t1x1.5; q11/15
		                Subject:        Re: [IP-Optical]
concatenation extensions in
		sonet/sdh

		                Hi,

		                some observations:

		                in terms of re-grooming and such, I believe
both virtual
		concatenation
		                and arbitrary concatenation can perform
this. One method is
		                standardized, the other is proprietary.

		                In terms of routing of the individual
connections that make
		up the
		                concatenated signal, virtual concatenation
is more flexible
		than
		                arbitrary concatenation, since you can put
each component VC
		in
		                different lines, and each component can be
routed
		differently.

		                In terms of interworking, yes the SIGNALLING
can defnititely
		be made to
		                interwork. However, the larger issue for
interworking is
		support by the
		                transport equipment themselves. Thus
interworking involves
		TWO parts:
		                signaling interworking and transport
interworking. Having
		one without
		                the other doesn't really help...

		                Thus, in terms of solving real problems,
either virtual or
		arbitrary can
		                accomplish that, but IMO, virtual seems more
flexible...and
		                standardized...

		                In terms of standards as fostering
interoperability and
		stifling of
		                innovation, in principle yes I agree. And
therefore if
		arbitrary
		                concatenation should be standardized, it
should be
		standardized in the
		                correct standards body. As Maarten
mentioned, the relevant
		standards
		                bodies discussed arbitrary concatenation
years ago, and
		decided
		                (hopefully based on their expert technical
opinion - I
		wasn't involved)
		                not to include arbitrary but instead to
include virtual.
		IMO, there must
		                be good reasons, and from what I can tell, I
see virtual as
		been more
		                flexible so that is a pretty good
reason...we at IETF, being
		protocol
		                experts (and budding transport experts?)
should not try to
		second-guess
		                the decisions without fully understanding
the
		ramifications...

		                As for stifling innovation, anytime you
standardize anything
		there is
		                always some factor of development that gets
fixed (is this
		something
		                that should not be said in a public forum???
-- sorry!!).
		Therefore
		                there is always a tradeoff between
innovation and
		standardization. I
		                think the job of standards bodies is to try
to balance these
		two factors
		                such that the industry in general can live
with the result
		without
		                unduly burdening...

		                agree?

		                Zhi

		                "Bernstein, Greg" wrote:
		                >
		                > A couple more points.
		                > (1)     GMPLS works well with arbitrary
concatenations
		need to specify the
		                > time slots since it provides a signaling
protocol that can
		do just that,
		                > i.e., GMPLS actually enables this feature
to interoperate.
		                > (2)     Arbitrary concatenation offers a
solution to a
		real problem, i.e.,
		                > eliminates the need for re-grooming on
lines that support
		it.  For those who
		                > have invested non-trivial amounts of money
in transoceanic
		links this can be
		                > a significant savings.
		                > (3)     The goal is interoperability and
to solve real
		problems.  We've got
		                > a real problem and with a minor edit to
the GMPLS SONET
		specification we can
		                > have an interoperable method for solving
it.
		                >
		                > To be precise in the definition of
arbitrary
		concatenation:
		                > As a concatenated signal within a single
SONET Line (SDH
		MS), with
		                > potentially arbitrary timeslots used for
its components.
		                >
		                > The current main application is: avoiding
the need for
		service impacting
		                > re-grooming. Note that this applies to
standard sized
		signals and is a per
		                > link property.
		                >
		                > Other applications do exist and are
somewhat competitive
		with non-LCAS
		                > virtual concatenation since the
implementation of
		arbitrary concatenation
		                > for odd sized signals is simpler than that
of virtual
		concatenation.  Once
		                > "odd" sized signals are used an entire
path through the
		network must exist
		                > that supports them.
		                >
		                > Folks I thought the role of standards
organizations was to
		foster
		                > interoperability that enables the industry
to move forward
		rather than as a
		                > means to stifle innovation. I think it is
better for the
		marketplace to
		                > decide which features are desirable.
		                >
		                > Greg B.
		                >
		                >         Dr. Greg M. Bernstein, Senior
Scientist, Ciena
		                >         New phone: (510) 573-2237
		                >

Delivery-date: Thu, 17 May 2001 11:40:06 -0700
Date: Thu, 17 May 2001 12:38:30 -0600
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
CC: "'Zhi-Wei Lin'" <[email-masked]>, "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

There is no intent in any of the standardization bodies to stifle
innovation. Standards are contribution driven, and what you find
in the documents as written are the product of those contributions.

If the desire is to extend current SONET/SDH with an arbitrary
concatenation feature, there is no problem to contribute to T1X1
and/or ITU-T to propose this extension. This is the correct way to
approach it. The INCORRECT way is to confuse the market by producing
an IETF version of SONET/SDH specs that is different from T1X1/ITU-T.

Let me add some background on how we ended up with the current
situation recommending virtual concatenation in SONET/SDH:

1. Contiguous or Arbitrary concatenation requires implementation
of the concatenation method at every NE along the chosen path
through the network to provide a service. At the time we began
these discussions, we had the problem that ATM wanted to use
VC-4-4c (STS-12c), but there were still a lot of OC-3/STM-1
links in the network and NEs that didn't support trails
bigger than VC-4 (STS-3c). By now, of course, VC-4-4c (STS-12c)
and even VC-4-16c (STS-48c) are becoming pretty ubiquitous,
but as has been observed in previous emails, it will be a
long time before you replace all of the 2.5G links in the
network, so contiguous/arbitrary concatenation to greater
than VC-4-16c/STS-48c is still a problem for some time to
come. The endpoints in a network always seem to evolve ahead
of and faster than links and equipment in the core network
can be replaced, so it was important to define a concatenation
method that could be implemented only by the endpoints.

2. Contiguous/arbitrary concatenation is not as elgant for
lower order paths as for higher order paths. We saw in
a few equipments the VC-2-5c mapping to put 4 x 34 Mbps
into an STM-1, but most equipment does not provide the
ability to concatenate lower order paths. For certain
payloads, lower order paths fit better, e.g., 5 x VC-12
to carry 10Mb Ethernet.

3. Different payloads to not fit ideally into "standard"
multiples found in contiguous concatenation (4, 16, 64,
256 VC-4 or 3, 12, 48, 192, 768 STS-1). 10 Mb Ethernet
fits into 5 x VC-12. 1Gb Ethernet fits into 7 x VC-4, etc.

4. As paths are set up or taken down in a network, there is
a tendency for capacity to become fragmented. Contiguous/
arbitrary concatenation cannot always take advantage of
free timeslots along a span if they are not adjacent on
the same fiber or if they are on different fibers.

5. LCAS was easier to envision in a virtual concatenation
environment. Many of the new services are not inherently
constant bit rate, and it can be useful to dynamically
add or remove components of the bundle to adjust link
capacity. It is also useful to be able to handle failures
of individual components of the concatenated trail by
just reducing the capacity rather than by having to
protection switch the entire path.

Virtual concatenation was designed to solve all of the above
problems. Arbitrary concatenation is another way to solve
problem (3) above, but it doesn't solve the others. Given
that virtual concatenation is standardized to solve all
of the problems, it reduces the pressure to implement
arbitrary concatenation throughout the network to solve
only problem (3).

If problem (3) is the only one you are trying to solve,
arbitrary concatenation has the advantage of not requiring
so much buffer space at the endpoints to accomodate
differential delay. But with trends in memory costs, this
is not so much of an issue, and this needs to be traded
off against the need to provide support for the contiguous/
arbitrary rate and all associated protection mechanisms at
EVERY NE along the chosen path in the network in order for
this to work.

If there is a significant market for applications where
solving (3) is vital but (1,2,4,5) are not so important,
then it may be worth pushing arbitrary concatenation as
a way to optimize how those services are provided over
what you get with virtual concatenation.

Regards,
Steve Trowbridge

"Bernstein, Greg" wrote:
> 
> To avoid re-grooming either virtual concatenation or arbitrary concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we can't or don't
> want to re-groom then we have two options:
> (1)     Require that ALL end systems that could potentially use this link
> convert over to virtual concatenation from standard concatenation.
> (2)     Or, install boxes at both ends of the link that support the
> arbitrary concatenation that we've been discussing.
> 
> Which of these seems more realistic and practical?
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Zhi-Wei Lin [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 To:     Bernstein, Greg
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        Re: [IP-Optical] concatenation extensions in
> sonet/sdh
> 
>                 Hi,
> 
>                 some observations:
> 
>                 in terms of re-grooming and such, I believe both virtual
> concatenation
>                 and arbitrary concatenation can perform this. One method is
>                 standardized, the other is proprietary.
> 
>                 In terms of routing of the individual connections that make
> up the
>                 concatenated signal, virtual concatenation is more flexible
> than
>                 arbitrary concatenation, since you can put each component VC
> in
>                 different lines, and each component can be routed
> differently.
> 
>                 In terms of interworking, yes the SIGNALLING can defnititely
> be made to
>                 interwork. However, the larger issue for interworking is
> support by the
>                 transport equipment themselves. Thus interworking involves
> TWO parts:
>                 signaling interworking and transport interworking. Having
> one without
>                 the other doesn't really help...
> 
>                 Thus, in terms of solving real problems, either virtual or
> arbitrary can
>                 accomplish that, but IMO, virtual seems more flexible...and
>                 standardized...
> 
>                 In terms of standards as fostering interoperability and
> stifling of
>                 innovation, in principle yes I agree. And therefore if
> arbitrary
>                 concatenation should be standardized, it should be
> standardized in the
>                 correct standards body. As Maarten mentioned, the relevant
> standards
>                 bodies discussed arbitrary concatenation years ago, and
> decided
>                 (hopefully based on their expert technical opinion - I
> wasn't involved)
>                 not to include arbitrary but instead to include virtual.
> IMO, there must
>                 be good reasons, and from what I can tell, I see virtual as
> been more
>                 flexible so that is a pretty good reason...we at IETF, being
> protocol
>                 experts (and budding transport experts?) should not try to
> second-guess
>                 the decisions without fully understanding the
> ramifications...
> 
>                 As for stifling innovation, anytime you standardize anything
> there is
>                 always some factor of development that gets fixed (is this
> something
>                 that should not be said in a public forum??? -- sorry!!).
> Therefore
>                 there is always a tradeoff between innovation and
> standardization. I
>                 think the job of standards bodies is to try to balance these
> two factors
>                 such that the industry in general can live with the result
> without
>                 unduly burdening...
> 
>                 agree?
> 
>                 Zhi
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > A couple more points.
>                 > (1)     GMPLS works well with arbitrary concatenations
> need to specify the
>                 > time slots since it provides a signaling protocol that can
> do just that,
>                 > i.e., GMPLS actually enables this feature to interoperate.
>                 > (2)     Arbitrary concatenation offers a solution to a
> real problem, i.e.,
>                 > eliminates the need for re-grooming on lines that support
> it.  For those who
>                 > have invested non-trivial amounts of money in transoceanic
> links this can be
>                 > a significant savings.
>                 > (3)     The goal is interoperability and to solve real
> problems.  We've got
>                 > a real problem and with a minor edit to the GMPLS SONET
> specification we can
>                 > have an interoperable method for solving it.
>                 >
>                 > To be precise in the definition of arbitrary
> concatenation:
>                 > As a concatenated signal within a single SONET Line (SDH
> MS), with
>                 > potentially arbitrary timeslots used for its components.
>                 >
>                 > The current main application is: avoiding the need for
> service impacting
>                 > re-grooming. Note that this applies to standard sized
> signals and is a per
>                 > link property.
>                 >
>                 > Other applications do exist and are somewhat competitive
> with non-LCAS
>                 > virtual concatenation since the implementation of
> arbitrary concatenation
>                 > for odd sized signals is simpler than that of virtual
> concatenation.  Once
>                 > "odd" sized signals are used an entire path through the
> network must exist
>                 > that supports them.
>                 >
>                 > Folks I thought the role of standards organizations was to
> foster
>                 > interoperability that enables the industry to move forward
> rather than as a
>                 > means to stifle innovation. I think it is better for the
> marketplace to
>                 > decide which features are desirable.
>                 >
>                 > Greg B.
>                 >
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >

Delivery-date: Thu, 17 May 2001 11:05:38 -0700
From: "Lazer, Monica A, NNAD" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, "'Zhi-Wei Lin'" <[email-masked]>
Cc: "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/s dh
Date: Thu, 17 May 2001 14:01:28 -0400

Why wouldn't the 2 boxes in option 2 use virtual concatenation instead of
arbitrary concatenation, though?

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
[email-masked]

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 12:27 PM
To: 'Zhi-Wei Lin'
Cc: 'Maarten Vissers'; Anup Tirumala; [email-masked];
[email-masked]; [email-masked]; t1x1.5; q11/15
Subject: [T1X1.5] RE: [IP-Optical] concatenation extensions in sonet/sdh

To avoid re-grooming either virtual concatenation or arbitrary concatenation
can help, but the implications are quite different.
Say we have a particularly valuable (expensive) link that we can't or don't
want to re-groom then we have two options:
(1)     Require that ALL end systems that could potentially use this link
convert over to virtual concatenation from standard concatenation.
(2)     Or, install boxes at both ends of the link that support the
arbitrary concatenation that we've been discussing.

Which of these seems more realistic and practical?
Greg B.
        Dr. Greg M. Bernstein, Senior Scientist, Ciena
        New phone: (510) 573-2237

                -----Original Message-----
                From:   Zhi-Wei Lin [mailto:[email-masked]]
                Sent:   Thursday, May 17, 2001 8:41 AM
                To:     Bernstein, Greg
                Cc:     'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
                Subject:        Re: [IP-Optical] concatenation extensions in
sonet/sdh

                Hi,

                some observations:

                in terms of re-grooming and such, I believe both virtual
concatenation
                and arbitrary concatenation can perform this. One method is
                standardized, the other is proprietary.

                In terms of routing of the individual connections that make
up the
                concatenated signal, virtual concatenation is more flexible
than
                arbitrary concatenation, since you can put each component VC
in
                different lines, and each component can be routed
differently.

                In terms of interworking, yes the SIGNALLING can defnititely
be made to
                interwork. However, the larger issue for interworking is
support by the
                transport equipment themselves. Thus interworking involves
TWO parts:
                signaling interworking and transport interworking. Having
one without
                the other doesn't really help...

                Thus, in terms of solving real problems, either virtual or
arbitrary can
                accomplish that, but IMO, virtual seems more flexible...and
                standardized...

                In terms of standards as fostering interoperability and
stifling of
                innovation, in principle yes I agree. And therefore if
arbitrary
                concatenation should be standardized, it should be
standardized in the
                correct standards body. As Maarten mentioned, the relevant
standards
                bodies discussed arbitrary concatenation years ago, and
decided
                (hopefully based on their expert technical opinion - I
wasn't involved)
                not to include arbitrary but instead to include virtual.
IMO, there must
                be good reasons, and from what I can tell, I see virtual as
been more
                flexible so that is a pretty good reason...we at IETF, being
protocol
                experts (and budding transport experts?) should not try to
second-guess
                the decisions without fully understanding the
ramifications...

                As for stifling innovation, anytime you standardize anything
there is
                always some factor of development that gets fixed (is this
something
                that should not be said in a public forum??? -- sorry!!).
Therefore
                there is always a tradeoff between innovation and
standardization. I
                think the job of standards bodies is to try to balance these
two factors
                such that the industry in general can live with the result
without
                unduly burdening...

                agree?

                Zhi

                "Bernstein, Greg" wrote:
                >
                > A couple more points.
                > (1)     GMPLS works well with arbitrary concatenations
need to specify the
                > time slots since it provides a signaling protocol that can
do just that,
                > i.e., GMPLS actually enables this feature to interoperate.
                > (2)     Arbitrary concatenation offers a solution to a
real problem, i.e.,
                > eliminates the need for re-grooming on lines that support
it.  For those who
                > have invested non-trivial amounts of money in transoceanic
links this can be
                > a significant savings.
                > (3)     The goal is interoperability and to solve real
problems.  We've got
                > a real problem and with a minor edit to the GMPLS SONET
specification we can
                > have an interoperable method for solving it.
                >
                > To be precise in the definition of arbitrary
concatenation:
                > As a concatenated signal within a single SONET Line (SDH
MS), with
                > potentially arbitrary timeslots used for its components.
                >
                > The current main application is: avoiding the need for
service impacting
                > re-grooming. Note that this applies to standard sized
signals and is a per
                > link property.
                >
                > Other applications do exist and are somewhat competitive
with non-LCAS
                > virtual concatenation since the implementation of
arbitrary concatenation
                > for odd sized signals is simpler than that of virtual
concatenation.  Once
                > "odd" sized signals are used an entire path through the
network must exist
                > that supports them.
                >
                > Folks I thought the role of standards organizations was to
foster
                > interoperability that enables the industry to move forward
rather than as a
                > means to stifle innovation. I think it is better for the
marketplace to
                > decide which features are desirable.
                >
                > Greg B.
                >
                >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
                >         New phone: (510) 573-2237
                >

Delivery-date: Thu, 17 May 2001 09:50:12 -0700
Date: Thu, 17 May 2001 12:48:28 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi Greg,

Let me change a few words in your example:

> (1)     Require that ALL end systems that could potentially use this link
> convert over to arbitrary concatenation from standard concatenation.
                  ^^^^^^^^^
> (2)     Or, install boxes at both ends of the link that support the
> virtual concatenation that we've been discussing.
  ^^^^^^^

I think the two example are different. #1 talks about potentially use
the link. That's also true of arbitrary or virtual.

#2 talks about only a pair of endpoints that support this. That's also
true of either virtual or arbitrary.

Another observation:

Arbitrary or virtual concatenation only impacts the endpoints, and for
any application either concatenation method would impact the same
endpoints, and therefore would require the same amount of change of the
endpoints. 

Example:

 +-----+   +----+    +----+    +----+    +--------+
 | A   |---| B  |----| C  |----| D  |----|    Z   |
 +-----+   +----+    +----+    +----+    +--------+
     \                                    /
      \                                  /
       \   +----+    +----+    +----+   /
        \--| E  |----| F  |----| G  |--/
           +----+    +----+    +----+ 

Assumes a VC-4-3c (or VC-4-3v) is requested.

With arbitrary concatenation, each component can be placed in any
timeslot, but they all traverse A-B-C-D-Z or A-E-F-G-Z. A and Z needs
special functions. But since you mentioned that arbitrary concat assumes
that the timeslots are sequential ordered (i.e., info in timeslot 1-6-8
cannot be rearranged 1-8-6), the intermediate nodes need certain
constraints on re-ordering (constraining the TSI capability).

With virtual concat, each component can be placed in any timeslot, and
each component can travel different routes, so timeslot 1 & 8 can
traverse A-B-C-D-Z while timeslot 6 can traverse A-E-F-G-Z. A and Z
needs special functions. However, as each timeslot is treated as a
separate connection, the intermediate nodes do not need any info or
constrained. The A node, when deciding the route (source routing) will
take the differential delays into account. And according to Maarten's
previous email, current state-of-the-art can handle differential delays
where the differential path distance between two component can be up to
3000 km (was this the right figure???) -- 3000 km is quite a bit
DIFFERENTIAL distance. 

Hope this helps with the discussion...

Zhi

"Bernstein, Greg" wrote:
> 
> To avoid re-grooming either virtual concatenation or arbitrary concatenation
> can help, but the implications are quite different.
> Say we have a particularly valuable (expensive) link that we can't or don't
> want to re-groom then we have two options:
> (1)     Require that ALL end systems that could potentially use this link
> convert over to virtual concatenation from standard concatenation.
> (2)     Or, install boxes at both ends of the link that support the
> arbitrary concatenation that we've been discussing.
> 
> Which of these seems more realistic and practical?
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Zhi-Wei Lin [mailto:[email-masked]]
>                 Sent:   Thursday, May 17, 2001 8:41 AM
>                 To:     Bernstein, Greg
>                 Cc:     'Maarten Vissers'; Anup Tirumala;
> [email-masked]; [email-masked]; [email-masked];
> t1x1.5; q11/15
>                 Subject:        Re: [IP-Optical] concatenation extensions in
> sonet/sdh
> 
>                 Hi,
> 
>                 some observations:
> 
>                 in terms of re-grooming and such, I believe both virtual
> concatenation
>                 and arbitrary concatenation can perform this. One method is
>                 standardized, the other is proprietary.
> 
>                 In terms of routing of the individual connections that make
> up the
>                 concatenated signal, virtual concatenation is more flexible
> than
>                 arbitrary concatenation, since you can put each component VC
> in
>                 different lines, and each component can be routed
> differently.
> 
>                 In terms of interworking, yes the SIGNALLING can defnititely
> be made to
>                 interwork. However, the larger issue for interworking is
> support by the
>                 transport equipment themselves. Thus interworking involves
> TWO parts:
>                 signaling interworking and transport interworking. Having
> one without
>                 the other doesn't really help...
> 
>                 Thus, in terms of solving real problems, either virtual or
> arbitrary can
>                 accomplish that, but IMO, virtual seems more flexible...and
>                 standardized...
> 
>                 In terms of standards as fostering interoperability and
> stifling of
>                 innovation, in principle yes I agree. And therefore if
> arbitrary
>                 concatenation should be standardized, it should be
> standardized in the
>                 correct standards body. As Maarten mentioned, the relevant
> standards
>                 bodies discussed arbitrary concatenation years ago, and
> decided
>                 (hopefully based on their expert technical opinion - I
> wasn't involved)
>                 not to include arbitrary but instead to include virtual.
> IMO, there must
>                 be good reasons, and from what I can tell, I see virtual as
> been more
>                 flexible so that is a pretty good reason...we at IETF, being
> protocol
>                 experts (and budding transport experts?) should not try to
> second-guess
>                 the decisions without fully understanding the
> ramifications...
> 
>                 As for stifling innovation, anytime you standardize anything
> there is
>                 always some factor of development that gets fixed (is this
> something
>                 that should not be said in a public forum??? -- sorry!!).
> Therefore
>                 there is always a tradeoff between innovation and
> standardization. I
>                 think the job of standards bodies is to try to balance these
> two factors
>                 such that the industry in general can live with the result
> without
>                 unduly burdening...
> 
>                 agree?
> 
>                 Zhi
> 
>                 "Bernstein, Greg" wrote:
>                 >
>                 > A couple more points.
>                 > (1)     GMPLS works well with arbitrary concatenations
> need to specify the
>                 > time slots since it provides a signaling protocol that can
> do just that,
>                 > i.e., GMPLS actually enables this feature to interoperate.
>                 > (2)     Arbitrary concatenation offers a solution to a
> real problem, i.e.,
>                 > eliminates the need for re-grooming on lines that support
> it.  For those who
>                 > have invested non-trivial amounts of money in transoceanic
> links this can be
>                 > a significant savings.
>                 > (3)     The goal is interoperability and to solve real
> problems.  We've got
>                 > a real problem and with a minor edit to the GMPLS SONET
> specification we can
>                 > have an interoperable method for solving it.
>                 >
>                 > To be precise in the definition of arbitrary
> concatenation:
>                 > As a concatenated signal within a single SONET Line (SDH
> MS), with
>                 > potentially arbitrary timeslots used for its components.
>                 >
>                 > The current main application is: avoiding the need for
> service impacting
>                 > re-grooming. Note that this applies to standard sized
> signals and is a per
>                 > link property.
>                 >
>                 > Other applications do exist and are somewhat competitive
> with non-LCAS
>                 > virtual concatenation since the implementation of
> arbitrary concatenation
>                 > for odd sized signals is simpler than that of virtual
> concatenation.  Once
>                 > "odd" sized signals are used an entire path through the
> network must exist
>                 > that supports them.
>                 >
>                 > Folks I thought the role of standards organizations was to
> foster
>                 > interoperability that enables the industry to move forward
> rather than as a
>                 > means to stifle innovation. I think it is better for the
> marketplace to
>                 > decide which features are desirable.
>                 >
>                 > Greg B.
>                 >
>                 >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                 >         New phone: (510) 573-2237
>                 >

Delivery-date: Thu, 17 May 2001 09:28:20 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Zhi-Wei Lin' <[email-masked]>
Cc: 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked],  [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 09:26:30 -0700

To avoid re-grooming either virtual concatenation or arbitrary concatenation
can help, but the implications are quite different.
Say we have a particularly valuable (expensive) link that we can't or don't
want to re-groom then we have two options:
(1)	Require that ALL end systems that could potentially use this link
convert over to virtual concatenation from standard concatenation.
(2)	Or, install boxes at both ends of the link that support the
arbitrary concatenation that we've been discussing.

Which of these seems more realistic and practical?
Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Zhi-Wei Lin [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 8:41 AM
		To:	Bernstein, Greg
		Cc:	'Maarten Vissers'; Anup Tirumala;
[email-masked]; [email-masked]; [email-masked];
t1x1.5; q11/15
		Subject:	Re: [IP-Optical] concatenation extensions in
sonet/sdh

		Hi,

		some observations:

		in terms of re-grooming and such, I believe both virtual
concatenation
		and arbitrary concatenation can perform this. One method is
		standardized, the other is proprietary.

		In terms of routing of the individual connections that make
up the
		concatenated signal, virtual concatenation is more flexible
than
		arbitrary concatenation, since you can put each component VC
in
		different lines, and each component can be routed
differently.

		In terms of interworking, yes the SIGNALLING can defnititely
be made to
		interwork. However, the larger issue for interworking is
support by the
		transport equipment themselves. Thus interworking involves
TWO parts:
		signaling interworking and transport interworking. Having
one without
		the other doesn't really help...

		Thus, in terms of solving real problems, either virtual or
arbitrary can
		accomplish that, but IMO, virtual seems more flexible...and
		standardized...

		In terms of standards as fostering interoperability and
stifling of
		innovation, in principle yes I agree. And therefore if
arbitrary
		concatenation should be standardized, it should be
standardized in the
		correct standards body. As Maarten mentioned, the relevant
standards
		bodies discussed arbitrary concatenation years ago, and
decided
		(hopefully based on their expert technical opinion - I
wasn't involved)
		not to include arbitrary but instead to include virtual.
IMO, there must
		be good reasons, and from what I can tell, I see virtual as
been more
		flexible so that is a pretty good reason...we at IETF, being
protocol
		experts (and budding transport experts?) should not try to
second-guess
		the decisions without fully understanding the
ramifications...

		As for stifling innovation, anytime you standardize anything
there is
		always some factor of development that gets fixed (is this
something
		that should not be said in a public forum??? -- sorry!!).
Therefore
		there is always a tradeoff between innovation and
standardization. I
		think the job of standards bodies is to try to balance these
two factors
		such that the industry in general can live with the result
without
		unduly burdening...

		agree?

		Zhi

		"Bernstein, Greg" wrote:
		> 
		> A couple more points.
		> (1)     GMPLS works well with arbitrary concatenations
need to specify the
		> time slots since it provides a signaling protocol that can
do just that,
		> i.e., GMPLS actually enables this feature to interoperate.
		> (2)     Arbitrary concatenation offers a solution to a
real problem, i.e.,
		> eliminates the need for re-grooming on lines that support
it.  For those who
		> have invested non-trivial amounts of money in transoceanic
links this can be
		> a significant savings.
		> (3)     The goal is interoperability and to solve real
problems.  We've got
		> a real problem and with a minor edit to the GMPLS SONET
specification we can
		> have an interoperable method for solving it.
		> 
		> To be precise in the definition of arbitrary
concatenation:
		> As a concatenated signal within a single SONET Line (SDH
MS), with
		> potentially arbitrary timeslots used for its components.
		> 
		> The current main application is: avoiding the need for
service impacting
		> re-grooming. Note that this applies to standard sized
signals and is a per
		> link property.
		> 
		> Other applications do exist and are somewhat competitive
with non-LCAS
		> virtual concatenation since the implementation of
arbitrary concatenation
		> for odd sized signals is simpler than that of virtual
concatenation.  Once
		> "odd" sized signals are used an entire path through the
network must exist
		> that supports them.
		> 
		> Folks I thought the role of standards organizations was to
foster
		> interoperability that enables the industry to move forward
rather than as a
		> means to stifle innovation. I think it is better for the
marketplace to
		> decide which features are desirable.
		> 
		> Greg B.
		> 
		>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
		>         New phone: (510) 573-2237
		>

Delivery-date: Thu, 17 May 2001 08:48:46 -0700
Date: Thu, 17 May 2001 11:41:21 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: "Bernstein, Greg" <[email-masked]>
CC: "'Maarten Vissers'" <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked], [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: Re: [IP-Optical] concatenation extensions in sonet/sdh

Hi,

some observations:

in terms of re-grooming and such, I believe both virtual concatenation
and arbitrary concatenation can perform this. One method is
standardized, the other is proprietary.

In terms of routing of the individual connections that make up the
concatenated signal, virtual concatenation is more flexible than
arbitrary concatenation, since you can put each component VC in
different lines, and each component can be routed differently.

In terms of interworking, yes the SIGNALLING can defnititely be made to
interwork. However, the larger issue for interworking is support by the
transport equipment themselves. Thus interworking involves TWO parts:
signaling interworking and transport interworking. Having one without
the other doesn't really help...

Thus, in terms of solving real problems, either virtual or arbitrary can
accomplish that, but IMO, virtual seems more flexible...and
standardized...

In terms of standards as fostering interoperability and stifling of
innovation, in principle yes I agree. And therefore if arbitrary
concatenation should be standardized, it should be standardized in the
correct standards body. As Maarten mentioned, the relevant standards
bodies discussed arbitrary concatenation years ago, and decided
(hopefully based on their expert technical opinion - I wasn't involved)
not to include arbitrary but instead to include virtual. IMO, there must
be good reasons, and from what I can tell, I see virtual as been more
flexible so that is a pretty good reason...we at IETF, being protocol
experts (and budding transport experts?) should not try to second-guess
the decisions without fully understanding the ramifications...

As for stifling innovation, anytime you standardize anything there is
always some factor of development that gets fixed (is this something
that should not be said in a public forum??? -- sorry!!). Therefore
there is always a tradeoff between innovation and standardization. I
think the job of standards bodies is to try to balance these two factors
such that the industry in general can live with the result without
unduly burdening...

agree?

Zhi

"Bernstein, Greg" wrote:
> 
> A couple more points.
> (1)     GMPLS works well with arbitrary concatenations need to specify the
> time slots since it provides a signaling protocol that can do just that,
> i.e., GMPLS actually enables this feature to interoperate.
> (2)     Arbitrary concatenation offers a solution to a real problem, i.e.,
> eliminates the need for re-grooming on lines that support it.  For those who
> have invested non-trivial amounts of money in transoceanic links this can be
> a significant savings.
> (3)     The goal is interoperability and to solve real problems.  We've got
> a real problem and with a minor edit to the GMPLS SONET specification we can
> have an interoperable method for solving it.
> 
> To be precise in the definition of arbitrary concatenation:
> As a concatenated signal within a single SONET Line (SDH MS), with
> potentially arbitrary timeslots used for its components.
> 
> The current main application is: avoiding the need for service impacting
> re-grooming. Note that this applies to standard sized signals and is a per
> link property.
> 
> Other applications do exist and are somewhat competitive with non-LCAS
> virtual concatenation since the implementation of arbitrary concatenation
> for odd sized signals is simpler than that of virtual concatenation.  Once
> "odd" sized signals are used an entire path through the network must exist
> that supports them.
> 
> Folks I thought the role of standards organizations was to foster
> interoperability that enables the industry to move forward rather than as a
> means to stifle innovation. I think it is better for the marketplace to
> decide which features are desirable.
> 
> Greg B.
> 
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
>

Delivery-date: Thu, 17 May 2001 08:23:03 -0700
From: "Bernstein, Greg" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Anup Tirumala <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked], "t1x1.5" <[email-masked]>, q11/15 <[email-masked]>
Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
Date: Thu, 17 May 2001 08:20:44 -0700

A couple more points.
(1)	GMPLS works well with arbitrary concatenations need to specify the
time slots since it provides a signaling protocol that can do just that,
i.e., GMPLS actually enables this feature to interoperate.
(2)	Arbitrary concatenation offers a solution to a real problem, i.e.,
eliminates the need for re-grooming on lines that support it.  For those who
have invested non-trivial amounts of money in transoceanic links this can be
a significant savings.
(3)	The goal is interoperability and to solve real problems.  We've got
a real problem and with a minor edit to the GMPLS SONET specification we can
have an interoperable method for solving it.

To be precise in the definition of arbitrary concatenation:
As a concatenated signal within a single SONET Line (SDH MS), with
potentially arbitrary timeslots used for its components.

The current main application is: avoiding the need for service impacting
re-grooming. Note that this applies to standard sized signals and is a per
link property.

Other applications do exist and are somewhat competitive with non-LCAS
virtual concatenation since the implementation of arbitrary concatenation
for odd sized signals is simpler than that of virtual concatenation.  Once
"odd" sized signals are used an entire path through the network must exist
that supports them.

Folks I thought the role of standards organizations was to foster
interoperability that enables the industry to move forward rather than as a
means to stifle innovation. I think it is better for the marketplace to
decide which features are desirable.

Greg B.
 
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Maarten Vissers [mailto:[email-masked]]
		Sent:	Thursday, May 17, 2001 1:36 AM
		To:	Anup Tirumala
		Cc:	[email-masked]; Bernstein, Greg;
[email-masked]; t1x1.5; q11/15
		Subject:	Re: [IP-Optical] concatenation extensions in
sonet/sdh

		 << File: Card for Maarten Vissers >> Greg, Anup, Sanjay,

		To my recollection, the SONET/SDH definition is performed in
T1X1.5 and
		ITU-T SG15. Last year new revisions of T1.105 and G.707 were
approved,
		in which the "arbitrary contiguous concatenation" has been
removed. Such
		step isn't made just for fun. 

		If you believe the removal of "arbitrary contiguous
concatenation" from
		these standards was a mistake, please submit a contribution
to T1X1.5
		and ITU-T Q.11/15 with a proposal to re-introduce it. At the
same time
		you can then also request to introduce "arbitrary
concatenation" and
		propose mappings of client signals into these arbitrary
(contiguous)
		concatenated signals. However, as indicated by Mark, Juergen
and myself,
		I doubt if you find support for such extension of SONET and
SDH.

		For the moment, SONET/SDH networks compliant with T1.105 and
G.707
		standards can forward "contiguous concatenated" VC-4-Xc
(X=4,16,64) and
		STS-3c/12c/48c/192c signals and "virtual concatenated"
VC-n-Xv (n=3,4),
		STS-1, STS-3c-Xc (X=1..256) and VC-n (n=11,12), VT-1.5-Xv
(X=1..64)
		signals, not the "arbitrary concatenated" signals. 
		Arbitrary concatenation is a proprietary extension of
SONET/SDH, for
		which there is no interworking with standard SONET/SDH
networks. 

		Virtual concatenation is THE international standardised
direction, for
		which a vendor and operator may expect to see seemless
interworking in
		the SONET/SDH network.

		Virtual concatenation got very popular due to the: 
		- pricing of Ethernet ports on routers (compared to pricing
of
		STM-N/OC-N ports on routers),
		- absence of channelized STM-N/OC-N interface ports on
routers.

		As a result the transport network was forced to accept
Ethernet physical
		interfaces, in additon to the traditional SONET/SDH and PDH
interfaces.
		Transport networking engineers very well understand the
desire of a
		customer to pay only for the bandwidth needed, and
consequential within
		the constraints of the SONET/SDH transport network a
solution was
		developed to meet the needs of the customer and the needs of
the
		operator. This is virtual concatenation with GFP as
encapsulation
		method.

		Virtual concatenation allows to separate the physical and
logical
		aspects of Ethernet signals, like such is common practice
for any other
		SDH/SONET signal. I.e. the (10M, 100M, 1G) Ethernet PHY
signal is
		terminated, the ethernet idle packets are dropped and the
packets with
		information inside of it are forwarded in a transport pipe
sized to the
		customers need. 
		The additional complexity is the introduction of a (skinny)
ehternet
		layer on top of the SDH/SONET layers, as at a minimum some
monitoring is
		to be performed at the ethernet level. 

		Of course, it would be more economical if the transport
network didn't
		have to do this job. I.e. routers should use STM-N/OC-N
interface ports
		supporting virtual concatenated VC-n/STS/VT signals. The
transport
		network would n't have to deal then with its client signals,
and instead
		of ethernet in the virtual concatenated signals, any other
data protocol
		could be used by the routers (e.g. IP/PPP/GFP).

		But, while having to do this ethernet processing, extensions
are
		becoming economical in the access transport networks; i.e.
having
		ethernet bridging/switching present, it can be used to groom
ethernet
		traffic to further optimise and thus cost reduce ethernet
packet
		transport. It is now possible to offer sub-VC-n/STS/VT
ethernet
		transport pipes (in addition to the multi-VC-n/STS/VT )
through the
		SDH/SONET access networks.

		Regards,

		Maarten

		Anup Tirumala wrote:
		> 
		> If routers can routinely fill TDM pipes fully, why are we
even talking
		> virtual concatenation?
		> 
		> Arbitrary (or even Virtual) concatenation has the
		> best bang for buck with packets sharing bandwidth
		> with TDM. (i.e. in a converged network).
		> 
		> Indeed, a business case does exist for arbitrary
concatenation.
		> Ask Cyras (now Ciena;)
		> 
		> You must look at this in conjunction with Network
Processors
		> and statistical multiplexing.
		> 
		> A customer need only pay for as much bandwidth as he/she
needs,
		> while the remainder can be used for TDM channels.
		> 
		> We believe the case for arbitrary concatenation does
exist:
		> 
		> 1. scales better with technology.
		> 2. no massive buffering requirements. (note that virtual
concatenation
		>    does not "guarantee" hit-less operation. with
buffering, one can limit
		>    the hit that's all).
		> 3. augments native contiguous concatenation. i.e.
contiguous concatenation
		>    becomes a degenerate case of arbitrary concatenation.
		> 4. A customer explicity asked for it. :)
		> 
		> I think there is merit to an effort at interoperability.
		> 
		> -anup
		> 
		> > -----Original Message-----
		> > From: [email-masked]
[mailto:[email-masked]]
		> > Sent: Tuesday, May 15, 2001 12:36 PM
		> > To: [email-masked]
		> > Cc: [email-masked]; [email-masked];
		> > [email-masked]
		> > Subject: RE: [IP-Optical] concatenation extensions in
sonet/sdh
		> >
		> >
		> > From my perspective, all necessary applications can be
met by
		> > contiguous
		> > and virtual concatenation.  Adding arbitrary
concatenation simply
		> > increases the number of spares to maintain, the number
of
		> > attributes to
		> > test for interoperability, and the potential complexity
to
		> > port cards.
		> > The improved bandwidth efficiency you are going to claim
		> > won't outweigh
		> > the problems I see as a result.  Unless you can show a
significant
		> > business driver for this, I would recommend not wasting
your
		> > time trying
		> > to standardize it.  The trend is to maintain variable
size
		> > connections
		> > using packets anyway.  Why are we talking about doing
this
		> > with TDM?  I
		> > find it most interesting that this IETF group is
discussing variable
		> > size TDM pipes, when routers typically can fill a TDM
pipe at
		> > the line
		> > rate.
		> >
		> > Mark Loyd Jones
		> > Sprint
		> > Technology Planning & Integration
		> > 913-534-5247
		> > [email-masked]
		> >
		> >
		> > > -----Original Message-----
		> > > From: chickoo66 [mailto:[email-masked]]
		> > > Sent: Tuesday, May 15, 2001 1:47 PM
		> > > To: GregB; mvissers; ip-optical
		> > > Cc: chickoo66
		> > > Subject: RE: [IP-Optical] concatenation extensions in
sonet/sdh
		> > >
		> > >
		> > > I could not agree more.
		> > > Arb-Concatenation, being a logical (and graceful)
		> > > extension of standard contiguous concatenation,
		> > > can easily co-exist with virtual.
		> > > Imagine channels such as 2c,5c,6c,7c... 767c :)
		> > > However, we need to be able to interoperate
		> > > with outside-vendor equipments, with regards
		> > > to the multiplexing scheme.
		> > > Dr.Berstein/other, do you know of any such
		> > > interoperating effort on-going?
		> > > Would any one be interested in interoperability
		> > > issues pertaining to arb-concat?
		> > > I emphasize: arb-conc is complementary to virt-concat.
		> > > Comments?
		> > > Sanjay
		> > >
		> > >
		> > >
		> > > --- "Bernstein, Greg" <[email-masked]> wrote:
		> > > > Folks, please note that Arbitrary concatenation is
		> > > > not in any of the ITU or
		> > > > ANSI standards as Maarten points out below.
		> > > > Maarten my understanding is that GFP can be used
		> > > > with either standard
		> > > > contiguous concatenation or virtual concatenation.
		> > > >
		> > > > For those interested in arbitrary concatenation for
		> > > > the standard sizes,
		> > > > e.g., STS-3c, STS-12c, one can just use the payload
		> > > > mappings from standard
		> > > > contiguous concatenation.  A network supporting
		> > > > arbitrary concatenation can
		> > > > transport these efficiently with no re-grooming.
		> > > >
		> > > > Note that I think SDH/SONET networks can make use of
		> > > > both virtual and
		> > > > arbitrary concatenation.
		> > > > Greg B.
		> > > >
		> > > >   Dr. Greg M. Bernstein, Senior Scientist, Ciena
		> > > >   New phone: (510) 573-2237
		> > > >
		> > > >
		> > > >           -----Original Message-----
		> > > >           From:   Maarten Vissers
[mailto:[email-masked]]
		> > > >           Sent:   Tuesday, May 15, 2001 1:06 AM
		> > > >           To:     Bernstein, Greg; 'ashritha
thirumalai';
		> > > > [email-masked]
		> > > >           Subject:        Re: [IP-Optical]
concatenation
		> > > extensions
		> > > > in
		> > > > sonet/sdh
		> > > >
		> > > >            << File: Card for Maarten Vissers >>
Greg,
		> > > >
		> > > >           The transport of ethernet signals via
SDH/SONET
		> > > > networks is
		> > > > being
		> > > >           defined in T1 and ITU-T to use virtual
		> > > > concatenation and GFP
		> > > > for
		> > > >           encapsulation, not arbitrary
concatenation.
		> > > >
		> > > >           The transport of SAN signals (ESCON, FC,
FICON)
		> > > > via
		> > > > SDH/SONET networks
		> > > >           is being defined in T1 and ITU-T to use
virtual
		> > > > concatenation and GFP
		> > > >           for encapsulation, not arbitrary
concatenation.
		> > > >
		> > > >           The transport of ATM signals via SDH/SONET
		> > > > networks is
		> > > > defined in T1 and
		> > > >           ITU-T to use VC-3/STS-1, VC-4/STS-3c,
		> > > > VC-4-4c/STS-12c,
		> > > > VC-4-16c/STS-48c,
		> > > >           VC-4-64c/STS-192c, VC-4-256c/STS-768c and
		> > > > STS-1-Xv,
		> > > > VC-4-Xv/STS-3c-Xv.
		> > > >
		> > > >           For the case interworking between
subnetworks of
		> > > > different
		> > > > vendors and
		> > > >           networks of different operators is
required, the
		> > > > above
		> > > > signals and
		> > > >           mappings are to be used.
		> > > >
		> > > >           For the case interworking is not required,
any
		> > > > proprietary
		> > > >           implementation (e.g. arbitrary
concatenation) can
		> > > > be used.
		> > > >
		> > > >           Regards,
		> > > >
		> > > >           Maarten
		> > > >
		> > > >
		> > > >           Maarten Vissers wrote:
		> > > >           >
		> > > >           > Greg, Sanjay,
		> > > >           >
		> > > >           > In additon to Juergen's comment, I would
like to
		> > > > point out
		> > > > that VC-4-2c,
		> > > >           > VC-4-3c, VC-4-5c, etc are not longer
part of the
		> > > > SDH
		> > > > hierarchy (G.707
		> > > >           > 10/2000), and I doubt if the ITU-T
community
		> > > > would like to
		> > > > re-introduce
		> > > >           > these signal types given all the hassle
the
		> > > > introduction
		> > > > of VC-4-4c
		> > > >           > (with ATM payload) did cause in the
past.
		> > > >           >
		> > > >           > And as Juergen indicated, real arbitrary
		> > > > concatenation
		> > > > would require the
		> > > >           > mapping of a VC-4-Xc signal in any set
of X AU-4
		> > > > timeslots. As long as
		> > > >           > you need still a series of contiguous
timeslots
		> > > > (i.e.
		> > > > arbitrary
		> > > >           > contiguous concatenation), bandwidth
		> > > > defragmenation (or
		> > > > re-grooming) is
		> > > >           > required once every ...
		> > > >           >
		> > > >           > I.e. arbitrary contiguous concatenation
(ACC)
		> > > >           > - still has the same fragmentation issue
that is
		> > > > also
		> > > > present in today's
		> > > >           > contiguous concatenation; it is less
restrictive
		> > > > from a
		> > > > theoretical
		> > > >           > perspective, but Murphy's law will be
		> > > > applicable, and the
		> > > > fragmentation
		> > > >           > will be such that there is no contiguous
set of
		> > > > AU4
		> > > > timeslots free
		> > > >           > normally - i.e. from the distance, there
is no
		> > > > benifit at
		> > > > all from the
		> > > >           > operational perspective, perhaps even
only a
		> > > > disadvantage
		> > > > (more complex
		> > > >           > provisioning due to more flexibility)
		> > > >           > - ACC signals can not be routed via most
		> > > > SDH/SONET
		> > > > networks.
		> > > >           >
		> > > >           > Within the OTN definition work ongoing,
the ODUk
		> > > > multiplexing is
		> > > >           > intended to be specified with true
arbitrary
		> > > > concatenation. Refer to
		> > > >           > SP15 of the G.709 living list for the
moment.
		> > > > Later this
		> > > > week a first
		> > > >           > ODUk multiplexing text proposal will be
issued
		> > > > towards
		> > > > ITU-T Q.11/15.
		> > > >           >
		> > > >           > Regards,
		> > > >           >
		> > > >           > Maarten
		> > > >           >
		> > > >           > Heiles Juergen wrote:
		> > > >           > >
		> > > >           > > Greg, Sanjay,
		> > > >           > >
		> > > >           > > if you build up a new network, if you
don't
		> > > > have to care
		> > > > about an installed base and if you further can
		> > > > accept to be restricted to a
		> > > > single vendor (E.g. signle ring network) arbitary
		> > > > concatenation could be
		> > > > fine.
		> > > >           > > Concerning the upgrade, virtual
concatenation
		> > > > would
		> > > > often require only a new tributary interface card
		> > > > (depending on your system
		> > > > design), not an upgrade of the whole network
		> > > > element. As you have to install
		> > > > this new interface card due to the new service (e.g.
		> > > > 100M/1G Ethernet)in any
		> > > > case it is not an additional investment.
		> > > >           > > Greg you mentioned re-grooming as far
as I
		> > > > understand
		> > > > arbitary (contiguous) concatenation you still need X
		> > > > contiguous VCs/SPEs.
		> > > > Only the number X and the starting time slot has no
		> > > > limitations as it is the
		> > > > case for standard contiguous cocnatenation. So you
		> > > > still ahve to do
		> > > > re-grooming if for example time slots 1, 5 and 6 are
		> > > > available in an STM-16
		> > > > signal as these time slots are not contgiguous.
		> > > > Arbitary concatenation has
		> > > > less restrictions compared to standard contiguous
		> > > > concatenation, but still
		> > > > has restrictions.
		> > > >           > > Sanjay, you talked about OC3072. We
might have
		> > > > 160
		> > > > Gbit/s in the future in some parts of the network,
		> > > > but others are still
		> > > > running with lower line speeds (e.g. long distance
		> > > > systems, trans oceanic
		> > > > systems) as the higher bit rate imposes limitations
		> > > > in the distance and you
		> > > > have an isntalled base. With virtual concatenation
		> > > > it is not a problem to
		> > > > transport a 160 Gbit/s service (if such a kind of
		> > > > service is needed in any
		> > > > case) over 4x40G or 16x10G.
		> > > >           > > Note that arbitary concatenation was
diffcult
		> > > > to
		> > > > implement with the chip technology available some
		> > > > years ago when the
		> > > > processing was often done in parallel on several
		> > > > chips. Todays single chip
		> > > > solutions allowed to introduce arbitary
		> > > > concatenation. For the size of the
		> > > > alignment buffer for virtual concatenation it is
		> > > > also only a question of the
		> > > > size of available memory chips which will increase
		> > > > over time.
		> > > >           > > Sanjay you mentioned that it might be
possible
		> > > > to use
		> > > > just an SW upgrade for an cross-connect in order to
		> > > > get arbitary
		> > > > concatenation support. I don't think so as arbitary
		> > > > concateantion requries
		> > > > specific pointer processing which is done in HW.
		> > > >           > >
		> > > >           > > Regards
		> > > >           > >
		> > > >           > > Juergen
		> > > >           > >
		> > > >           > > > -----Original Message-----
		> > > >           > > > From: Bernstein, Greg
[SMTP:[email-masked]]
		> > > >           > > > Sent: Monday, May 14, 2001 5:55 AM
		> > > >           > > > To:   'ashritha thirumalai'; Fong,
Man Wing;
		> > > > Maarten
		> > > > Vissers; Heiles Juergen
		> > > >           > > > Cc:   [email-masked]
		> > > >           > > > Subject:      RE: [IP-Optical]
concatenation
		> > > > extensions in sonet/sdh
		> > > >           > > >
		> > > >           > > > Hi Sanjay see comments in line
below.
		> > > >           > > > Greg B.
		> > > >           > > >
		> > > >           > > >       Dr. Greg M. Bernstein, Senior
		> > > > Scientist, Ciena
		> > > >           > > >       New phone: (510) 573-2237
		> > > >           > > >
		> > > >           > > >
		> > > >           > > >               -----Original
Message-----
		> > > >           > > >               From:   ashritha
thirumalai
		> > > > [mailto:[email-masked]]
		> > > >           > > >               Sent:   Saturday, May
12, 2001
		> > > > 9:54 AM
		> > > >           > > >               To:     Bernstein,
Greg; Fong,
		> > > > Man Wing;
		> > > > Maarten Vissers;
		> > > >           > > > Heiles Juergen
		> > > >           > > >               Cc:
		> > > > [email-masked]
		> > > >           > > >               Subject:        RE:
		> > > > [IP-Optical]
		> > > > concatenation extensions in
		> > > >           > > > sonet/sdh
		> > > >           > > >
		> > > >           > > >               Dr. Bernstein,
		> > > >           > > >
		> > > >           > > >               Glad you replied.
		> > > >           > > >
		> > > >           > > >               A few further
questions:
		> > > >           > > >
		> > > >           > > >               1. how are two
different
		> > > > vendors
		> > > > implementing arb-conc
		> > > >           > > >               going to
inter-operate? (i.e.
		> > > > how are
		> > > > bytes in
		> > > >           > > >               an arb-concatenated
channel
		> > > > multiplexed
		> > > > into the
		> > > >           > > >               rest of Sonet/SDH
timeslots?)
		> > > >           > > >               > For non-standard
sizes this
		> > > > needs some
		> > > > work. I'm happy to
		> > > >           > > > work anyone in this area. Starting
with the
		> > > > standard
		> > > > sizes isn't a problem
		> > > >           > > > we just use the already standardized
		> > > > mappings.
		> > > >           > > >               2. would you be able
to list
		> > > > some
		> > > > vendors that
		> > > >           > > >               do (or claim to)
support
		> > > > arb-concat?
		> > > >           > > >               > Ciena's CoreDirector
for
		> > > > one. I know
		> > > > of other vendors but
		> > > >           > > > I'm not sure if they've publicly
announced.
		> > > >           > > >               3. and a repeat
question. why
		> > > > should one
		> > > > go with
		> > > >           > > >               arb-concat when
virt-cont
		> > > > (kludgy as it
		> > > > may be)
		> > > >           > > >               has been standardized.
(in my
		> > > > limited
		> > > > understanding
		> > > >           > > >               of virt-conc, it does
avoid
		> > > > the
		> > > > "re-grooming" that
		> > > >           > > >               you alluded to).
		> > > >           > > >               > Well virtual
concatenation
		> > > > can do
		> > > > everything but it>
		> > > >           > > > requires the edge equipment to be
upgraded.
		> > > > If folks
		> > > > want to preserve their
		> > > >           > > > investments around the edge and
		> > > > incrementally upgrade
		> > > > the core then any line
		> > > >           > > > connecting two pieces of equipment
		> > > > supporting
		> > > > arbitrary concatenation
		> > > >           > > > doesn't need to be re-groomed or be
used
		> > > > inefficiently.  Hence it's a good
		> > > >           > > > feature for core equipment, but
maybe not so
		> > > > hot
		> > > > compared to virtual
		> > > >           > > > concatenation at the edge.
		> > > >           > > >
		> > > >           > > >               greatly appreciate a
reply.
		> > > >           > > >
		> > > >           > > >               Thanx,
		> > > >           > > >               Sanjay.
		> > > >           > > >
		> > > >           > > >
		> > > >           > > >
		> > > >           > > >
		> > > >           > > >               --- "Bernstein, Greg"
		> > > > <[email-masked]>
		> > > > wrote:
		> > > >           > > >               > Hi sorry to be out
of the
		> > > > loop for a
		> > > > while.  Man
		> > > >           > > >               > Wing's assesment and
the
		> > > >           > > >               > concerns about
upgrades are
		> > > > fairly
		> > > > correct except:
		> > > >           > > >               > (1) With the new
generation
		> > > > of
		> > > > SONET/SDH cross
		> > > >           > > >               > connects arbitrary
is a
		> > > >           > > >               > feature.  I can
think of at
		> > > > least one
		> > > > new and very
		> > > >           > > >               > popular switch that
has
		> > > >           > > >               > this feature.
		> > > >           > > >               > (2) I also know of
access
		> > > > equipment
		> > > > vendors that
		> > > >           > > >               > offer this feature
(but not
		> > > >           > > >               > virtual
concatenation).
		> > > >           > > >               > (3) There is a bit
more
		> > > > fundamental
		> > > > reason behind
		> > > >           > > >               > the usefulness of
		> > > >           > > >               > arbitrary
concatenation.
		> > > > Avoiding the
		> > > > need to
		> > > >           > > >               > "re-groom" the
circuits on a
		> > > >           > > >               > line (the nasty
service
		> > > > impacting
		> > > > process of
		> > > >           > > >               > remapping circuits
to time
		> > > >           > > >               > slots so that you
can add a
		> > > > new
		> > > > concatenated circuit
		> > > >           > > >               > within the standard
		> > > >           > > >               > contiguous
concatenation
		> > > > constraints).
		> > > >           > > >               > As to how it got
into the
		> > > > ODSI
		> > > > specification, the
		> > > >           > > >               > answer is fairly
simple,
		> > > >           > > >               > folks (including
myself)
		> > > > asked for it
		> > > > to be
		> > > >           > > >               > included, just like
in the
		> > > > GMPLS
		> > > >           > > >               > specification.  I
haven't
		> > > > found a
		> > > > customer out there
		> > > >           > > >               > that likes to
re-groom
		> > > >           > > >               > traffic (or the
bandwidth
		> > > > inefficiency
		> > > > from not
		> > > >           > > >               > regrooming).
		> > > >           > > >               >
		> > > >           > > >               > Greg B.
		> > > >           > > >               >
		> > > > ***********************************
		> > > >           > > >               > Dr. Greg M.
Bernstein
		> > > >           > > >               > Senior Scientist,
Ciena
		> > > > Corporation
		> > > >           > > >               >
		> > > >           > > >               > -----Original
Message-----
		> > > >           > > >               > From: ashritha
thirumalai
		> > > >           > > >               >
[mailto:[email-masked]]
		> > > >           > > >               > Sent: Friday, May
11, 2001
		> > > > 1:50 PM
		> > > >           > > >               > To: Fong, Man Wing;
Maarten
		> > > > Vissers;
		> > > > Heiles Juergen
		> > > >           > > >               > Cc:
		> > > > [email-masked]
		> > > >           > > >               > Subject: RE:
[IP-Optical]
		> > > > concatenation extensions
		> > > >           > > >               > in sonet/sdh
		> > > >           > > >               >
		> > > >           > > >               >
		> > > >           > > >               > Well, arb-conct is
most
		> > > > really useful
		> > > > for data
		> > > >           > > >               > (i.e.
Packet-Over-Sonet).
		> > > > i.e. one can
		> > > > provide
		> > > >           > > >               > an STS19c or so for
a 1GbE
		> > > > pipe (as
		> > > > opposed to
		> > > >           > > >               > an STS48c as is
currently
		> > > > being done).
		> > > > This
		> > > >           > > >               > goal is same as that
of
		> > > > virt-conc.
		> > > >           > > >               >
		> > > >           > > >               > I am not really sure
how an
		> > > > interconnection will
		> > > >           > > >               > be problematic with
a DACS?
		> > > > Could you
		> > > > elaborate
		> > > >           > > >               > kindly?
		> > > >           > > >               >
		> > > >           > > >               > Thanx,
		> > > >           > > >               > Sanjay
		> > > >           > > >               > --- "Fong, Man Wing"
		> > > > <[email-masked]>
		> > > >           > > >               > wrote:
		> > > >           > > >               > > Hi Sanjay,
		> > > >           > > >               > >
		> > > >           > > >               > > Here is my 2 cents
worth
		> > > > of
		> > > > comments.
		> > > >           > > >               > >
		> > > >           > > >               > > 3. arb. conc. as
well as
		> > > > virt. conc.
		> > > > require
		> > > >           > > >               > > upgrades
		> > > >           > > >               > >    at the end
points,
		> > > > since all
		> > > > systems in a ring
		> > > >           > > >               > >    will be of the
same
		> > > > vendor
		> > > > anyway. (i.e. if one
		> > > >           > > >               > >    system supports
arb.
		> > > > conc. so
		> > > > will the rest in
		> > > >           > > >               > >    the ring).
		> > > >           > > >               > > Not quiet true.
There
		> > > > might be a
		> > > > problem when
		> > > >           > > >               > > interconnecting
with a
		> > > > cross
		> > > >           > > >               > > connect system.
For my
		> > > > understanding, I can't
		> > > >           > > >               > think
		> > > >           > > >               > > of any cross
connect
		> > > >           > > >               > > system support
arbitrary
		> > > > concatenation.
		> > > >           > > >               > >
		> > > >           > > >               > > Regards,
		> > > >           > > >               > > Man Wing
		> > > >           > > >               > >
		> > > >           > > >               > > -----Original
Message-----
		> > > >           > > >               > > From:
ashritha
		> > > > thirumalai
		> > > >           > > >               > >
		> > > > [mailto:[email-masked]]
		> > > >           > > >               > > Sent:
Friday, May
		> > > > 11, 2001
		> > > > 11:55 AM
		> > > >           > > >               > > To: Maarten
Vissers;
		> > > > Heiles Juergen
		> > > >           > > >               > > Cc: 'ashritha
thirumalai';
		> > > >           > > >               > >
		> > > > [email-masked]
		> > > >           > > >               > > Subject:    Re:
		> > > > [IP-Optical]
		> > > > concatenation extensions
		> > > >           > > >               > > in sonet/sdh
		> > > >           > > >               > >
		> > > >           > > >               > > Thanks Juergen and
Maarten
		> > > > for you
		> > > > valuable
		> > > >           > > >               > > feedback.
		> > > >           > > >               > >
		> > > >           > > >               > > Here's my dilemma:
		> > > >           > > >               > >
		> > > >           > > >               > > 1. arb.
concatenation is a
		> > > > natural
		> > > > and elegant
		> > > >           > > >               > >    extension to
sonet/sdh
		> > > > contigous-concatenation.
		> > > >           > > >               >
		> > > >           > > >               > >
		> > > >           > > >               > > 2. arb.
concatenation
		> > > > scales very
		> > > > well with rate. >
		> > > >           > > >               > >    imagine the
buffering
		> > > > required
		> > > > for OC768 or i
		> > > >           > > >               > >    dare say,
OC3072 in a
		> > > > framer
		> > > > device supporting
		> > > >           > > >               > >    virtual
concatenation.
		> > > > (while an
		> > > > ANSI draft
		> > > >           > > >               > >    recommends a
minimum of
		> > > > 1 frame's
		> > > > worth of
		> > > >           > > >               > >    buffering, this
is
		> > > > hardly
		> > > > sufficient. most
		> > > >           > > >               > people
		> > > >           > > >               > >    want about 16
frames
		> > > > worth of
		> > > > buffering).
		> > > >           > > >               > >
		> > > >           > > >               > > 3. in a given
ring, it is
		> > > > virtually
		> > > > unknown to
		> > > >           > > >               > >    intermix
systems from
		> > > > two
		> > > > vendors.
		> > > >           > > >               > >    therefore, a
system
		> > > > (say and ADM)
		> > > > supporting
		> > > >           > > >               > >    arb.
concatenation can
		> > > > gracefully
		> > > > co-exist with
		> > > >           > > >               > >    its sibling
systems on
		> > > > the same
		> > > > ring.
		> > > >           > > >               > >
		> > > >           > > >               > > 4. now the
question is
		> > > > what happens
		> > > > at end-points.
		> > > >           > > >               >
		> > > >           > > >               > >    well, the
end-points
		> > > > (especially
		> > > > the receive)
		> > > >           > > >               > >    will have to
support
		> > > > arb
		> > > > concatenation.
		> > > >           > > >               > >    (if there is a
cross
		> > > > connect, it
		> > > >           > > >               > >    could possibly
be
		> > > > handled by
		> > > > software alone).
		> > > >           > > >               > >
		> > > >           > > >               > >    On the other
hand,
		> > > > virtual
		> > > > concatenation will
		> > > >           > > >               > >    need support as
well at
		> > > > the
		> > > > end-points. i.e.
		> > > >           > > >               > >    current systems
will
		> > > > need to be
		> > > > upgraded.
		> > > >           > > >               > >
		> > > >           > > >               > > my summary (i hope
you
		> > > > will critique
		> > > > this):
		> > > >           > > >               > >
		> > > >           > > >               > > 1. arb. conc. is a
more
		> > > > elegant
		> > > > solution.
		> > > >           > > >               > > 2. arb. conc.
scales quite
		> > > > well with
		> > > > rate, while
		> > > >           > > >               > >    vir. conc. gets
uglier
		> > > > and uglier
		> > > > to implement.
		> > > >           > > >               >
		> > > >           > > >               > > 3. arb. conc. as
well as
		> > > > virt. conc.
		> > > > require
		> > > >           > > >               > > upgrades
		> > > >           > > >               > >    at the end
points,
		> > > > since all
		> > > > systems in a ring
		> > > >           > > >               > >    will be of the
same
		> > > > vendor
		> > > > anyway. (i.e. if one
		> > > >           > > >               > >    system supports
arb.
		> > > > conc. so
		> > > > will the rest in
		> > > >           > > >               > >    the ring).
		> > > >           > > >               > > 4. why is ODSI
making a
		> > > > mention of
		> > > > arb.
		> > > >           > > >               > > concatenation
		> > > >           > > >               > >    in their
functional
		> > > > spec?
		> > > >           > > >               > >
		> > > >           > > >               > > Thanx,
		> > > >           > > >               > > Sanjay.
		> > > >           > > >               > > --- Maarten
Vissers
		> > > > <[email-masked]> wrote:
		> > > >           > > >               > > > Sanjay,
		> > > >           > > >               > > >
		> > > >           > > >               > > > Arbitrary
concatenation
		> > > > was
		> > > > present in the very
		> > > >           > > >               > > > first versions
of T.105
		> > > >           > > >               > > > and G.707
(called G.709
		> > > > at the
		> > > > time). It was
		> > > >           > > >               > never
		> > > >           > > >               > > > implemented,
until
		> > > >           > > >               > > > ATM people
decided
		> > > > (without
		> > > > consultation with
		> > > >           > > >               > > > transport
people) to
		> > > >           > > >               > > > define ATM over
		> > > > VC-4-4c/STS-12c.
		> > > > The problems
		> > > >           > > >               > this
		> > > >           > > >               > > > has caused
initially
		> > > >           > > >               > > > in the networks
was
		> > > > tremendous;
		> > > > VC-4-4c/STS-12c
		> > > >           > > >               > > > couldn't be
transported
		> > > >           > > >               > > > as a tributary
signal in
		> > > > e.g.
		> > > > STM-16/OC-48
		> > > >           > > >               > > signals,
		> > > >           > > >               > > > it could only be
		> > > >           > > >               > > > transported
within an
		> > > > STM-4/OC-12
		> > > > directly on
		> > > >           > > >               > > fiber
		> > > >           > > >               > > > (very
expensive!!).
		> > > >           > > >               > > > Only when new
network
		> > > > elements
		> > > > where installed
		> > > >           > > >               > > > supporting
		> > > >           > > >               > > > VC-4-4c/STS-12c
this
		> > > > ATM-service
		> > > > could be
		> > > >           > > >               > handled
		> > > >           > > >               > > by
		> > > >           > > >               > > > the transport
		> > > >           > > >               > > > networks at
normal
		> > > > costs. To
		> > > > transport
		> > > >           > > >               > > > VC-4-4c/STS-12c
over the
		> > > > original
		> > > >           > > >               > > > SDH networks,
		> > > > contiguous/virtual
		> > > > concatenation
		> > > >           > > >               > > > conversion
function has
		> > > >           > > >               > > > been defined
(see
		> > > > G.707); special
		> > > > cont/virt conc
		> > > >           > > >               > > > conversion
interface
		> > > >           > > >               > > > port units have
been
		> > > > designed and
		> > > > installed.
		> > > >           > > >               > > >
		> > > >           > > >               > > > Arbitrary
concatenation
		> > > > has been
		> > > > taken out in
		> > > >           > > >               > the
		> > > >           > > >               > > > latest versions
of the
		> > > >           > > >               > > > two standards
for the
		> > > > reasons
		> > > > mentioned by
		> > > >           > > >               > Juergen
		> > > >           > > >               > > > and indicated
above.
		> > > >           > > >               > > > I would say that
most
		> > > > likely 99%
		> > > > of the existing
		> > > >           > > >               > > > SONET/SDH
networks do
		> > > >           > > >               > > > not support
arbitrary
		> > > > concatenation, and there
		> > > >           > > >               > are
		> > > >           > > >               > > > no client
signals
		> > > >           > > >               > > > defined that are
mapped
		> > > > into
		> > > > arbitrary
		> > > >           > > >               > > concatenated
		> > > >           > > >               > > > signals. So I
would
		> > > >           > > >               > > > assume that
arbitrary
		> > > > concatenation is a dead
		> > > >           > > >               > > body,
		> > > >           > > >               > > > not worth to
invest
		> > > >           > > >               > > > a single penny
in.
		> > > > Virtual
		> > > > concatenation is the
		> > > >           > > >               > > > future.
		> > > >           > > >               > > >
		> > > >           > > >               > > > Regards,
		> > > >           > > >               > > >
		> > > >           > > >               > > > Maarten
		> > > >           > > >               > > >
		> > > >           > > >               > > > Heiles Juergen
wrote:
		> > > >           > > >               > > > >
		> > > >           > > >               > > > > Sanjay,
		> > > >           > > >               > > > >
		> > > >           > > >               > > > > arbitary
contiguous
		> > > > concatenation has to be
		> > > >           > > >               > > > supported by all
network
		> > > > elements
		> > > > along the>
		> > > >           > > >               > path,>
		> > > >           > > >               > > > while virtual
		> > > > concatenation needs
		> > > > only support
		> > > >           > > >               > at
		> > > >           > > >               > > > the end systems
		> > > > terminating
		> > > > virtual
		> > > >           > > >               > concatenation
		> > > >           > > >               > > > and providing
access to
		> > > > the client
		> > > > signal.
		> > > >           > > >               > > > > Arbitary
contiguous
		> > > > concatenation is not
		> > > >           > > >               > > > standardized and
support
		> > > > only by
		> > > > several
		> > > >           > > >               > vendors.
		> > > >           > > >               > > > Exisitng
networks don't
		> > > > support
		> > > > it. It would
		> > > >           > > >               > > require
		> > > >           > > >               > > > a replacement of
most
		> > > > network
		> > > > elements,
		> > > >           > > >               > something
		> > > >           > > >               > > > operators don't
want.
		> > > > With virtual
		> > > > concatenation
		> > > >           > > >               > > you
		> > > >           > > >               > > > can go through
exisitng
		> > > > networks.
		> > > > Only the end
		> > > >           > > >               > > > systems that
support the
		> > > > specific
		> > > > client signal
		> > > >           > > >               > > have
		> > > >           > > >               > > > to support
virtual
		> > > > concatenation
		> > > > also.
		> > > >           > > >               > > > > Furthermore
virtual
		> > > > concatenation allows to
		> > > >           > > >               > > > disribute the
individual
		> > > > VCs/STS-SPEs over
		> > > >           > > >               > several
		> > > >           > > >               > > > STM/OC signals,
which is
		> > > > not
		> > > > possible with
		> > > >           > > >               > > > contiguous
		> > > > concatenation. An
		> > > > application for
		> > > >           > > >               > this
		> > > >           > > >               > > is
		> > > >           > > >               > > > the transport of
a 10
		> > > > Gbit/s
		> > > > paylaod over
		> > > >           > > >               > 4xOC-48
		> > > >           > > >               > > in
		> > > >           > > >               > > > a OC-48 based
WDM
		> > > > system.
		> > > >           > > >               > > > > The LCAS (Link
		> > > > Capacity
		> > > > Adjustment Scheme)
		> > > >           > > >               > > allows
		> > > >           > > >               > > > to modify the
number of
		> > > > virtual
		> > > > concatenated
		> > > >           > > >               > > signals
		> > > >           > > >               > > > (and as such the
		> > > > transport
		> > > > bandwidth) on the
		> > > >           > > >               > fly.
		> > > >           > > >               > > > > In my view
virtual
		> > > > concatenation
		> > > > has a longer
		> > > >           > > >               > > > lifetime.
		> > > >           > > >               > > > >
		> > > >           > > >               > > > > Regards
		> > > >           > > >               > > > >
		> > > >           > > >               > > > > Juergen
		> > > >           > > >               > > > >
		> > > >           > > >               > > > > >
-----Original
		> > > > Message-----
		> > > >           > > >               > > > > > From:
ashritha
		> > > > thirumalai
		> > > >           > > >               > > >
		> > > > [SMTP:[email-masked]]
		> > > >           > > >               > > > > > Sent:
Monday, May
		> > > > 07, 2001
		> > > > 9:05 PM
		> > > >           > > >               > > > > > To:
		> > > > [email-masked]
		> > > >           > > >               > > > > > Cc:
		> > > > [email-masked]
		> > > >           > > >               > > > > > Subject:
		> > > > [IP-Optical]
		> > > > concatenation
		> > > >           > > >               > > > extensions in
sonet/sdh
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > All,
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > A newbie
question.
		> > > > (and a
		> > > > digression from
		> > > >           > > >               > > > current
		> > > >           > > >               > > > > > threads)
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > Virtual
		> > > > concatenation seems to
		> > > > have been
		> > > >           > > >               > > > accepted
		> > > >           > > >               > > > > > as standard
		> > > > procedure.
		> > > > Lucent/Agere, Cypress
		> > > >           > > >               > > etc
		> > > >           > > >               > > > > > seem to have
sonet
		> > > > framers
		> > > > that support
		> > > >           > > >               > > virtual
		> > > >           > > >               > > > > >
concatenation.
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > However,
there has
		> > > > been some
		> > > > discussion on
		> > > >           > > >               > > > > > arbitrary
		> > > > concatenation as
		> > > > well. arbitrary
		> > > >           > > >               > > > > >
concatenation seems
		> > > > to be a
		> > > > graceful
		> > > >           > > >               > extension
		> > > >           > > >               > > > > > of
sonet/sdh's
		> > > > contiguous
		> > > > concatenation,
		> > > >           > > >               > while
		> > > >           > > >               > > > > > virtual
		> > > > concatenation seems
		> > > > like such a
		> > > >           > > >               > hack.
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > I invite
your
		> > > > opinions and
		> > > > comments on the
		> > > >           > > >               > > > > >
applications,
		> > > > relevance and
		> > > > potential
		> > > >           > > >               > > lifetimes
		> > > >           > > >               > > > > > of virtual
and
		> > > > arbitrary
		> > > > concatenation
		> > > >           > > >               > > schemes.
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > > Thanx,
		> > > >           > > >               > > > > > Sanjay.
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > >
		> > > >           > > >               > > >
		> > > >           > > >               >
		> > > > __________________________________________________
		> > > >           > > >               > > > > > Do You
Yahoo!?
		> > > >           > > >               > > > > > Yahoo!
Auctions -
		> > > > buy the
		> > > > things you want at
		> > > >           > > >               > > > great prices
		> > > >           > > >               > > > > >
		> > > > http://auctions.yahoo.com/
		> > > >           > > >               > > > > >
		> > > >           > > >               > > > > >
		> > > >           > > >               > >
		> > > > _______________________________________________
		> > > >           > > >               > > > > > IP-Optical
mailing
		> > > > list
		> > > >           > > >               > > > > >
		> > > > [email-masked]
		> > > >           > > >               > > > > >
		> > > >           > > >               > > >
		> > > >           > > >               > >
		> > > >           > > >               >
		> > > >           > > >
		> > > >
		> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
		> > > >           > > >               > > > >
		> > > >           > > >               > > > >
		> > > >           > > >               >
		> > > > _______________________________________________
		> > > >           > > >               > > > > IP-Optical
mailing
		> > > > list
		> > > >           > > >               > > > >
		> > > > [email-masked]
		> > > >           > > >               > > > >
		> > > >           > > >               > >
		> > > >           > > >               >
		> > > >           > > >
		> > > >
		> > >
http://lists.bell-labs.com/mailman/listinfo/ip-optical>
		> > > >           > > >               > > begin:vcard
		> > > >           > > >               > > >
n:Vissers;Maarten
		> > > >           > > >               > > > tel;cell:+31 62
061 3945
		> > > >           > > >               > > > tel;fax:+31 35
687 5976
		> > > >           > > >               > > > tel;home:+31 35
526 5463
		> > > >           > > >               > > > tel;work:+31 35
687 4270
		> > > >           > > >               > > >
x-mozilla-html:FALSE
		> > > >           > > >               > > > org:Lucent
Technologies
		> > > > Nederland;NA&CPSE
		> > > >           > > >               > > > version:2.1
		> > > >           > > >               > > >
		> > > > email;internet:[email-masked]
		> > > >           > > >               > > >
		> > > > adr;quoted-printable:;;Botterstraat
		> > > >           > > >               > > >
45=0D=0A=0D=0A;1271 XL
		> > > > Huizen;;;The Netherlands>
		> > > >           > > >               > >>  > > fn:Maarten
Vissers
		> > > >           > > >               > > > end:vcard
		> > > >           > > >               > > >
		> > > >           > > >               > >
		> > > >           > > >               > >
		> > > >           > > >               > >
		> > > > __________________________________________________
		> > > >           > > >               > > Do You Yahoo!?
		> > > >           > > >               > > Yahoo! Auctions -
buy the
		> > > > things you
		> > > > want at great
		> > > >           > > >               > > prices
		> > > >           > > >               > >
http://auctions.yahoo.com/
		> > > >           > > >               > >
		> > > >           > > >               > >
		> > > > _______________________________________________
		> > > >           > > >               > > IP-Optical mailing
list
		> > > >           > > >               > >
		> > > > [email-masked]
		> > > >           > > >               > >
		> > > >           > > >               >
		> > > >           > > >
		> > > >
		> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
		> > > >           > > >               >
		> > > >           > > >               >
		> > > >           > > >               >
		> > > > __________________________________________________
		> > > >           > > >               > Do You Yahoo!?
		> > > >           > > >               > Yahoo! Auctions -
buy the
		> > > > things you
		> > > > want at great
		> > > >           > > >               > prices
		> > > >           > > >               >
http://auctions.yahoo.com/
		> > > >           > > >               >
		> > > >           > > >               >
		> > > > _______________________________________________
		> > > >           > > >               > IP-Optical mailing
list
		> > > >           > > >               >
		> > > > [email-masked]
		> > > >           > > >               >
		> > > >           > > >
		> > > >
		> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
		> > > >           > > >
		> > > >           > > >
		> > > >           > > >
		> > > > __________________________________________________
		> > > >           > > >               Do You Yahoo!?
		> > > >           > > >               Yahoo! Auctions - buy
the
		> > > > things you
		> > > > want at great prices
		> > > >           > > >
http://auctions.yahoo.com/
		> > > >           > >
		> > > >           > >
		> > > > _______________________________________________
		> > > >           > > IP-Optical mailing list
		> > > >           > > [email-masked]
		> > > >           > >
		> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
		> > >
		> > >
		> > > __________________________________________________
		> > > Do You Yahoo!?
		> > > Yahoo! Auctions - buy the things you want at great
prices
		> > > http://auctions.yahoo.com/
		> > >
		> > > _______________________________________________
		> > > IP-Optical mailing list
		> > > [email-masked]
		> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
		> > >
		> >
		> 
		> _______________________________________________
		> IP-Optical mailing list
		> [email-masked]
		> http://lists.bell-labs.com/mailman/listinfo/ip-optical

Delivery-date: Thu, 17 May 2001 06:48:07 -0700
Date: Thu, 17 May 2001 09:46:59 -0400
From: Siva Sankaranarayanan <[email-masked]>
Reply-To: [email-masked]
Organization: JJ0C21010
To: Zhi-Wei Lin <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ASTN Layer Network Architecture

Tammy, Maarten and Zhi,
  Along the lines of Zhi's question, it is also fundamental to know
which plane "owns" the management responsibility for the connection,
e.g., if a SPC is setup, then is it the management plane which owns this
or the control plane.  The management plane initiates the request, but
the control plane executes the request via NNI signaling.  As far as I
see, if we resolve this issue, then we can get a better understanding of
what is meant by "migrating" a connection from the management plane to
the control plane control.

Regards,
Shiva
------------------
Sivakumar Sankaranarayanan
Member of Technical Staff 
HO 3C-508A 
Lucent Technologies,
101 Crawfords Corner Road,
Holmdel, NJ 07733.

Phone: 	+1 732 949 5762
Fax: 	+1 732 949 3210 (Attn: S. Sankaranarayanan)
Email: 	[email-masked]

Delivery-date: Thu, 17 May 2001 06:21:24 -0700
Date: Thu, 17 May 2001 09:13:11 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: Dimitri Papadimitriou <[email-masked]>
CC: Maarten Vissers <[email-masked]>, Michael Waldo <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

Hi,

I think there will always be some set of vendors in the industry that
will add proprietary extensions to standards-based specifications
regardless of whether it is transport standards or protocol standards. 

The question that should be asked first is: is GMPLS going to add
proprietary extensions above and beyond what is standards specified? If
the answer is "yes", then that sets the precedence for any and all
vendors to request inclusion of their favorite proprietary extensions to
GMPLS. 

And if one specific proprietary extension gets an enumerated codepoint,
then that also sets the precedence for any and all vendors to request
specific codepoints for their favorite proprietary extensions. 

Are we prepared to accept that?

Zhi

BTW, currently the virtual concatenated capability specified for GMPLS
only allows for co-routing of the individual component VCs, while the
standard calls for any routing (over any links) of the individual
component VCs (more flexible). As such, do we need to call this out
explicitly in the GMPLS draft so that people do not get a
mis-understanding of what virtual concatenation can do? 

We can obviously extend this for GMPLS in the future to support the full
flexibility allowed for virtual concatenation. 

Dimitri Papadimitriou wrote:
> 
> Dear Maarten et all,
> 
> For "arbitrary contiguous concatenation" you stated (and of course)
> i agree it has been removed but the question is: what about existing
> equipments it is not because it has been removed from recommendation
> that products disappear - can someone confirm the use of arbitrary
> contiguous concatenation ? - there is also a difference between "what
> the ideal situation should be and what the situation is today in
> SDH/Sonet networks"
> 
> => ... so i don't really think it is a big issue and the following
> alternative can be used to determine what can be done:
> - either we strictly comply to "last versions" of G.707 / T1.105
> in that case "arbitrary contiguous concatenation" must be removed
> - or we do not strictly comply today then the "arbitrary concatenation"
> has to be considered in addition to "arbitrary contiguous
> concatenation" - in that case a submission to the ITU-T/T1 should be
> ideally proposed in order to "harmonize" the specifications
> - or we stay as defined today making the assumption that "arbitrary
> contiguous concatenation" was included so that some equipments might
> still support it.
> 
> Any other possibility ?
> 
> Regards,
> Dimitri.
> 
> Maarten Vissers wrote:
> >
> > Waldo,
> >
> > I am copying an email conversation ongoing in the IP-optical mailing
> > list on arbitrary concatenation. Hope this provides the input you are
> > looking for.
> >
> > Bottom line is that neither arbitrary contiguous concatenation nor
> > arbitrary concatenation is part of the SONET/SDH standards. It is a
> > vendor proprietary extension of these SONET/SDH standards, for which it
> > is in my (and some other peoples) view highly unlikely that it will be
> > included in the SONET/SDH standards.
> >
> > As you indicate with virtual concatenation being the international
> > standard and the direction in the industry today, arbitrary
> > concatenation doesn't add anything to the transport network; contrary,
> > it would cause interworking problems.
> >
> > But arbitrary contiguous concatenation wouldn't add anything either, and
> > compared to arbitrary concatenation it would still have the bandwidth
> > fragmentation problem that standard contiguous concatenation is having.
> > I.e. arbitrary contiguous concatenation is worse.
> >
> > All,
> >
> > The GMPLS SONET/SDH extension document is thus defining a control plane
> > which supports capabilities in the transport plane that are not
> > supported by the international standards for this transport plane.
> > Personally, I find this very incorrect. IETF has no mandate to change
> > the SONET/SDH standards. A control plane for the transport network
> > should follow the transport network standards, not define its own
> > transport network.
> >
> > Regards,
> >
> > Maarten
> >
> > ---------------
> >
> > Maarten Vissers wrote:
> > >
> > > Greg, Anup, Sanjay,
> > >
> > > To my recollection, the SONET/SDH definition is performed in T1X1.5 and
> > > ITU-T SG15. Last year new revisions of T1.105 and G.707 were approved,
> > > in which the "arbitrary contiguous concatenation" has been removed. Such
> > > step isn't made just for fun.
> > >
> > > If you believe the removal of "arbitrary contiguous concatenation" from
> > > these standards was a mistake, please submit a contribution to T1X1.5
> > > and ITU-T Q.11/15 with a proposal to re-introduce it. At the same time
> > > you can then also request to introduce "arbitrary concatenation" and
> > > propose mappings of client signals into these arbitrary (contiguous)
> > > concatenated signals. However, as indicated by Mark, Juergen and myself,
> > > I doubt if you find support for such extension of SONET and SDH.
> > >
> > > For the moment, SONET/SDH networks compliant with T1.105 and G.707
> > > standards can forward "contiguous concatenated" VC-4-Xc (X=4,16,64) and
> > > STS-3c/12c/48c/192c signals and "virtual concatenated" VC-n-Xv (n=3,4),
> > > STS-1, STS-3c-Xc (X=1..256) and VC-n (n=11,12), VT-1.5-Xv (X=1..64)
> > > signals, not the "arbitrary concatenated" signals.
> > > Arbitrary concatenation is a proprietary extension of SONET/SDH, for
> > > which there is no interworking with standard SONET/SDH networks.
> > >
> > > Virtual concatenation is THE international standardised direction, for
> > > which a vendor and operator may expect to see seemless interworking in
> > > the SONET/SDH network.
> > >
> > > Virtual concatenation got very popular due to the:
> > > - pricing of Ethernet ports on routers (compared to pricing of
> > > STM-N/OC-N ports on routers),
> > > - absence of channelized STM-N/OC-N interface ports on routers.
> > >
> > > As a result the transport network was forced to accept Ethernet physical
> > > interfaces, in additon to the traditional SONET/SDH and PDH interfaces.
> > > Transport networking engineers very well understand the desire of a
> > > customer to pay only for the bandwidth needed, and consequential within
> > > the constraints of the SONET/SDH transport network a solution was
> > > developed to meet the needs of the customer and the needs of the
> > > operator. This is virtual concatenation with GFP as encapsulation
> > > method.
> > >
> > > Virtual concatenation allows to separate the physical and logical
> > > aspects of Ethernet signals, like such is common practice for any other
> > > SDH/SONET signal. I.e. the (10M, 100M, 1G) Ethernet PHY signal is
> > > terminated, the ethernet idle packets are dropped and the packets with
> > > information inside of it are forwarded in a transport pipe sized to the
> > > customers need.
> > > The additional complexity is the introduction of a (skinny) ehternet
> > > layer on top of the SDH/SONET layers, as at a minimum some monitoring is
> > > to be performed at the ethernet level.
> > >
> > > Of course, it would be more economical if the transport network didn't
> > > have to do this job. I.e. routers should use STM-N/OC-N interface ports
> > > supporting virtual concatenated VC-n/STS/VT signals. The transport
> > > network would n't have to deal then with its client signals, and instead
> > > of ethernet in the virtual concatenated signals, any other data protocol
> > > could be used by the routers (e.g. IP/PPP/GFP).
> > >
> > > But, while having to do this ethernet processing, extensions are
> > > becoming economical in the access transport networks; i.e. having
> > > ethernet bridging/switching present, it can be used to groom ethernet
> > > traffic to further optimise and thus cost reduce ethernet packet
> > > transport. It is now possible to offer sub-VC-n/STS/VT ethernet
> > > transport pipes (in addition to the multi-VC-n/STS/VT ) through the
> > > SDH/SONET access networks.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Anup Tirumala wrote:
> > > >
> > > > If routers can routinely fill TDM pipes fully, why are we even talking
> > > > virtual concatenation?
> > > >
> > > > Arbitrary (or even Virtual) concatenation has the
> > > > best bang for buck with packets sharing bandwidth
> > > > with TDM. (i.e. in a converged network).
> > > >
> > > > Indeed, a business case does exist for arbitrary concatenation.
> > > > Ask Cyras (now Ciena;)
> > > >
> > > > You must look at this in conjunction with Network Processors
> > > > and statistical multiplexing.
> > > >
> > > > A customer need only pay for as much bandwidth as he/she needs,
> > > > while the remainder can be used for TDM channels.
> > > >
> > > > We believe the case for arbitrary concatenation does exist:
> > > >
> > > > 1. scales better with technology.
> > > > 2. no massive buffering requirements. (note that virtual concatenation
> > > >    does not "guarantee" hit-less operation. with buffering, one can limit
> > > >    the hit that's all).
> > > > 3. augments native contiguous concatenation. i.e. contiguous concatenation
> > > >    becomes a degenerate case of arbitrary concatenation.
> > > > 4. A customer explicity asked for it. :)
> > > >
> > > > I think there is merit to an effort at interoperability.
> > > >
> > > > -anup
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > > > Sent: Tuesday, May 15, 2001 12:36 PM
> > > > > To: [email-masked]
> > > > > Cc: [email-masked]; [email-masked];
> > > > > [email-masked]
> > > > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > > > >
> > > > >
> > > > > From my perspective, all necessary applications can be met by
> > > > > contiguous
> > > > > and virtual concatenation.  Adding arbitrary concatenation simply
> > > > > increases the number of spares to maintain, the number of
> > > > > attributes to
> > > > > test for interoperability, and the potential complexity to
> > > > > port cards.
> > > > > The improved bandwidth efficiency you are going to claim
> > > > > won't outweigh
> > > > > the problems I see as a result.  Unless you can show a significant
> > > > > business driver for this, I would recommend not wasting your
> > > > > time trying
> > > > > to standardize it.  The trend is to maintain variable size
> > > > > connections
> > > > > using packets anyway.  Why are we talking about doing this
> > > > > with TDM?  I
> > > > > find it most interesting that this IETF group is discussing variable
> > > > > size TDM pipes, when routers typically can fill a TDM pipe at
> > > > > the line
> > > > > rate.
> > > > >
> > > > > Mark Loyd Jones
> > > > > Sprint
> > > > > Technology Planning & Integration
> > > > > 913-534-5247
> > > > > [email-masked]
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: chickoo66 [mailto:[email-masked]]
> > > > > > Sent: Tuesday, May 15, 2001 1:47 PM
> > > > > > To: GregB; mvissers; ip-optical
> > > > > > Cc: chickoo66
> > > > > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > > > > >
> > > > > >
> > > > > > I could not agree more.
> > > > > > Arb-Concatenation, being a logical (and graceful)
> > > > > > extension of standard contiguous concatenation,
> > > > > > can easily co-exist with virtual.
> > > > > > Imagine channels such as 2c,5c,6c,7c... 767c :)
> > > > > > However, we need to be able to interoperate
> > > > > > with outside-vendor equipments, with regards
> > > > > > to the multiplexing scheme.
> > > > > > Dr.Berstein/other, do you know of any such
> > > > > > interoperating effort on-going?
> > > > > > Would any one be interested in interoperability
> > > > > > issues pertaining to arb-concat?
> > > > > > I emphasize: arb-conc is complementary to virt-concat.
> > > > > > Comments?
> > > > > > Sanjay
> > > > > >
> > > > > >
> > > > > >
> > > > > > --- "Bernstein, Greg" <[email-masked]> wrote:
> > > > > > > Folks, please note that Arbitrary concatenation is
> > > > > > > not in any of the ITU or
> > > > > > > ANSI standards as Maarten points out below.
> > > > > > > Maarten my understanding is that GFP can be used
> > > > > > > with either standard
> > > > > > > contiguous concatenation or virtual concatenation.
> > > > > > >
> > > > > > > For those interested in arbitrary concatenation for
> > > > > > > the standard sizes,
> > > > > > > e.g., STS-3c, STS-12c, one can just use the payload
> > > > > > > mappings from standard
> > > > > > > contiguous concatenation.  A network supporting
> > > > > > > arbitrary concatenation can
> > > > > > > transport these efficiently with no re-grooming.
> > > > > > >
> > > > > > > Note that I think SDH/SONET networks can make use of
> > > > > > > both virtual and
> > > > > > > arbitrary concatenation.
> > > > > > > Greg B.
> > > > > > >
> > > > > > >   Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > > > > > >   New phone: (510) 573-2237
> > > > > > >
> > > > > > >
> > > > > > >           -----Original Message-----
> > > > > > >           From:   Maarten Vissers [mailto:[email-masked]]
> > > > > > >           Sent:   Tuesday, May 15, 2001 1:06 AM
> > > > > > >           To:     Bernstein, Greg; 'ashritha thirumalai';
> > > > > > > [email-masked]
> > > > > > >           Subject:        Re: [IP-Optical] concatenation
> > > > > > extensions
> > > > > > > in
> > > > > > > sonet/sdh
> > > > > > >
> > > > > > >            << File: Card for Maarten Vissers >> Greg,
> > > > > > >
> > > > > > >           The transport of ethernet signals via SDH/SONET
> > > > > > > networks is
> > > > > > > being
> > > > > > >           defined in T1 and ITU-T to use virtual
> > > > > > > concatenation and GFP
> > > > > > > for
> > > > > > >           encapsulation, not arbitrary concatenation.
> > > > > > >
> > > > > > >           The transport of SAN signals (ESCON, FC, FICON)
> > > > > > > via
> > > > > > > SDH/SONET networks
> > > > > > >           is being defined in T1 and ITU-T to use virtual
> > > > > > > concatenation and GFP
> > > > > > >           for encapsulation, not arbitrary concatenation.
> > > > > > >
> > > > > > >           The transport of ATM signals via SDH/SONET
> > > > > > > networks is
> > > > > > > defined in T1 and
> > > > > > >           ITU-T to use VC-3/STS-1, VC-4/STS-3c,
> > > > > > > VC-4-4c/STS-12c,
> > > > > > > VC-4-16c/STS-48c,
> > > > > > >           VC-4-64c/STS-192c, VC-4-256c/STS-768c and
> > > > > > > STS-1-Xv,
> > > > > > > VC-4-Xv/STS-3c-Xv.
> > > > > > >
> > > > > > >           For the case interworking between subnetworks of
> > > > > > > different
> > > > > > > vendors and
> > > > > > >           networks of different operators is required, the
> > > > > > > above
> > > > > > > signals and
> > > > > > >           mappings are to be used.
> > > > > > >
> > > > > > >           For the case interworking is not required, any
> > > > > > > proprietary
> > > > > > >           implementation (e.g. arbitrary concatenation) can
> > > > > > > be used.
> > > > > > >
> > > > > > >           Regards,
> > > > > > >
> > > > > > >           Maarten
> > > > > > >
> > > > > > >
> > > > > > >           Maarten Vissers wrote:
> > > > > > >           >
> > > > > > >           > Greg, Sanjay,
> > > > > > >           >
> > > > > > >           > In additon to Juergen's comment, I would like to
> > > > > > > point out
> > > > > > > that VC-4-2c,
> > > > > > >           > VC-4-3c, VC-4-5c, etc are not longer part of the
> > > > > > > SDH
> > > > > > > hierarchy (G.707
> > > > > > >           > 10/2000), and I doubt if the ITU-T community
> > > > > > > would like to
> > > > > > > re-introduce
> > > > > > >           > these signal types given all the hassle the
> > > > > > > introduction
> > > > > > > of VC-4-4c
> > > > > > >           > (with ATM payload) did cause in the past.
> > > > > > >           >
> > > > > > >           > And as Juergen indicated, real arbitrary
> > > > > > > concatenation
> > > > > > > would require the
> > > > > > >           > mapping of a VC-4-Xc signal in any set of X AU-4
> > > > > > > timeslots. As long as
> > > > > > >           > you need still a series of contiguous timeslots
> > > > > > > (i.e.
> > > > > > > arbitrary
> > > > > > >           > contiguous concatenation), bandwidth
> > > > > > > defragmenation (or
> > > > > > > re-grooming) is
> > > > > > >           > required once every ...
> > > > > > >           >
> > > > > > >           > I.e. arbitrary contiguous concatenation (ACC)
> > > > > > >           > - still has the same fragmentation issue that is
> > > > > > > also
> > > > > > > present in today's
> > > > > > >           > contiguous concatenation; it is less restrictive
> > > > > > > from a
> > > > > > > theoretical
> > > > > > >           > perspective, but Murphy's law will be
> > > > > > > applicable, and the
> > > > > > > fragmentation
> > > > > > >           > will be such that there is no contiguous set of
> > > > > > > AU4
> > > > > > > timeslots free
> > > > > > >           > normally - i.e. from the distance, there is no
> > > > > > > benifit at
> > > > > > > all from the
> > > > > > >           > operational perspective, perhaps even only a
> > > > > > > disadvantage
> > > > > > > (more complex
> > > > > > >           > provisioning due to more flexibility)
> > > > > > >           > - ACC signals can not be routed via most
> > > > > > > SDH/SONET
> > > > > > > networks.
> > > > > > >           >
> > > > > > >           > Within the OTN definition work ongoing, the ODUk
> > > > > > > multiplexing is
> > > > > > >           > intended to be specified with true arbitrary
> > > > > > > concatenation. Refer to
> > > > > > >           > SP15 of the G.709 living list for the moment.
> > > > > > > Later this
> > > > > > > week a first
> > > > > > >           > ODUk multiplexing text proposal will be issued
> > > > > > > towards
> > > > > > > ITU-T Q.11/15.
> > > > > > >           >
> > > > > > >           > Regards,
> > > > > > >           >
> > > > > > >           > Maarten
> > > > > > >           >
> > > > > > >           > Heiles Juergen wrote:
> > > > > > >           > >
> > > > > > >           > > Greg, Sanjay,
> > > > > > >           > >
> > > > > > >           > > if you build up a new network, if you don't
> > > > > > > have to care
> > > > > > > about an installed base and if you further can
> > > > > > > accept to be restricted to a
> > > > > > > single vendor (E.g. signle ring network) arbitary
> > > > > > > concatenation could be
> > > > > > > fine.
> > > > > > >           > > Concerning the upgrade, virtual concatenation
> > > > > > > would
> > > > > > > often require only a new tributary interface card
> > > > > > > (depending on your system
> > > > > > > design), not an upgrade of the whole network
> > > > > > > element. As you have to install
> > > > > > > this new interface card due to the new service (e.g.
> > > > > > > 100M/1G Ethernet)in any
> > > > > > > case it is not an additional investment.
> > > > > > >           > > Greg you mentioned re-grooming as far as I
> > > > > > > understand
> > > > > > > arbitary (contiguous) concatenation you still need X
> > > > > > > contiguous VCs/SPEs.
> > > > > > > Only the number X and the starting time slot has no
> > > > > > > limitations as it is the
> > > > > > > case for standard contiguous cocnatenation. So you
> > > > > > > still ahve to do
> > > > > > > re-grooming if for example time slots 1, 5 and 6 are
> > > > > > > available in an STM-16
> > > > > > > signal as these time slots are not contgiguous.
> > > > > > > Arbitary concatenation has
> > > > > > > less restrictions compared to standard contiguous
> > > > > > > concatenation, but still
> > > > > > > has restrictions.
> > > > > > >           > > Sanjay, you talked about OC3072. We might have
> > > > > > > 160
> > > > > > > Gbit/s in the future in some parts of the network,
> > > > > > > but others are still
> > > > > > > running with lower line speeds (e.g. long distance
> > > > > > > systems, trans oceanic
> > > > > > > systems) as the higher bit rate imposes limitations
> > > > > > > in the distance and you
> > > > > > > have an isntalled base. With virtual concatenation
> > > > > > > it is not a problem to
> > > > > > > transport a 160 Gbit/s service (if such a kind of
> > > > > > > service is needed in any
> > > > > > > case) over 4x40G or 16x10G.
> > > > > > >           > > Note that arbitary concatenation was diffcult
> > > > > > > to
> > > > > > > implement with the chip technology available some
> > > > > > > years ago when the
> > > > > > > processing was often done in parallel on several
> > > > > > > chips. Todays single chip
> > > > > > > solutions allowed to introduce arbitary
> > > > > > > concatenation. For the size of the
> > > > > > > alignment buffer for virtual concatenation it is
> > > > > > > also only a question of the
> > > > > > > size of available memory chips which will increase
> > > > > > > over time.
> > > > > > >           > > Sanjay you mentioned that it might be possible
> > > > > > > to use
> > > > > > > just an SW upgrade for an cross-connect in order to
> > > > > > > get arbitary
> > > > > > > concatenation support. I don't think so as arbitary
> > > > > > > concateantion requries
> > > > > > > specific pointer processing which is done in HW.
> > > > > > >           > >
> > > > > > >           > > Regards
> > > > > > >           > >
> > > > > > >           > > Juergen
> > > > > > >           > >
> > > > > > >           > > > -----Original Message-----
> > > > > > >           > > > From: Bernstein, Greg [SMTP:[email-masked]]
> > > > > > >           > > > Sent: Monday, May 14, 2001 5:55 AM
> > > > > > >           > > > To:   'ashritha thirumalai'; Fong, Man Wing;
> > > > > > > Maarten
> > > > > > > Vissers; Heiles Juergen
> > > > > > >           > > > Cc:   [email-masked]
> > > > > > >           > > > Subject:      RE: [IP-Optical] concatenation
> > > > > > > extensions in sonet/sdh
> > > > > > >           > > >
> > > > > > >           > > > Hi Sanjay see comments in line below.
> > > > > > >           > > > Greg B.
> > > > > > >           > > >
> > > > > > >           > > >       Dr. Greg M. Bernstein, Senior
> > > > > > > Scientist, Ciena
> > > > > > >           > > >       New phone: (510) 573-2237
> > > > > > >           > > >
> > > > > > >           > > >
> > > > > > >           > > >               -----Original Message-----
> > > > > > >           > > >               From:   ashritha thirumalai
> > > > > > > [mailto:[email-masked]]
> > > > > > >           > > >               Sent:   Saturday, May 12, 2001
> > > > > > > 9:54 AM
> > > > > > >           > > >               To:     Bernstein, Greg; Fong,
> > > > > > > Man Wing;
> > > > > > > Maarten Vissers;
> > > > > > >           > > > Heiles Juergen
> > > > > > >           > > >               Cc:
> > > > > > > [email-masked]
> > > > > > >           > > >               Subject:        RE:
> > > > > > > [IP-Optical]
> > > > > > > concatenation extensions in
> > > > > > >           > > > sonet/sdh
> > > > > > >           > > >
> > > > > > >           > > >               Dr. Bernstein,
> > > > > > >           > > >
> > > > > > >           > > >               Glad you replied.
> > > > > > >           > > >
> > > > > > >           > > >               A few further questions:
> > > > > > >           > > >
> > > > > > >           > > >               1. how are two different
> > > > > > > vendors
> > > > > > > implementing arb-conc
> > > > > > >           > > >               going to inter-operate? (i.e.
> > > > > > > how are
> > > > > > > bytes in
> > > > > > >           > > >               an arb-concatenated channel
> > > > > > > multiplexed
> > > > > > > into the
> > > > > > >           > > >               rest of Sonet/SDH timeslots?)
> > > > > > >           > > >               > For non-standard sizes this
> > > > > > > needs some
> > > > > > > work. I'm happy to
> > > > > > >           > > > work anyone in this area. Starting with the
> > > > > > > standard
> > > > > > > sizes isn't a problem
> > > > > > >           > > > we just use the already standardized
> > > > > > > mappings.
> > > > > > >           > > >               2. would you be able to list
> > > > > > > some
> > > > > > > vendors that
> > > > > > >           > > >               do (or claim to) support
> > > > > > > arb-concat?
> > > > > > >           > > >               > Ciena's CoreDirector for
> > > > > > > one. I know
> > > > > > > of other vendors but
> > > > > > >           > > > I'm not sure if they've publicly announced.
> > > > > > >           > > >               3. and a repeat question. why
> > > > > > > should one
> > > > > > > go with
> > > > > > >           > > >               arb-concat when virt-cont
> > > > > > > (kludgy as it
> > > > > > > may be)
> > > > > > >           > > >               has been standardized. (in my
> > > > > > > limited
> > > > > > > understanding
> > > > > > >           > > >               of virt-conc, it does avoid
> > > > > > > the
> > > > > > > "re-grooming" that
> > > > > > >           > > >               you alluded to).
> > > > > > >           > > >               > Well virtual concatenation
> > > > > > > can do
> > > > > > > everything but it>
> > > > > > >           > > > requires the edge equipment to be upgraded.
> > > > > > > If folks
> > > > > > > want to preserve their
> > > > > > >           > > > investments around the edge and
> > > > > > > incrementally upgrade
> > > > > > > the core then any line
> > > > > > >           > > > connecting two pieces of equipment
> > > > > > > supporting
> > > > > > > arbitrary concatenation
> > > > > > >           > > > doesn't need to be re-groomed or be used
> > > > > > > inefficiently.  Hence it's a good
> > > > > > >           > > > feature for core equipment, but maybe not so
> > > > > > > hot
> > > > > > > compared to virtual
> > > > > > >           > > > concatenation at the edge.
> > > > > > >           > > >
> > > > > > >           > > >               greatly appreciate a reply.
> > > > > > >           > > >
> > > > > > >           > > >               Thanx,
> > > > > > >           > > >               Sanjay.
> > > > > > >           > > >
> > > > > > >           > > >
> > > > > > >           > > >
> > > > > > >           > > >
> > > > > > >           > > >               --- "Bernstein, Greg"
> > > > > > > <[email-masked]>
> > > > > > > wrote:
> > > > > > >           > > >               > Hi sorry to be out of the
> > > > > > > loop for a
> > > > > > > while.  Man
> > > > > > >           > > >               > Wing's assesment and the
> > > > > > >           > > >               > concerns about upgrades are
> > > > > > > fairly
> > > > > > > correct except:
> > > > > > >           > > >               > (1) With the new generation
> > > > > > > of
> > > > > > > SONET/SDH cross
> > > > > > >           > > >               > connects arbitrary is a
> > > > > > >           > > >               > feature.  I can think of at
> > > > > > > least one
> > > > > > > new and very
> > > > > > >           > > >               > popular switch that has
> > > > > > >           > > >               > this feature.
> > > > > > >           > > >               > (2) I also know of access
> > > > > > > equipment
> > > > > > > vendors that
> > > > > > >           > > >               > offer this feature (but not
> > > > > > >           > > >               > virtual concatenation).
> > > > > > >           > > >               > (3) There is a bit more
> > > > > > > fundamental
> > > > > > > reason behind
> > > > > > >           > > >               > the usefulness of
> > > > > > >           > > >               > arbitrary concatenation.
> > > > > > > Avoiding the
> > > > > > > need to
> > > > > > >           > > >               > "re-groom" the circuits on a
> > > > > > >           > > >               > line (the nasty service
> > > > > > > impacting
> > > > > > > process of
> > > > > > >           > > >               > remapping circuits to time
> > > > > > >           > > >               > slots so that you can add a
> > > > > > > new
> > > > > > > concatenated circuit
> > > > > > >           > > >               > within the standard
> > > > > > >           > > >               > contiguous concatenation
> > > > > > > constraints).
> > > > > > >           > > >               > As to how it got into the
> > > > > > > ODSI
> > > > > > > specification, the
> > > > > > >           > > >               > answer is fairly simple,
> > > > > > >           > > >               > folks (including myself)
> > > > > > > asked for it
> > > > > > > to be
> > > > > > >           > > >               > included, just like in the
> > > > > > > GMPLS
> > > > > > >           > > >               > specification.  I haven't
> > > > > > > found a
> > > > > > > customer out there
> > > > > > >           > > >               > that likes to re-groom
> > > > > > >           > > >               > traffic (or the bandwidth
> > > > > > > inefficiency
> > > > > > > from not
> > > > > > >           > > >               > regrooming).
> > > > > > >           > > >               >
> > > > > > >           > > >               > Greg B.
> > > > > > >           > > >               >
> > > > > > > ***********************************
> > > > > > >           > > >               > Dr. Greg M. Bernstein
> > > > > > >           > > >               > Senior Scientist, Ciena
> > > > > > > Corporation
> > > > > > >           > > >               >
> > > > > > >           > > >               > -----Original Message-----
> > > > > > >           > > >               > From: ashritha thirumalai
> > > > > > >           > > >               > [mailto:[email-masked]]
> > > > > > >           > > >               > Sent: Friday, May 11, 2001
> > > > > > > 1:50 PM
> > > > > > >           > > >               > To: Fong, Man Wing; Maarten
> > > > > > > Vissers;
> > > > > > > Heiles Juergen
> > > > > > >           > > >               > Cc:
> > > > > > > [email-masked]
> > > > > > >           > > >               > Subject: RE: [IP-Optical]
> > > > > > > concatenation extensions
> > > > > > >           > > >               > in sonet/sdh
> > > > > > >           > > >               >
> > > > > > >           > > >               >
> > > > > > >           > > >               > Well, arb-conct is most
> > > > > > > really useful
> > > > > > > for data
> > > > > > >           > > >               > (i.e. Packet-Over-Sonet).
> > > > > > > i.e. one can
> > > > > > > provide
> > > > > > >           > > >               > an STS19c or so for a 1GbE
> > > > > > > pipe (as
> > > > > > > opposed to
> > > > > > >           > > >               > an STS48c as is currently
> > > > > > > being done).
> > > > > > > This
> > > > > > >           > > >               > goal is same as that of
> > > > > > > virt-conc.
> > > > > > >           > > >               >
> > > > > > >           > > >               > I am not really sure how an
> > > > > > > interconnection will
> > > > > > >           > > >               > be problematic with a DACS?
> > > > > > > Could you
> > > > > > >

Delivery-date: Thu, 17 May 2001 05:46:11 -0700
Date: Thu, 17 May 2001 08:38:02 -0400
From: Zhi-Wei Lin <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ASTN Layer Network Architecture

Hi Tammy, Maarten,

I have fundamental questions about some of the capabilities you've
discussed. For example, you mentioned that a connection should be able
to move from control plane to management plane. 

What would trigger such a move?

And in the case that such move is possible, and assuming a connection is
initially set up as a switched connection (SC), then move to the
management plane, who would be responsible for tearing it down,
monitoring it, modifying it, protecting it?

Also, if a connection can move into the management plane, do we then
need to define all these maintenance capabilities for the control plane?
Maybe a subset but not the entire list?

How likely is it for a network to have control plane but no management
plane?

Would these capabilities considered as part of a link management agent?

Thanks!

Zhi

[email-masked] wrote:
> 
> Maarten,
> See my replies to your comments below.
> Tammy
> 
> -----Original Message-----
> From: mvissers [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2001 09:54
> To: Tammy.Ferris
> Cc: tsg13q10; tsg15q12; tsg15q14; ccamp; t1x15; mvissers
> Subject: Re: ASTN Layer Network Architecture
> 
> > 1) You said Network Engineering does:
> > ***
> > Monitored are how much of the available links are utilized. After
> > reaching a threshold (which could be % utilization & rate of change of
> > utilization & possibly also # of failed connection attempts), a
> request
> > to the server LNCP is made for new trails. Network engineering should
> > also monitor the bandwidth demand from a source/destination
> > relationship, in order to identify the traffic patterns in the
> network.
> > Where necessary, a layer network's architecture can be optimised by
> > e.g. adding direct links between two heavily interconnected nodes.
> > Decisions are taken based on policies set by the network operator.
> > It is also worth being able to calculate the number of current open
> > connections and the maximum number of open connections allowed (due to
> > limits in either capacity or connection identifiers). To do network
> > engineering you need to know something about the average holding time
> > of the connection and the call request rate
> > ***
> > But I currently see these as traffic engineering functions.
> >
> > You said Traffic Engineering does:
> > ***
> > - creates connections in the LNCP interconnecting the layer network
> > links via matrix connections in the fabrics
> > ****
> > But I currently see these as network engineering functions.
> 
> It seems we have opposite understandings here.
> "Network engineering" for me relates to engineering the (layer) network,
> i.e. making sure all necessary resources are available. Resources that
> can be managed by the (automatic) network engineering process are the
> links of the layer network.
> 
> "Traffic engineering" on the other hand relates to engineering the
> traffic flows, i.e. making sure that the network is utilised to the
> highest degree possible, to maximize throughput (increases customer
> satisfaction) and profit (increases operator satisfaction).
> 
> It seems strange for me, to specify the opposite "network engineering
> engineers the traffic flows" and "traffic engineering engineers the
> network"...
> 
> ***TLF reply
> I agree with the comments you just made here.  I currently don't see
> that the text in your CD reflects what you have just said.  I think it
> is a traffic engineering function to know average hold times and
> connection request rates, do traffic estimates, and then monitor actual
> traffic. Traffic engineering collects capacity and usage data and
> improves upon previous traffic estimates and requests for capacity in
> the next round...
> *****
> No further meaning is tried to
> be reflected by the size of the boxes (but we may start a contest,
> predict the percentages of the 3 connection types in e.g. 2007 and bury
> it under a tree in Turin... :-)  ).
> ***TLF reply
> I will bring my estimates to Turin :)...
> *****
> >
> > 3) I think the answer to the question in figure 4 is yes.  I would
> > expect that as traffic and service requirements change over time,
> > network resources will move between the management and control plane
> > control.
> 
> OK. Consequential question is now if this is a feature that belongs
> already to the first phase of ASON, or to a later phase?
> ***TLF reply
> I think this is a core capability and belongs to the first phase.
> *****
> >
> > 4) You have identified a pamLockedLinkCapacity.  I would like you to
> > consider extending the definition to be pamMaintenanceLinkCapacity so
> > that it will include all Links that are disabled as well as locked and
> > possibly those under test.
> 
> Perhaps you can take the lead here and create a complete
> definition...
> ***TLF reply
> I will see if I have time to put together a contribution on this for
> Turin.
> *****
> As far as I can see we have the
> - "administrative state" (7.1.3/X.731) with its states "unlocked",
> "shutting down" and "locked"
> - "operational state" (7.1.1/X.731) with its states "disabled" and
> "enabled" ==> is this operational state implied when you referred to
> "link (connection?)s that are disabled"?
> ***TLF reply
> yes
> *****
> - "usage state" (7.1.2/X.731) with its states "idle", "active" and
> "busy" ==> isn't this more extensively represented by the four "pamXXX"
> parameters in G.853.8? I.e. can we ignore this state?
> 
> ***TLF reply
> We can ignore the usage state in terms of maintenance capacity.  Other
> attributes to consider relating to maintenance capacity are
> "availability status" and "control status" (for consideration of
> degraded resources and resources under test).  And if we want to strech
> it even further there is another attribute that can be used to indicate
> that we don't know the status of the resource (e.g. cannot communicate
> to resource so currently state is unknown).
> *****
> 
> Is pamMaintenanceLinkCapacity the best term representing all
> applications as well as its usage in the traffic engineering process?
> The pamMaintenanceLinkCapacity represents the number of link connections
> which are currently not accessible by the routing process within traffic
> engineering.
> ***TLF reply
> In some of my past experiences this has been useful for planning and
> monitoring purposes to know how much of the network is typically
> undergoing maintenance and what the fluctuation patterns are relating
> to maintenance activity, etc.  Further, it is useful for traffic
> engineering and network engineering purpose to know how much planned
> capacity is expected to be under maintenance during normal operations.
> 
> It would be important for routing engines to know that certain
> resources were not available for maintenance but don't really need to
> know what type of maintenance is being done (e.g. new installation,
> repair, waiting for circuit to be torn down, reconfiguration, etc.).
> *****
> 
> We need to define the rules for pamMaintenanceLinkCapacity (or other
> term); i.e. when is its value increased, decreased and which other
> pamXXX values are then consequentially decreased/increased.
> 
> Up to now:
>         pamMaximumLinkCapacity =        pamPotentialLinkCapacity +
>                                         pamProvisionedLinkCapacity +
>                                         pamAvailableLinkCapacity
> 
> Will pamMaintenanceLinkCapacity be just an extra term in this
> expression? E.g.
>         pamMaximumLinkCapacity =        pamPotentialLinkCapacity +
>                                         pamProvisionedLinkCapacity +
>                                         pamAvailableLinkCapacity +
>                                         pamMaintenanceLinkCapacity
> ***TLF reply
> I am not sure about this. Isn't pamAvailableLinkCapacity +
> pamMaintenanceLinkCapacity = pamProvisionedLinkCapacity? Or maybe
> pamAvailableLinkCapacity + pamMaintenanceLinkCapacity + ?? =
> pamProvisionedLinkCapacity?
> 
> It seems to me like pamAvailableLinkCapacity represents both usage and
> capacity information (which is a bit confusing to me). Are you
> intending to use pamAvailableLinkCapacity to represent the total
> dynamic capacity available to the control plane or the capacity in the
> control plane that has not yet be assigned to connections under the
> control of the control plane?  It looked, from your definition that you
> may have meant the later, but then where are you factoring in the
> former in this equation?
> *****
> 
> If the above will be the case, how would we address the "shutting down"
> situation; if there are e.g. 5 link connections in shutting down state,
> then they are still ProvisionedLinkCapacity and at the same time also
> MaintenanceLinkCapacity... most likely we can ignore this detail and
> consider that these e.g. 5 link connections are not longer part of
> ProvisionedLinkCapacity.
> ***TLF reply
> I think that the transition from unlocked to shutting down does not
> change the capacity category for the resource.  I think the transition
> from shutting down to locked is the trigger to put into maintenance
> capacity.
> *****
> 
> What contributes to pamMaintenanceLinkCapacity? E.g. number of link
> connections in admin states locked and shutting down, number of link
> connections in operational state disabled, ... other?
> ***TLF reply
> Admin state, operational state,... + other considerations include
> (non-preemptible?) test connections?, degraded connections?
> connections in unknown state??
> *****
> 
> The operational state "disabled" represents the number of link
> connections that are "DOWN" (i.e. failed), we do not have to bother with
> additional parameters indicting that a particular link has e.g. lost 90%
> of its capacity to the a network failure... that sounds nice...
> ***TLF reply
> Maarten, I am not sure what you mean by this last comment.
> *****
> 
> >
> > 5) In the case of the SPC, where there is sharing of provisioning
> > between the control plane and the management plane, which one is
> > responsible for verification of connectivity and clean-up from failed
> > set-up and release operations?  I think somewhere we need to have a
> > discussion of this interaction.
> 
> The control plane is responsible. The management plane has handed all
> info necessary to the control plane; see also as a first example annex
> E. Also when the SPC is released, the managmeent plane initiates the
> release, but the control plane is responsible for correct release.
> ***TLF reply
> Okay.
> *****
> 
> >
> > 6) I was thinking that it might be nice to be able to set up a primary
> > route in the management plane (e.g. PC) and a protection route in the
> > control plane (e.g. SPC).  Currently this seems to present
> coordination
> > problems. Is this something that would be worth further investigation?
> 
> I think this is very problematic. Protection requires route diversity,
> and if you use two different instances (MP, CP) for the two routes, I
> don't see how route diversity can be obtained.
> ***TLF reply
> Consider the following hypotheticals: there exists a management plane
> instance that is not capable or calculating a diverse route and there
> is a control plane instance that is not capable of pre-provisioning (by
> this I mean creating a connection in the database for the transmission
> plane even if the transmission resources do not yet exist that will
> become operational once resources become available to support the
> connection).  This management plane and control plane need to interface
> to one another.
> 
> Now, given the above, assume that the management plane has provided a
> pc for a given user and with no protection route because at the time
> the user did not want one.  Then subsequently, the user asks for the
> addition of a diverse route protection for the existing connection.  It
> would seem natural that one would want to make use of the intelligence
> of the control plane in determining diverse routes.
> 
> Or, maybe another scenario... The user has requested a connection that
> requires network build-out to support.  To reserve the resource, the
> connection is pre-provisioned in the management plane (note cannot be
> done in the control plane in this scenario as the control plane does
> not support pre-provisioning according to initial assumptions).  This
> connection is to be protected by an m:n protection group where the
> protection connections have been configured using the control plane.
> *****
> 
> >
> > 7) It seems to me that the UNI brings up the subject of Service
> > management which you have not addressed in this contribution.  This is
> > not to reflect negatively on the contribution as you have covered
> quite
> > a lot of material with this contribution.  I was just wondering what
> > your thoughts were about this going forward.
> 
> I haven't arrived at this yet... I have had some discussions with some
> of my colleagues on billing principles (use of performance monitoring
> information); i.e. use of tandem connection monitoring or of
> differential PM (case no TCM is available)...
> 
> Can you present some more of your thoughts behind service management...
> might be helpful as we move forward to have a first reference that we
> can consider at each step.
> ***TLF reply
> There are a lot of facets to this which I cannot adequately cover here,
> but for now.... here are some random thoughts to trigger much more work
> later.
> 
> Some service management functions include:
> Credit Checks
> Service Order Entry
> Service Order Tracking
> Customer Trouble Tickets
> Assignment of service to network resources (crosses multiple layers)
> Reservation systems
> Interace to Billing functions (e.g. billing profile assignment)
> Interface to Network Management functions (e.g.  Network fault
> correlation to affect on service, inventory/service discovery( ;) ?)
> 
> This is to name a few... where does the UNI fit into all of this?
> 
> *****
> 
> >
> > Tammy
> 
> Regards,
> 
> Maarten

Delivery-date: Thu, 17 May 2001 04:50:37 -0700
Date: Thu, 17 May 2001 13:46:50 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: Maarten Vissers <[email-masked]>
CC: Michael Waldo <[email-masked]>, "Bernstein, Greg" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

This is a multi-part message in MIME format.
--------------F906E79E765EDB1E11698AE4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear Maarten et all,

For "arbitrary contiguous concatenation" you stated (and of course)
i agree it has been removed but the question is: what about existing
equipments it is not because it has been removed from recommendation
that products disappear - can someone confirm the use of arbitrary
contiguous concatenation ? - there is also a difference between "what
the ideal situation should be and what the situation is today in 
SDH/Sonet networks"  

=> ... so i don't really think it is a big issue and the following 
alternative can be used to determine what can be done:
- either we strictly comply to "last versions" of G.707 / T1.105
in that case "arbitrary contiguous concatenation" must be removed
- or we do not strictly comply today then the "arbitrary concatenation"
has to be considered in addition to "arbitrary contiguous 
concatenation" - in that case a submission to the ITU-T/T1 should be
ideally proposed in order to "harmonize" the specifications 
- or we stay as defined today making the assumption that "arbitrary
contiguous concatenation" was included so that some equipments might
still support it.

Any other possibility ?

Regards,
Dimitri.

Maarten Vissers wrote:
> 
> Waldo,
> 
> I am copying an email conversation ongoing in the IP-optical mailing
> list on arbitrary concatenation. Hope this provides the input you are
> looking for.
> 
> Bottom line is that neither arbitrary contiguous concatenation nor
> arbitrary concatenation is part of the SONET/SDH standards. It is a
> vendor proprietary extension of these SONET/SDH standards, for which it
> is in my (and some other peoples) view highly unlikely that it will be
> included in the SONET/SDH standards.
> 
> As you indicate with virtual concatenation being the international
> standard and the direction in the industry today, arbitrary
> concatenation doesn't add anything to the transport network; contrary,
> it would cause interworking problems.
> 
> But arbitrary contiguous concatenation wouldn't add anything either, and
> compared to arbitrary concatenation it would still have the bandwidth
> fragmentation problem that standard contiguous concatenation is having.
> I.e. arbitrary contiguous concatenation is worse.
> 
> All,
> 
> The GMPLS SONET/SDH extension document is thus defining a control plane
> which supports capabilities in the transport plane that are not
> supported by the international standards for this transport plane.
> Personally, I find this very incorrect. IETF has no mandate to change
> the SONET/SDH standards. A control plane for the transport network
> should follow the transport network standards, not define its own
> transport network.
> 
> Regards,
> 
> Maarten
> 
> ---------------
> 
> Maarten Vissers wrote:
> >
> > Greg, Anup, Sanjay,
> >
> > To my recollection, the SONET/SDH definition is performed in T1X1.5 and
> > ITU-T SG15. Last year new revisions of T1.105 and G.707 were approved,
> > in which the "arbitrary contiguous concatenation" has been removed. Such
> > step isn't made just for fun.
> >
> > If you believe the removal of "arbitrary contiguous concatenation" from
> > these standards was a mistake, please submit a contribution to T1X1.5
> > and ITU-T Q.11/15 with a proposal to re-introduce it. At the same time
> > you can then also request to introduce "arbitrary concatenation" and
> > propose mappings of client signals into these arbitrary (contiguous)
> > concatenated signals. However, as indicated by Mark, Juergen and myself,
> > I doubt if you find support for such extension of SONET and SDH.
> >
> > For the moment, SONET/SDH networks compliant with T1.105 and G.707
> > standards can forward "contiguous concatenated" VC-4-Xc (X=4,16,64) and
> > STS-3c/12c/48c/192c signals and "virtual concatenated" VC-n-Xv (n=3,4),
> > STS-1, STS-3c-Xc (X=1..256) and VC-n (n=11,12), VT-1.5-Xv (X=1..64)
> > signals, not the "arbitrary concatenated" signals.
> > Arbitrary concatenation is a proprietary extension of SONET/SDH, for
> > which there is no interworking with standard SONET/SDH networks.
> >
> > Virtual concatenation is THE international standardised direction, for
> > which a vendor and operator may expect to see seemless interworking in
> > the SONET/SDH network.
> >
> > Virtual concatenation got very popular due to the:
> > - pricing of Ethernet ports on routers (compared to pricing of
> > STM-N/OC-N ports on routers),
> > - absence of channelized STM-N/OC-N interface ports on routers.
> >
> > As a result the transport network was forced to accept Ethernet physical
> > interfaces, in additon to the traditional SONET/SDH and PDH interfaces.
> > Transport networking engineers very well understand the desire of a
> > customer to pay only for the bandwidth needed, and consequential within
> > the constraints of the SONET/SDH transport network a solution was
> > developed to meet the needs of the customer and the needs of the
> > operator. This is virtual concatenation with GFP as encapsulation
> > method.
> >
> > Virtual concatenation allows to separate the physical and logical
> > aspects of Ethernet signals, like such is common practice for any other
> > SDH/SONET signal. I.e. the (10M, 100M, 1G) Ethernet PHY signal is
> > terminated, the ethernet idle packets are dropped and the packets with
> > information inside of it are forwarded in a transport pipe sized to the
> > customers need.
> > The additional complexity is the introduction of a (skinny) ehternet
> > layer on top of the SDH/SONET layers, as at a minimum some monitoring is
> > to be performed at the ethernet level.
> >
> > Of course, it would be more economical if the transport network didn't
> > have to do this job. I.e. routers should use STM-N/OC-N interface ports
> > supporting virtual concatenated VC-n/STS/VT signals. The transport
> > network would n't have to deal then with its client signals, and instead
> > of ethernet in the virtual concatenated signals, any other data protocol
> > could be used by the routers (e.g. IP/PPP/GFP).
> >
> > But, while having to do this ethernet processing, extensions are
> > becoming economical in the access transport networks; i.e. having
> > ethernet bridging/switching present, it can be used to groom ethernet
> > traffic to further optimise and thus cost reduce ethernet packet
> > transport. It is now possible to offer sub-VC-n/STS/VT ethernet
> > transport pipes (in addition to the multi-VC-n/STS/VT ) through the
> > SDH/SONET access networks.
> >
> > Regards,
> >
> > Maarten
> >
> > Anup Tirumala wrote:
> > >
> > > If routers can routinely fill TDM pipes fully, why are we even talking
> > > virtual concatenation?
> > >
> > > Arbitrary (or even Virtual) concatenation has the
> > > best bang for buck with packets sharing bandwidth
> > > with TDM. (i.e. in a converged network).
> > >
> > > Indeed, a business case does exist for arbitrary concatenation.
> > > Ask Cyras (now Ciena;)
> > >
> > > You must look at this in conjunction with Network Processors
> > > and statistical multiplexing.
> > >
> > > A customer need only pay for as much bandwidth as he/she needs,
> > > while the remainder can be used for TDM channels.
> > >
> > > We believe the case for arbitrary concatenation does exist:
> > >
> > > 1. scales better with technology.
> > > 2. no massive buffering requirements. (note that virtual concatenation
> > >    does not "guarantee" hit-less operation. with buffering, one can limit
> > >    the hit that's all).
> > > 3. augments native contiguous concatenation. i.e. contiguous concatenation
> > >    becomes a degenerate case of arbitrary concatenation.
> > > 4. A customer explicity asked for it. :)
> > >
> > > I think there is merit to an effort at interoperability.
> > >
> > > -anup
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > Sent: Tuesday, May 15, 2001 12:36 PM
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]
> > > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > > >
> > > >
> > > > From my perspective, all necessary applications can be met by
> > > > contiguous
> > > > and virtual concatenation.  Adding arbitrary concatenation simply
> > > > increases the number of spares to maintain, the number of
> > > > attributes to
> > > > test for interoperability, and the potential complexity to
> > > > port cards.
> > > > The improved bandwidth efficiency you are going to claim
> > > > won't outweigh
> > > > the problems I see as a result.  Unless you can show a significant
> > > > business driver for this, I would recommend not wasting your
> > > > time trying
> > > > to standardize it.  The trend is to maintain variable size
> > > > connections
> > > > using packets anyway.  Why are we talking about doing this
> > > > with TDM?  I
> > > > find it most interesting that this IETF group is discussing variable
> > > > size TDM pipes, when routers typically can fill a TDM pipe at
> > > > the line
> > > > rate.
> > > >
> > > > Mark Loyd Jones
> > > > Sprint
> > > > Technology Planning & Integration
> > > > 913-534-5247
> > > > [email-masked]
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: chickoo66 [mailto:[email-masked]]
> > > > > Sent: Tuesday, May 15, 2001 1:47 PM
> > > > > To: GregB; mvissers; ip-optical
> > > > > Cc: chickoo66
> > > > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > > > >
> > > > >
> > > > > I could not agree more.
> > > > > Arb-Concatenation, being a logical (and graceful)
> > > > > extension of standard contiguous concatenation,
> > > > > can easily co-exist with virtual.
> > > > > Imagine channels such as 2c,5c,6c,7c... 767c :)
> > > > > However, we need to be able to interoperate
> > > > > with outside-vendor equipments, with regards
> > > > > to the multiplexing scheme.
> > > > > Dr.Berstein/other, do you know of any such
> > > > > interoperating effort on-going?
> > > > > Would any one be interested in interoperability
> > > > > issues pertaining to arb-concat?
> > > > > I emphasize: arb-conc is complementary to virt-concat.
> > > > > Comments?
> > > > > Sanjay
> > > > >
> > > > >
> > > > >
> > > > > --- "Bernstein, Greg" <[email-masked]> wrote:
> > > > > > Folks, please note that Arbitrary concatenation is
> > > > > > not in any of the ITU or
> > > > > > ANSI standards as Maarten points out below.
> > > > > > Maarten my understanding is that GFP can be used
> > > > > > with either standard
> > > > > > contiguous concatenation or virtual concatenation.
> > > > > >
> > > > > > For those interested in arbitrary concatenation for
> > > > > > the standard sizes,
> > > > > > e.g., STS-3c, STS-12c, one can just use the payload
> > > > > > mappings from standard
> > > > > > contiguous concatenation.  A network supporting
> > > > > > arbitrary concatenation can
> > > > > > transport these efficiently with no re-grooming.
> > > > > >
> > > > > > Note that I think SDH/SONET networks can make use of
> > > > > > both virtual and
> > > > > > arbitrary concatenation.
> > > > > > Greg B.
> > > > > >
> > > > > >   Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > > > > >   New phone: (510) 573-2237
> > > > > >
> > > > > >
> > > > > >           -----Original Message-----
> > > > > >           From:   Maarten Vissers [mailto:[email-masked]]
> > > > > >           Sent:   Tuesday, May 15, 2001 1:06 AM
> > > > > >           To:     Bernstein, Greg; 'ashritha thirumalai';
> > > > > > [email-masked]
> > > > > >           Subject:        Re: [IP-Optical] concatenation
> > > > > extensions
> > > > > > in
> > > > > > sonet/sdh
> > > > > >
> > > > > >            << File: Card for Maarten Vissers >> Greg,
> > > > > >
> > > > > >           The transport of ethernet signals via SDH/SONET
> > > > > > networks is
> > > > > > being
> > > > > >           defined in T1 and ITU-T to use virtual
> > > > > > concatenation and GFP
> > > > > > for
> > > > > >           encapsulation, not arbitrary concatenation.
> > > > > >
> > > > > >           The transport of SAN signals (ESCON, FC, FICON)
> > > > > > via
> > > > > > SDH/SONET networks
> > > > > >           is being defined in T1 and ITU-T to use virtual
> > > > > > concatenation and GFP
> > > > > >           for encapsulation, not arbitrary concatenation.
> > > > > >
> > > > > >           The transport of ATM signals via SDH/SONET
> > > > > > networks is
> > > > > > defined in T1 and
> > > > > >           ITU-T to use VC-3/STS-1, VC-4/STS-3c,
> > > > > > VC-4-4c/STS-12c,
> > > > > > VC-4-16c/STS-48c,
> > > > > >           VC-4-64c/STS-192c, VC-4-256c/STS-768c and
> > > > > > STS-1-Xv,
> > > > > > VC-4-Xv/STS-3c-Xv.
> > > > > >
> > > > > >           For the case interworking between subnetworks of
> > > > > > different
> > > > > > vendors and
> > > > > >           networks of different operators is required, the
> > > > > > above
> > > > > > signals and
> > > > > >           mappings are to be used.
> > > > > >
> > > > > >           For the case interworking is not required, any
> > > > > > proprietary
> > > > > >           implementation (e.g. arbitrary concatenation) can
> > > > > > be used.
> > > > > >
> > > > > >           Regards,
> > > > > >
> > > > > >           Maarten
> > > > > >
> > > > > >
> > > > > >           Maarten Vissers wrote:
> > > > > >           >
> > > > > >           > Greg, Sanjay,
> > > > > >           >
> > > > > >           > In additon to Juergen's comment, I would like to
> > > > > > point out
> > > > > > that VC-4-2c,
> > > > > >           > VC-4-3c, VC-4-5c, etc are not longer part of the
> > > > > > SDH
> > > > > > hierarchy (G.707
> > > > > >           > 10/2000), and I doubt if the ITU-T community
> > > > > > would like to
> > > > > > re-introduce
> > > > > >           > these signal types given all the hassle the
> > > > > > introduction
> > > > > > of VC-4-4c
> > > > > >           > (with ATM payload) did cause in the past.
> > > > > >           >
> > > > > >           > And as Juergen indicated, real arbitrary
> > > > > > concatenation
> > > > > > would require the
> > > > > >           > mapping of a VC-4-Xc signal in any set of X AU-4
> > > > > > timeslots. As long as
> > > > > >           > you need still a series of contiguous timeslots
> > > > > > (i.e.
> > > > > > arbitrary
> > > > > >           > contiguous concatenation), bandwidth
> > > > > > defragmenation (or
> > > > > > re-grooming) is
> > > > > >           > required once every ...
> > > > > >           >
> > > > > >           > I.e. arbitrary contiguous concatenation (ACC)
> > > > > >           > - still has the same fragmentation issue that is
> > > > > > also
> > > > > > present in today's
> > > > > >           > contiguous concatenation; it is less restrictive
> > > > > > from a
> > > > > > theoretical
> > > > > >           > perspective, but Murphy's law will be
> > > > > > applicable, and the
> > > > > > fragmentation
> > > > > >           > will be such that there is no contiguous set of
> > > > > > AU4
> > > > > > timeslots free
> > > > > >           > normally - i.e. from the distance, there is no
> > > > > > benifit at
> > > > > > all from the
> > > > > >           > operational perspective, perhaps even only a
> > > > > > disadvantage
> > > > > > (more complex
> > > > > >           > provisioning due to more flexibility)
> > > > > >           > - ACC signals can not be routed via most
> > > > > > SDH/SONET
> > > > > > networks.
> > > > > >           >
> > > > > >           > Within the OTN definition work ongoing, the ODUk
> > > > > > multiplexing is
> > > > > >           > intended to be specified with true arbitrary
> > > > > > concatenation. Refer to
> > > > > >           > SP15 of the G.709 living list for the moment.
> > > > > > Later this
> > > > > > week a first
> > > > > >           > ODUk multiplexing text proposal will be issued
> > > > > > towards
> > > > > > ITU-T Q.11/15.
> > > > > >           >
> > > > > >           > Regards,
> > > > > >           >
> > > > > >           > Maarten
> > > > > >           >
> > > > > >           > Heiles Juergen wrote:
> > > > > >           > >
> > > > > >           > > Greg, Sanjay,
> > > > > >           > >
> > > > > >           > > if you build up a new network, if you don't
> > > > > > have to care
> > > > > > about an installed base and if you further can
> > > > > > accept to be restricted to a
> > > > > > single vendor (E.g. signle ring network) arbitary
> > > > > > concatenation could be
> > > > > > fine.
> > > > > >           > > Concerning the upgrade, virtual concatenation
> > > > > > would
> > > > > > often require only a new tributary interface card
> > > > > > (depending on your system
> > > > > > design), not an upgrade of the whole network
> > > > > > element. As you have to install
> > > > > > this new interface card due to the new service (e.g.
> > > > > > 100M/1G Ethernet)in any
> > > > > > case it is not an additional investment.
> > > > > >           > > Greg you mentioned re-grooming as far as I
> > > > > > understand
> > > > > > arbitary (contiguous) concatenation you still need X
> > > > > > contiguous VCs/SPEs.
> > > > > > Only the number X and the starting time slot has no
> > > > > > limitations as it is the
> > > > > > case for standard contiguous cocnatenation. So you
> > > > > > still ahve to do
> > > > > > re-grooming if for example time slots 1, 5 and 6 are
> > > > > > available in an STM-16
> > > > > > signal as these time slots are not contgiguous.
> > > > > > Arbitary concatenation has
> > > > > > less restrictions compared to standard contiguous
> > > > > > concatenation, but still
> > > > > > has restrictions.
> > > > > >           > > Sanjay, you talked about OC3072. We might have
> > > > > > 160
> > > > > > Gbit/s in the future in some parts of the network,
> > > > > > but others are still
> > > > > > running with lower line speeds (e.g. long distance
> > > > > > systems, trans oceanic
> > > > > > systems) as the higher bit rate imposes limitations
> > > > > > in the distance and you
> > > > > > have an isntalled base. With virtual concatenation
> > > > > > it is not a problem to
> > > > > > transport a 160 Gbit/s service (if such a kind of
> > > > > > service is needed in any
> > > > > > case) over 4x40G or 16x10G.
> > > > > >           > > Note that arbitary concatenation was diffcult
> > > > > > to
> > > > > > implement with the chip technology available some
> > > > > > years ago when the
> > > > > > processing was often done in parallel on several
> > > > > > chips. Todays single chip
> > > > > > solutions allowed to introduce arbitary
> > > > > > concatenation. For the size of the
> > > > > > alignment buffer for virtual concatenation it is
> > > > > > also only a question of the
> > > > > > size of available memory chips which will increase
> > > > > > over time.
> > > > > >           > > Sanjay you mentioned that it might be possible
> > > > > > to use
> > > > > > just an SW upgrade for an cross-connect in order to
> > > > > > get arbitary
> > > > > > concatenation support. I don't think so as arbitary
> > > > > > concateantion requries
> > > > > > specific pointer processing which is done in HW.
> > > > > >           > >
> > > > > >           > > Regards
> > > > > >           > >
> > > > > >           > > Juergen
> > > > > >           > >
> > > > > >           > > > -----Original Message-----
> > > > > >           > > > From: Bernstein, Greg [SMTP:[email-masked]]
> > > > > >           > > > Sent: Monday, May 14, 2001 5:55 AM
> > > > > >           > > > To:   'ashritha thirumalai'; Fong, Man Wing;
> > > > > > Maarten
> > > > > > Vissers; Heiles Juergen
> > > > > >           > > > Cc:   [email-masked]
> > > > > >           > > > Subject:      RE: [IP-Optical] concatenation
> > > > > > extensions in sonet/sdh
> > > > > >           > > >
> > > > > >           > > > Hi Sanjay see comments in line below.
> > > > > >           > > > Greg B.
> > > > > >           > > >
> > > > > >           > > >       Dr. Greg M. Bernstein, Senior
> > > > > > Scientist, Ciena
> > > > > >           > > >       New phone: (510) 573-2237
> > > > > >           > > >
> > > > > >           > > >
> > > > > >           > > >               -----Original Message-----
> > > > > >           > > >               From:   ashritha thirumalai
> > > > > > [mailto:[email-masked]]
> > > > > >           > > >               Sent:   Saturday, May 12, 2001
> > > > > > 9:54 AM
> > > > > >           > > >               To:     Bernstein, Greg; Fong,
> > > > > > Man Wing;
> > > > > > Maarten Vissers;
> > > > > >           > > > Heiles Juergen
> > > > > >           > > >               Cc:
> > > > > > [email-masked]
> > > > > >           > > >               Subject:        RE:
> > > > > > [IP-Optical]
> > > > > > concatenation extensions in
> > > > > >           > > > sonet/sdh
> > > > > >           > > >
> > > > > >           > > >               Dr. Bernstein,
> > > > > >           > > >
> > > > > >           > > >               Glad you replied.
> > > > > >           > > >
> > > > > >           > > >               A few further questions:
> > > > > >           > > >
> > > > > >           > > >               1. how are two different
> > > > > > vendors
> > > > > > implementing arb-conc
> > > > > >           > > >               going to inter-operate? (i.e.
> > > > > > how are
> > > > > > bytes in
> > > > > >           > > >               an arb-concatenated channel
> > > > > > multiplexed
> > > > > > into the
> > > > > >           > > >               rest of Sonet/SDH timeslots?)
> > > > > >           > > >               > For non-standard sizes this
> > > > > > needs some
> > > > > > work. I'm happy to
> > > > > >           > > > work anyone in this area. Starting with the
> > > > > > standard
> > > > > > sizes isn't a problem
> > > > > >           > > > we just use the already standardized
> > > > > > mappings.
> > > > > >           > > >               2. would you be able to list
> > > > > > some
> > > > > > vendors that
> > > > > >           > > >               do (or claim to) support
> > > > > > arb-concat?
> > > > > >           > > >               > Ciena's CoreDirector for
> > > > > > one. I know
> > > > > > of other vendors but
> > > > > >           > > > I'm not sure if they've publicly announced.
> > > > > >           > > >               3. and a repeat question. why
> > > > > > should one
> > > > > > go with
> > > > > >           > > >               arb-concat when virt-cont
> > > > > > (kludgy as it
> > > > > > may be)
> > > > > >           > > >               has been standardized. (in my
> > > > > > limited
> > > > > > understanding
> > > > > >           > > >               of virt-conc, it does avoid
> > > > > > the
> > > > > > "re-grooming" that
> > > > > >           > > >               you alluded to).
> > > > > >           > > >               > Well virtual concatenation
> > > > > > can do
> > > > > > everything but it>
> > > > > >           > > > requires the edge equipment to be upgraded.
> > > > > > If folks
> > > > > > want to preserve their
> > > > > >           > > > investments around the edge and
> > > > > > incrementally upgrade
> > > > > > the core then any line
> > > > > >           > > > connecting two pieces of equipment
> > > > > > supporting
> > > > > > arbitrary concatenation
> > > > > >           > > > doesn't need to be re-groomed or be used
> > > > > > inefficiently.  Hence it's a good
> > > > > >           > > > feature for core equipment, but maybe not so
> > > > > > hot
> > > > > > compared to virtual
> > > > > >           > > > concatenation at the edge.
> > > > > >           > > >
> > > > > >           > > >               greatly appreciate a reply.
> > > > > >           > > >
> > > > > >           > > >               Thanx,
> > > > > >           > > >               Sanjay.
> > > > > >           > > >
> > > > > >           > > >
> > > > > >           > > >
> > > > > >           > > >
> > > > > >           > > >               --- "Bernstein, Greg"
> > > > > > <[email-masked]>
> > > > > > wrote:
> > > > > >           > > >               > Hi sorry to be out of the
> > > > > > loop for a
> > > > > > while.  Man
> > > > > >           > > >               > Wing's assesment and the
> > > > > >           > > >               > concerns about upgrades are
> > > > > > fairly
> > > > > > correct except:
> > > > > >           > > >               > (1) With the new generation
> > > > > > of
> > > > > > SONET/SDH cross
> > > > > >           > > >               > connects arbitrary is a
> > > > > >           > > >               > feature.  I can think of at
> > > > > > least one
> > > > > > new and very
> > > > > >           > > >               > popular switch that has
> > > > > >           > > >               > this feature.
> > > > > >           > > >               > (2) I also know of access
> > > > > > equipment
> > > > > > vendors that
> > > > > >           > > >               > offer this feature (but not
> > > > > >           > > >               > virtual concatenation).
> > > > > >           > > >               > (3) There is a bit more
> > > > > > fundamental
> > > > > > reason behind
> > > > > >           > > >               > the usefulness of
> > > > > >           > > >               > arbitrary concatenation.
> > > > > > Avoiding the
> > > > > > need to
> > > > > >           > > >               > "re-groom" the circuits on a
> > > > > >           > > >               > line (the nasty service
> > > > > > impacting
> > > > > > process of
> > > > > >           > > >               > remapping circuits to time
> > > > > >           > > >               > slots so that you can add a
> > > > > > new
> > > > > > concatenated circuit
> > > > > >           > > >               > within the standard
> > > > > >           > > >               > contiguous concatenation
> > > > > > constraints).
> > > > > >           > > >               > As to how it got into the
> > > > > > ODSI
> > > > > > specification, the
> > > > > >           > > >               > answer is fairly simple,
> > > > > >           > > >               > folks (including myself)
> > > > > > asked for it
> > > > > > to be
> > > > > >           > > >               > included, just like in the
> > > > > > GMPLS
> > > > > >           > > >               > specification.  I haven't
> > > > > > found a
> > > > > > customer out there
> > > > > >           > > >               > that likes to re-groom
> > > > > >           > > >               > traffic (or the bandwidth
> > > > > > inefficiency
> > > > > > from not
> > > > > >           > > >               > regrooming).
> > > > > >           > > >               >
> > > > > >           > > >               > Greg B.
> > > > > >           > > >               >
> > > > > > ***********************************
> > > > > >           > > >               > Dr. Greg M. Bernstein
> > > > > >           > > >               > Senior Scientist, Ciena
> > > > > > Corporation
> > > > > >           > > >               >
> > > > > >           > > >               > -----Original Message-----
> > > > > >           > > >               > From: ashritha thirumalai
> > > > > >           > > >               > [mailto:[email-masked]]
> > > > > >           > > >               > Sent: Friday, May 11, 2001
> > > > > > 1:50 PM
> > > > > >           > > >               > To: Fong, Man Wing; Maarten
> > > > > > Vissers;
> > > > > > Heiles Juergen
> > > > > >           > > >               > Cc:
> > > > > > [email-masked]
> > > > > >           > > >               > Subject: RE: [IP-Optical]
> > > > > > concatenation extensions
> > > > > >           > > >               > in sonet/sdh
> > > > > >           > > >               >
> > > > > >           > > >               >
> > > > > >           > > >               > Well, arb-conct is most
> > > > > > really useful
> > > > > > for data
> > > > > >           > > >               > (i.e. Packet-Over-Sonet).
> > > > > > i.e. one can
> > > > > > provide
> > > > > >           > > >               > an STS19c or so for a 1GbE
> > > > > > pipe (as
> > > > > > opposed to
> > > > > >           > > >               > an STS48c as is currently
> > > > > > being done).
> > > > > > This
> > > > > >           > > >               > goal is same as that of
> > > > > > virt-conc.
> > > > > >           > > >               >
> > > > > >           > > >               > I am not really sure how an
> > > > > > interconnection will
> > > > > >           > > >               > be problematic with a DACS?
> > > > > > Could you
> > > > > > elaborate
> > > > > >           > > >               > kindly?
> > > > > >           > > >               >
> > > > > >           > > >               > Thanx,
> > > > > >           > > >               > Sanjay
> > > > > >           > > >               > --- "Fong, Man Wing"
> > > > > > <[email-masked]>
> > > > > >           > > >               > wrote:
> > > > > >           > > >               > > Hi Sanjay,
> > > > > >           > > >               > >
> > > > > >           > > >               > > Here is my 2 cents worth
> > > > > > of
> > > > > > comments.
> > > > > >           > > >               > >
> > > > > >           > > >               > > 3. arb. conc. as well as
> > > > > > virt. conc.
> > > > > > require
> > > > > >           > > >               > > upgrades
> > > > > >           > > >               > >    at the end points,
> > > > > > since all
> > > > > > systems in a ring
> > > > > >           > > >               > >    will be of the same
> > > > > > vendor
> > > > > > anyway. (i.e. if one
> > > > > >           > > >               > >    system supports arb.
> > > > > > conc. so
> > > > > > will the rest in
> > > > > >           > > >               > >    the ring).
> > > > > >           > > >               > > Not quiet true. There
> > > > > > might be a
> > > > > > problem when
> > > > > >           > > >               > > interconnecting with a
> > > > > > cross
> > > > > >           > > >               > > connect system. For my
> > > > > > understanding, I can't
> > > > > >           > > >               > think
> > > > > >           > > >               > > of any cross connect
> > > > > >           > > >               > > system support arbitrary
> > > > > > concatenation.
> > > > > >           > > >               > >
> > > > > >           > > >               > > Regards,
> > > > > >           > > >               > > Man Wing
> > > > > >           > > >               > >
> > > > > >           > > >               > > -----Original Message-----
> > > > > >           > > >               > > From:       ashritha
> > > > > > thirumalai
> > > > > >           > > >               > >
> > > > > > [mailto:[email-masked]]
> > > > > >           > > >               > > Sent:       Friday, May
> > > > > > 11, 2001
> > > > > > 11:55 AM
> > > > > >           > > >               > > To: Maarten Vissers;
> > > > > > Heiles Juergen
> > > > > >           > > >               > > Cc: 'ashritha thirumalai';
> > > > > >           > > >               > >
> > > > > > [email-masked]
> > > > > >           > > >               > > Subject:    Re:
> > > > > > [IP-Optical]
> > > > > > concatenation extensions
> > > > > >           > > >               > > in sonet/sdh
> > > > > >           > > >               > >
> > > > > >           > > >               > > Thanks Juergen and Maarten
> > > > > > for you
> > > > > > valuable
> > > > > >           > > >               > > feedback.
> > > > > >           > > >               > >
> > > > > >           > > >               > > Here's my dilemma:
> > > > > >           > > >               > >
> > > > > >           > > >               > > 1. arb. concatenation is a
> > > > > > natural
> > > > > > and elegant
> > > > > >           > > >               > >    extension to sonet/sdh
> > > > > > contigous-concatenation.
> > > > > >           > > >               >
> > > > > >           > > >               > >
> > > > > >           > > >               > > 2. arb. concatenation
> > > > > > scales very
> > > > > > well with rate. >
> > > > > >           > > >               > >    imagine the buffering
> > > > > > required
> > > > > > for OC768 or i
> > > > > >           > > >               > >    dare say, OC3072 in a
> > > > > > framer
> > > > > > device supporting
> > > > > >           > > >               > >    virtual concatenation.
> > > > > > (while an
> > > > > > ANSI draft
> > > > > >           > > >               > >    recommends a minimum of
> > > > > > 1 frame's
> > > > > > worth of
> > > > > >           > > >               > >    buffering, this is
> > > > > > hardly
> > > > > > sufficient. most
> > > > > >           > > >               > people
> > > > > >           > > >               > >    want about 16 frames
> > > > > > worth of
> > > > > > buffering).
> > > > > >           > > >               > >
> > > > > >           > > >               > > 3. in a given ring, it is
> > > > > > virtually
> > > > > > unknown to
> > > > > >           > > >               > >    intermix systems from
> > > > > > two
> > > > > > vendors.
> > > > > >           > > >               > >    therefore, a system
> > > > > > (say and ADM)
> > > > > > supporting
> > > > > >           > > >               > >    arb. concatenation can
> > > > > > gracefully
> > > > > > co-exist with
> > > > > >           > > >               > >    its sibling systems on
> > > > > > the same
> > > > > > ring.
> > > > > >           > > >               > >
> > > > > >           > > >               > > 4. now the question is
> > > > > > what happens
> > > > > > at end-points.
> > > > > >           > > >               >
> > > > > >           > > >               > >    well, the end-points
> > > > > > (especially
> > > > > > the receive)
> > > > > >           > > >               > >    will have to support
> > > > > > arb
> > > > > > concatenation.
> > > > > >           > > >               > >    (if there is a cross
> > > > > > connect, it
> > > > > >           > > >               > >    could possibly be
> > > > > > handled by
> > > > > > software alone).
> > > > > >           > > >               > >
> > > > > >           > > >               > >    On the other hand,
> > > > > > virtual
> > > > > > concatenation will
> > > > > >           > > >               > >    need support as well at
> > > > > > the
> > > > > > end-points. i.e.
> > > > > >           > > >               > >    current systems will
> > > > > > need to be
> > > > > > upgraded.
> > > > > >           > > >               > >
> > > > > >           > > >               > > my summary (i hope you
> > > > > > will critique
> > > > > > this):
> > > > > >           > > >               > >
> > > > > >           > > >               > > 1. arb. conc. is a more
> > > > > > elegant
> > > > > > solution.
> > > > > >           > > >               > > 2. arb. conc. scales quite
> > > > > > well with
> > > > > > rate, while
> > > > > >           > > >               > >    vir. conc. gets uglier
> > > > > > and uglier
> > > > > > to implement.
> > > > > >           > > >               >
> > > > > >           > > >               > > 3. arb. conc. as well as
> > > > > > virt. conc.
> > > > > > require
> > > > > >           > > >               > > upgrades
> > > > > >           > > >               > >    at the end points,
> > > > > > since all
> > > > > > systems in a ring
> > > > > >           > > >               > >    will be of the same
> > > > > > vendor
> > > > > > anyway. (i.e. if one
> > > > > >           > > >               > >    system supports arb.
> > > > > > conc. so
> > > > > > will the rest in
> > > > > >           > > >               > >    the ring).
> > > > > >           > > >               > > 4. why is ODSI making a
> > > > > > mention of
> > > > > > arb.
> > > > > >           > > >               > > concatenation
> > > > > >           > > >               > >    in their functional
> > > > > > spec?
> > > > > >           > > >               > >
> > > > > >           > > >               > > Thanx,
> > > > > >           > > >               > > Sanjay.
> > > > > >           > > >               > > --- Maarten Vissers
> > > > > > <[email-masked]> wrote:
> > > > > >           > > >               > > > Sanjay,
> > > > > >           > > >               > > >
> > > > > >           > > >               > > > Arbitrary concatenation
> > > > > > was
> > > > > > present in the very
> > > > > >           > > >               > > > first versions of T.105
> > > > > >           > > >               > > > and G.707 (called G.709
> > > > > > at the
> > > > > > time). It was
> > > > > >           > > >               > never
> > > > > >           > > >               > > > implemented, until
> > > > > >           > > >               > > > ATM people decided
> > > > > > (without
> > > > > > consultation with
> > > > > >           > > >               > > > transport people) to
> > > > > >           > > >               > > > define ATM over
> > > > > > VC-4-4c/STS-12c.
> > > > > > The problems
> > > > > >           > > >               > this
> > > > > >           > > >               > > > has caused initially
> > > > > >           > > >               > > > in the networks was
> > > > > > tremendous;
> > > > > > VC-4-4c/STS-12c
> > > > > >           > > >               > > > couldn't be transported
> > > > > >           > > >               > > > as a tributary signal in
> > > > > > e.g.
> > > > > > STM-16/OC-48
> > > > > >           > > >               > > signals,
> > > > > >           > > >               > > > it could only be
> > > > > >           > > >               > > > transported within an
> > > > > > STM-4/OC-12
> > > > > > directly on
> > > > > >           > > >               > > fiber
> > > > > >           > > >               > > > (very expensive!!).
> > > > > >           > > >               > > > Only when new network
> > > > > > elements
> > > > > > where installed
> > > > > >           > > >               > > > supporting
> > > > > >           > > >               > > > VC-4-4c/STS-12c this
> > > > > > ATM-service
> > > > > > could be
> > > > > >           > > >               > handled
> > > > > >           > > >               > > by
> > > > > >           > > >               > > > the transport
> > > > > >           > > >               > > > networks at normal
> > > > > > costs. To
> > > > > > transport
> > > > > >           > > >               > > > VC-4-4c/STS-12c over the
> > > > > > original
> > > > > >           > > >               > > > SDH networks,
> > > > > > contiguous/virtual
> > > > > > concatenation
> > > > > >           > > >               > > > conversion function has
> > > > > >           > > >               > > > been defined (see
> > > > > > G.707); special
> > > > > > cont/virt conc
> > > > > >           > > >               > > > conversion interface
> > > > > >           > > >               > > > port units have been
> > > > > > designed and
> > > > > > installed.
> > > > > >           > > >               > > >
> > > > > >           > > >               > > > Arbitrary concatenation
> > > > > > has been
> > > > > > taken out in
> > > > > >           > > >               > the
> > > > > >           > > >               > > > latest versions of the
> > > > > >           > > >               > > > two standards for the
> > > > > > reasons
> > > > > > mentioned by
> > > > > >           > > >               > Juergen
> > > > > >           > > >               > > > and indicated above.
> > > > > >           > > >               > > > I would say that most
> > > > > > likely 99%
> > > > > > of the existing
> > > > > >           > > >               > > > SONET/SDH networks do
> > > > > >           > > >               > > > not support arbitrary
> > > > > > concatenation, and there
> > > > > >           > > >               > are
> > > > > >           > > >               > > > no client signals
> > > > > >           > > >               > > > defined that are mapped
> > > > > > into
> > > > > > arbitrary
> > > > > >           > > >               > > concatenated
> > > > > >           > > >               > > > signals. So I would
> > > > > >           > > >               > > > assume that arbitrary
> > > > > > concatenation is a dead
> > > > > >           > > >               > > body,
> > > > > >           > > >               > > > not worth to invest
> > > > > >           > > >               > > > a single penny in.
> > > > > > Virtual
> > > > > > concatenation is the
> > > > > >           > > >               > > > future.
> > > > > >           > > >               > > >
> > > > > >           > > >               > > > Regards,
> > > > > >           > > >               > > >
> > > > > >           > > >               > > > Maarten
> > > > > >           > > >               > > >
> > > > > >           > > >               > > > Heiles Juergen wrote:
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > > Sanjay,
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > > arbitary contiguous
> > > > > > concatenation has to be
> > > > > >           > > >               > > > supported by all network
> > > > > > elements
> > > > > > along the>
> > > > > >           > > >               > path,>
> > > > > >           > > >               > > > while virtual
> > > > > > concatenation needs
> > > > > > only support
> > > > > >           > > >               > at
> > > > > >           > > >               > > > the end systems
> > > > > > terminating
> > > > > > virtual
> > > > > >           > > >               > concatenation
> > > > > >           > > >               > > > and providing access to
> > > > > > the client
> > > > > > signal.
> > > > > >           > > >               > > > > Arbitary contiguous
> > > > > > concatenation is not
> > > > > >           > > >               > > > standardized and support
> > > > > > only by
> > > > > > several
> > > > > >           > > >               > vendors.
> > > > > >           > > >               > > > Exisitng networks don't
> > > > > > support
> > > > > > it. It would
> > > > > >           > > >               > > require
> > > > > >           > > >               > > > a replacement of most
> > > > > > network
> > > > > > elements,
> > > > > >           > > >               > something
> > > > > >           > > >               > > > operators don't want.
> > > > > > With virtual
> > > > > > concatenation
> > > > > >           > > >               > > you
> > > > > >           > > >               > > > can go through exisitng
> > > > > > networks.
> > > > > > Only the end
> > > > > >           > > >               > > > systems that support the
> > > > > > specific
> > > > > > client signal
> > > > > >           > > >               > > have
> > > > > >           > > >               > > > to support virtual
> > > > > > concatenation
> > > > > > also.
> > > > > >           > > >               > > > > Furthermore virtual
> > > > > > concatenation allows to
> > > > > >           > > >               > > > disribute the individual
> > > > > > VCs/STS-SPEs over
> > > > > >           > > >               > several
> > > > > >           > > >               > > > STM/OC signals, which is
> > > > > > not
> > > > > > possible with
> > > > > >           > > >               > > > contiguous
> > > > > > concatenation. An
> > > > > > application for
> > > > > >           > > >               > this
> > > > > >           > > >               > > is
> > > > > >           > > >               > > > the transport of a 10
> > > > > > Gbit/s
> > > > > > paylaod over
> > > > > >           > > >               > 4xOC-48
> > > > > >           > > >               > > in
> > > > > >           > > >               > > > a OC-48 based WDM
> > > > > > system.
> > > > > >           > > >               > > > > The LCAS (Link
> > > > > > Capacity
> > > > > > Adjustment Scheme)
> > > > > >           > > >               > > allows
> > > > > >           > > >               > > > to modify the number of
> > > > > > virtual
> > > > > > concatenated
> > > > > >           > > >               > > signals
> > > > > >           > > >               > > > (and as such the
> > > > > > transport
> > > > > > bandwidth) on the
> > > > > >           > > >               > fly.
> > > > > >           > > >               > > > > In my view virtual
> > > > > > concatenation
> > > > > > has a longer
> > > > > >           > > >               > > > lifetime.
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > > Regards
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > > Juergen
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > > > -----Original
> > > > > > Message-----
> > > > > >           > > >               > > > > > From: ashritha
> > > > > > thirumalai
> > > > > >           > > >               > > >
> > > > > > [SMTP:[email-masked]]
> > > > > >           > > >               > > > > > Sent: Monday, May
> > > > > > 07, 2001
> > > > > > 9:05 PM
> > > > > >           > > >               > > > > > To:
> > > > > > [email-masked]
> > > > > >           > > >               > > > > > Cc:
> > > > > > [email-masked]
> > > > > >           > > >               > > > > > Subject:
> > > > > > [IP-Optical]
> > > > > > concatenation
> > > > > >           > > >               > > > extensions in sonet/sdh
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > All,
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > A newbie question.
> > > > > > (and a
> > > > > > digression from
> > > > > >           > > >               > > > current
> > > > > >           > > >               > > > > > threads)
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > Virtual
> > > > > > concatenation seems to
> > > > > > have been
> > > > > >           > > >               > > > accepted
> > > > > >           > > >               > > > > > as standard
> > > > > > procedure.
> > > > > > Lucent/Agere, Cypress
> > > > > >           > > >               > > etc
> > > > > >           > > >               > > > > > seem to have sonet
> > > > > > framers
> > > > > > that support
> > > > > >           > > >               > > virtual
> > > > > >           > > >               > > > > > concatenation.
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > However, there has
> > > > > > been some
> > > > > > discussion on
> > > > > >           > > >               > > > > > arbitrary
> > > > > > concatenation as
> > > > > > well. arbitrary
> > > > > >           > > >               > > > > > concatenation seems
> > > > > > to be a
> > > > > > graceful
> > > > > >           > > >               > extension
> > > > > >           > > >               > > > > > of sonet/sdh's
> > > > > > contiguous
> > > > > > concatenation,
> > > > > >           > > >               > while
> > > > > >           > > >               > > > > > virtual
> > > > > > concatenation seems
> > > > > > like such a
> > > > > >           > > >               > hack.
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > I invite your
> > > > > > opinions and
> > > > > > comments on the
> > > > > >           > > >               > > > > > applications,
> > > > > > relevance and
> > > > > > potential
> > > > > >           > > >               > > lifetimes
> > > > > >           > > >               > > > > > of virtual and
> > > > > > arbitrary
> > > > > > concatenation
> > > > > >           > > >               > > schemes.
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > > Thanx,
> > > > > >           > > >               > > > > > Sanjay.
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > >
> > > > > >           > > >               >
> > > > > > __________________________________________________
> > > > > >           > > >               > > > > > Do You Yahoo!?
> > > > > >           > > >               > > > > > Yahoo! Auctions -
> > > > > > buy the
> > > > > > things you want at
> > > > > >           > > >               > > > great prices
> > > > > >           > > >               > > > > >
> > > > > > http://auctions.yahoo.com/
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > >
> > > > > > _______________________________________________
> > > > > >           > > >               > > > > > IP-Optical mailing
> > > > > > list
> > > > > >           > > >               > > > > >
> > > > > > [email-masked]
> > > > > >           > > >               > > > > >
> > > > > >           > > >               > > >
> > > > > >           > > >               > >
> > > > > >           > > >               >
> > > > > >           > > >
> > > > > >
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > >           > > >               > > > >
> > > > > >           > > >               > > > >
> > > > > >           > > >               >
> > > > > > _______________________________________________
> > > > > >           > > >               > > > > IP-Optical mailing
> > > > > > list
> > > > > >           > > >               > > > >
> > > > > > [email-masked]
> > > > > >           > > >               > > > >
> > > > > >           > > >               > >
> > > > > >           > > >               >
> > > > > >           > > >
> > > > > >
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical>
> > > > > >           > > >               > > begin:vcard
> > > > > >           > > >               > > > n:Vissers;Maarten
> > > > > >           > > >               > > > tel;cell:+31 62 061 3945
> > > > > >           > > >               > > > tel;fax:+31 35 687 5976
> > > > > >           > > >               > > > tel;home:+31 35 526 5463
> > > > > >           > > >               > > > tel;work:+31 35 687 4270
> > > > > >           > > >               > > > x-mozilla-html:FALSE
> > > > > >           > > >               > > > org:Lucent Technologies
> > > > > > Nederland;NA&CPSE
> > > > > >           > > >               > > > version:2.1
> > > > > >           > > >               > > >
> > > > > > email;internet:[email-masked]
> > > > > >           > > >               > > >
> > > > > > adr;quoted-printable:;;Botterstraat
> > > > > >           > > >               > > > 45=0D=0A=0D=0A;1271 XL
> > > > > > Huizen;;;The Netherlands>
> > > > > >           > > >               > >>  > > fn:Maarten Vissers
> > > > > >           > > >               > > > end:vcard
> > > > > >           > > >               > > >
> > > > > >           > > >               > >
> > > > > >           > > >               > >
> > > > > >           > > >               > >
> > > > > > __________________________________________________
> > > > > >           > > >               > > Do You Yahoo!?
> > > > > >           > > >               > > Yahoo! Auctions - buy the
> > > > > > things you
> > > > > > want at great
> > > > > >           > > >               > > prices
> > > > > >           > > >               > > http://auctions.yahoo.com/
> > > > > >           > > >               > >
> > > > > >           > > >               > >
> > > > > > _______________________________________________
> > > > > >           > > >               > > IP-Optical mailing list
> > > > > >           > > >               > >
> > > > > > [email-masked]
> > > > > >           > > >               > >
> > > > > >           > > >               >
> > > > > >           > > >
> > > > > >
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > >           > > >               >
> > > > > >           > > >               >
> > > > > >           > > >               >
> > > > > > __________________________________________________
> > > > > >           > > >               > Do You Yahoo!?
> > > > > >           > > >               > Yahoo! Auctions - buy the
> > > > > > things you
> > > > > > want at great
> > > > > >           > > >               > prices
> > > > > >           > > >               > http://auctions.yahoo.com/
> > > > > >           > > >               >
> > > > > >           > > >               >
> > > > > > _______________________________________________
> > > > > >           > > >               > IP-Optical mailing list
> > > > > >           > > >               >
> > > > > > [email-masked]
> > > > > >           > > >               >
> > > > > >           > > >
> > > > > >
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > > >           > > >
> > > > > >           > > >
> > > > > >           > > >
> > > > > > __________________________________________________
> > > > > >           > > >               Do You Yahoo!?
> > > > > >           > > >               Yahoo! Auctions - buy the
> > > > > > things you
> > > > > > want at great prices
> > > > > >           > > >               http://auctions.yahoo.com/
> > > > > >           > >
> > > > > >           > >
> > > > > > _______________________________________________
> > > > > >           > > IP-Optical mailing list
> > > > > >           > > [email-masked]
> > > > > >           > >
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > Yahoo! Auctions - buy the things you want at great prices
> > > > > http://auctions.yahoo.com/
> > > > >
> > > > > _______________________________________________
> > > > > IP-Optical mailing list
> > > > > [email-masked]
> > > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------F906E79E765EDB1E11698AE4
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------F906E79E765EDB1E11698AE4--

Delivery-date: Thu, 17 May 2001 04:28:43 -0700
Cc: "Bernstein, Greg" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 17 May 2001 13:26:10 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Michael Waldo <[email-masked]>
Original-CC: "Bernstein, Greg" <[email-masked]>, "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

This is a multi-part message in MIME format.
--------------A1A8AA663DBC054B94796453
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Waldo,

I am copying an email conversation ongoing in the IP-optical mailing
list on arbitrary concatenation. Hope this provides the input you are
looking for.

Bottom line is that neither arbitrary contiguous concatenation nor
arbitrary concatenation is part of the SONET/SDH standards. It is a
vendor proprietary extension of these SONET/SDH standards, for which it
is in my (and some other peoples) view highly unlikely that it will be
included in the SONET/SDH standards.

As you indicate with virtual concatenation being the international
standard and the direction in the industry today, arbitrary
concatenation doesn't add anything to the transport network; contrary,
it would cause interworking problems.

But arbitrary contiguous concatenation wouldn't add anything either, and
compared to arbitrary concatenation it would still have the bandwidth
fragmentation problem that standard contiguous concatenation is having.
I.e. arbitrary contiguous concatenation is worse.

All,

The GMPLS SONET/SDH extension document is thus defining a control plane
which supports capabilities in the transport plane that are not
supported by the international standards for this transport plane.
Personally, I find this very incorrect. IETF has no mandate to change
the SONET/SDH standards. A control plane for the transport network
should follow the transport network standards, not define its own
transport network.

Regards,

Maarten

---------------

Maarten Vissers wrote:
> 
> Greg, Anup, Sanjay,
> 
> To my recollection, the SONET/SDH definition is performed in T1X1.5 and
> ITU-T SG15. Last year new revisions of T1.105 and G.707 were approved,
> in which the "arbitrary contiguous concatenation" has been removed. Such
> step isn't made just for fun.
> 
> If you believe the removal of "arbitrary contiguous concatenation" from
> these standards was a mistake, please submit a contribution to T1X1.5
> and ITU-T Q.11/15 with a proposal to re-introduce it. At the same time
> you can then also request to introduce "arbitrary concatenation" and
> propose mappings of client signals into these arbitrary (contiguous)
> concatenated signals. However, as indicated by Mark, Juergen and myself,
> I doubt if you find support for such extension of SONET and SDH.
> 
> For the moment, SONET/SDH networks compliant with T1.105 and G.707
> standards can forward "contiguous concatenated" VC-4-Xc (X=4,16,64) and
> STS-3c/12c/48c/192c signals and "virtual concatenated" VC-n-Xv (n=3,4),
> STS-1, STS-3c-Xc (X=1..256) and VC-n (n=11,12), VT-1.5-Xv (X=1..64)
> signals, not the "arbitrary concatenated" signals.
> Arbitrary concatenation is a proprietary extension of SONET/SDH, for
> which there is no interworking with standard SONET/SDH networks.
> 
> Virtual concatenation is THE international standardised direction, for
> which a vendor and operator may expect to see seemless interworking in
> the SONET/SDH network.
> 
> Virtual concatenation got very popular due to the:
> - pricing of Ethernet ports on routers (compared to pricing of
> STM-N/OC-N ports on routers),
> - absence of channelized STM-N/OC-N interface ports on routers.
> 
> As a result the transport network was forced to accept Ethernet physical
> interfaces, in additon to the traditional SONET/SDH and PDH interfaces.
> Transport networking engineers very well understand the desire of a
> customer to pay only for the bandwidth needed, and consequential within
> the constraints of the SONET/SDH transport network a solution was
> developed to meet the needs of the customer and the needs of the
> operator. This is virtual concatenation with GFP as encapsulation
> method.
> 
> Virtual concatenation allows to separate the physical and logical
> aspects of Ethernet signals, like such is common practice for any other
> SDH/SONET signal. I.e. the (10M, 100M, 1G) Ethernet PHY signal is
> terminated, the ethernet idle packets are dropped and the packets with
> information inside of it are forwarded in a transport pipe sized to the
> customers need.
> The additional complexity is the introduction of a (skinny) ehternet
> layer on top of the SDH/SONET layers, as at a minimum some monitoring is
> to be performed at the ethernet level.
> 
> Of course, it would be more economical if the transport network didn't
> have to do this job. I.e. routers should use STM-N/OC-N interface ports
> supporting virtual concatenated VC-n/STS/VT signals. The transport
> network would n't have to deal then with its client signals, and instead
> of ethernet in the virtual concatenated signals, any other data protocol
> could be used by the routers (e.g. IP/PPP/GFP).
> 
> But, while having to do this ethernet processing, extensions are
> becoming economical in the access transport networks; i.e. having
> ethernet bridging/switching present, it can be used to groom ethernet
> traffic to further optimise and thus cost reduce ethernet packet
> transport. It is now possible to offer sub-VC-n/STS/VT ethernet
> transport pipes (in addition to the multi-VC-n/STS/VT ) through the
> SDH/SONET access networks.
> 
> Regards,
> 
> Maarten
> 
> Anup Tirumala wrote:
> >
> > If routers can routinely fill TDM pipes fully, why are we even talking
> > virtual concatenation?
> >
> > Arbitrary (or even Virtual) concatenation has the
> > best bang for buck with packets sharing bandwidth
> > with TDM. (i.e. in a converged network).
> >
> > Indeed, a business case does exist for arbitrary concatenation.
> > Ask Cyras (now Ciena;)
> >
> > You must look at this in conjunction with Network Processors
> > and statistical multiplexing.
> >
> > A customer need only pay for as much bandwidth as he/she needs,
> > while the remainder can be used for TDM channels.
> >
> > We believe the case for arbitrary concatenation does exist:
> >
> > 1. scales better with technology.
> > 2. no massive buffering requirements. (note that virtual concatenation
> >    does not "guarantee" hit-less operation. with buffering, one can limit
> >    the hit that's all).
> > 3. augments native contiguous concatenation. i.e. contiguous concatenation
> >    becomes a degenerate case of arbitrary concatenation.
> > 4. A customer explicity asked for it. :)
> >
> > I think there is merit to an effort at interoperability.
> >
> > -anup
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, May 15, 2001 12:36 PM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > >
> > >
> > > From my perspective, all necessary applications can be met by
> > > contiguous
> > > and virtual concatenation.  Adding arbitrary concatenation simply
> > > increases the number of spares to maintain, the number of
> > > attributes to
> > > test for interoperability, and the potential complexity to
> > > port cards.
> > > The improved bandwidth efficiency you are going to claim
> > > won't outweigh
> > > the problems I see as a result.  Unless you can show a significant
> > > business driver for this, I would recommend not wasting your
> > > time trying
> > > to standardize it.  The trend is to maintain variable size
> > > connections
> > > using packets anyway.  Why are we talking about doing this
> > > with TDM?  I
> > > find it most interesting that this IETF group is discussing variable
> > > size TDM pipes, when routers typically can fill a TDM pipe at
> > > the line
> > > rate.
> > >
> > > Mark Loyd Jones
> > > Sprint
> > > Technology Planning & Integration
> > > 913-534-5247
> > > [email-masked]
> > >
> > >
> > > > -----Original Message-----
> > > > From: chickoo66 [mailto:[email-masked]]
> > > > Sent: Tuesday, May 15, 2001 1:47 PM
> > > > To: GregB; mvissers; ip-optical
> > > > Cc: chickoo66
> > > > Subject: RE: [IP-Optical] concatenation extensions in sonet/sdh
> > > >
> > > >
> > > > I could not agree more.
> > > > Arb-Concatenation, being a logical (and graceful)
> > > > extension of standard contiguous concatenation,
> > > > can easily co-exist with virtual.
> > > > Imagine channels such as 2c,5c,6c,7c... 767c :)
> > > > However, we need to be able to interoperate
> > > > with outside-vendor equipments, with regards
> > > > to the multiplexing scheme.
> > > > Dr.Berstein/other, do you know of any such
> > > > interoperating effort on-going?
> > > > Would any one be interested in interoperability
> > > > issues pertaining to arb-concat?
> > > > I emphasize: arb-conc is complementary to virt-concat.
> > > > Comments?
> > > > Sanjay
> > > >
> > > >
> > > >
> > > > --- "Bernstein, Greg" <[email-masked]> wrote:
> > > > > Folks, please note that Arbitrary concatenation is
> > > > > not in any of the ITU or
> > > > > ANSI standards as Maarten points out below.
> > > > > Maarten my understanding is that GFP can be used
> > > > > with either standard
> > > > > contiguous concatenation or virtual concatenation.
> > > > >
> > > > > For those interested in arbitrary concatenation for
> > > > > the standard sizes,
> > > > > e.g., STS-3c, STS-12c, one can just use the payload
> > > > > mappings from standard
> > > > > contiguous concatenation.  A network supporting
> > > > > arbitrary concatenation can
> > > > > transport these efficiently with no re-grooming.
> > > > >
> > > > > Note that I think SDH/SONET networks can make use of
> > > > > both virtual and
> > > > > arbitrary concatenation.
> > > > > Greg B.
> > > > >
> > > > >   Dr. Greg M. Bernstein, Senior Scientist, Ciena
> > > > >   New phone: (510) 573-2237
> > > > >
> > > > >
> > > > >           -----Original Message-----
> > > > >           From:   Maarten Vissers [mailto:[email-masked]]
> > > > >           Sent:   Tuesday, May 15, 2001 1:06 AM
> > > > >           To:     Bernstein, Greg; 'ashritha thirumalai';
> > > > > [email-masked]
> > > > >           Subject:        Re: [IP-Optical] concatenation
> > > > extensions
> > > > > in
> > > > > sonet/sdh
> > > > >
> > > > >            << File: Card for Maarten Vissers >> Greg,
> > > > >
> > > > >           The transport of ethernet signals via SDH/SONET
> > > > > networks is
> > > > > being
> > > > >           defined in T1 and ITU-T to use virtual
> > > > > concatenation and GFP
> > > > > for
> > > > >           encapsulation, not arbitrary concatenation.
> > > > >
> > > > >           The transport of SAN signals (ESCON, FC, FICON)
> > > > > via
> > > > > SDH/SONET networks
> > > > >           is being defined in T1 and ITU-T to use virtual
> > > > > concatenation and GFP
> > > > >           for encapsulation, not arbitrary concatenation.
> > > > >
> > > > >           The transport of ATM signals via SDH/SONET
> > > > > networks is
> > > > > defined in T1 and
> > > > >           ITU-T to use VC-3/STS-1, VC-4/STS-3c,
> > > > > VC-4-4c/STS-12c,
> > > > > VC-4-16c/STS-48c,
> > > > >           VC-4-64c/STS-192c, VC-4-256c/STS-768c and
> > > > > STS-1-Xv,
> > > > > VC-4-Xv/STS-3c-Xv.
> > > > >
> > > > >           For the case interworking between subnetworks of
> > > > > different
> > > > > vendors and
> > > > >           networks of different operators is required, the
> > > > > above
> > > > > signals and
> > > > >           mappings are to be used.
> > > > >
> > > > >           For the case interworking is not required, any
> > > > > proprietary
> > > > >           implementation (e.g. arbitrary concatenation) can
> > > > > be used.
> > > > >
> > > > >           Regards,
> > > > >
> > > > >           Maarten
> > > > >
> > > > >
> > > > >           Maarten Vissers wrote:
> > > > >           >
> > > > >           > Greg, Sanjay,
> > > > >           >
> > > > >           > In additon to Juergen's comment, I would like to
> > > > > point out
> > > > > that VC-4-2c,
> > > > >           > VC-4-3c, VC-4-5c, etc are not longer part of the
> > > > > SDH
> > > > > hierarchy (G.707
> > > > >           > 10/2000), and I doubt if the ITU-T community
> > > > > would like to
> > > > > re-introduce
> > > > >           > these signal types given all the hassle the
> > > > > introduction
> > > > > of VC-4-4c
> > > > >           > (with ATM payload) did cause in the past.
> > > > >           >
> > > > >           > And as Juergen indicated, real arbitrary
> > > > > concatenation
> > > > > would require the
> > > > >           > mapping of a VC-4-Xc signal in any set of X AU-4
> > > > > timeslots. As long as
> > > > >           > you need still a series of contiguous timeslots
> > > > > (i.e.
> > > > > arbitrary
> > > > >           > contiguous concatenation), bandwidth
> > > > > defragmenation (or
> > > > > re-grooming) is
> > > > >           > required once every ...
> > > > >           >
> > > > >           > I.e. arbitrary contiguous concatenation (ACC)
> > > > >           > - still has the same fragmentation issue that is
> > > > > also
> > > > > present in today's
> > > > >           > contiguous concatenation; it is less restrictive
> > > > > from a
> > > > > theoretical
> > > > >           > perspective, but Murphy's law will be
> > > > > applicable, and the
> > > > > fragmentation
> > > > >           > will be such that there is no contiguous set of
> > > > > AU4
> > > > > timeslots free
> > > > >           > normally - i.e. from the distance, there is no
> > > > > benifit at
> > > > > all from the
> > > > >           > operational perspective, perhaps even only a
> > > > > disadvantage
> > > > > (more complex
> > > > >           > provisioning due to more flexibility)
> > > > >           > - ACC signals can not be routed via most
> > > > > SDH/SONET
> > > > > networks.
> > > > >           >
> > > > >           > Within the OTN definition work ongoing, the ODUk
> > > > > multiplexing is
> > > > >           > intended to be specified with true arbitrary
> > > > > concatenation. Refer to
> > > > >           > SP15 of the G.709 living list for the moment.
> > > > > Later this
> > > > > week a first
> > > > >           > ODUk multiplexing text proposal will be issued
> > > > > towards
> > > > > ITU-T Q.11/15.
> > > > >           >
> > > > >           > Regards,
> > > > >           >
> > > > >           > Maarten
> > > > >           >
> > > > >           > Heiles Juergen wrote:
> > > > >           > >
> > > > >           > > Greg, Sanjay,
> > > > >           > >
> > > > >           > > if you build up a new network, if you don't
> > > > > have to care
> > > > > about an installed base and if you further can
> > > > > accept to be restricted to a
> > > > > single vendor (E.g. signle ring network) arbitary
> > > > > concatenation could be
> > > > > fine.
> > > > >           > > Concerning the upgrade, virtual concatenation
> > > > > would
> > > > > often require only a new tributary interface card
> > > > > (depending on your system
> > > > > design), not an upgrade of the whole network
> > > > > element. As you have to install
> > > > > this new interface card due to the new service (e.g.
> > > > > 100M/1G Ethernet)in any
> > > > > case it is not an additional investment.
> > > > >           > > Greg you mentioned re-grooming as far as I
> > > > > understand
> > > > > arbitary (contiguous) concatenation you still need X
> > > > > contiguous VCs/SPEs.
> > > > > Only the number X and the starting time slot has no
> > > > > limitations as it is the
> > > > > case for standard contiguous cocnatenation. So you
> > > > > still ahve to do
> > > > > re-grooming if for example time slots 1, 5 and 6 are
> > > > > available in an STM-16
> > > > > signal as these time slots are not contgiguous.
> > > > > Arbitary concatenation has
> > > > > less restrictions compared to standard contiguous
> > > > > concatenation, but still
> > > > > has restrictions.
> > > > >           > > Sanjay, you talked about OC3072. We might have
> > > > > 160
> > > > > Gbit/s in the future in some parts of the network,
> > > > > but others are still
> > > > > running with lower line speeds (e.g. long distance
> > > > > systems, trans oceanic
> > > > > systems) as the higher bit rate imposes limitations
> > > > > in the distance and you
> > > > > have an isntalled base. With virtual concatenation
> > > > > it is not a problem to
> > > > > transport a 160 Gbit/s service (if such a kind of
> > > > > service is needed in any
> > > > > case) over 4x40G or 16x10G.
> > > > >           > > Note that arbitary concatenation was diffcult
> > > > > to
> > > > > implement with the chip technology available some
> > > > > years ago when the
> > > > > processing was often done in parallel on several
> > > > > chips. Todays single chip
> > > > > solutions allowed to introduce arbitary
> > > > > concatenation. For the size of the
> > > > > alignment buffer for virtual concatenation it is
> > > > > also only a question of the
> > > > > size of available memory chips which will increase
> > > > > over time.
> > > > >           > > Sanjay you mentioned that it might be possible
> > > > > to use
> > > > > just an SW upgrade for an cross-connect in order to
> > > > > get arbitary
> > > > > concatenation support. I don't think so as arbitary
> > > > > concateantion requries
> > > > > specific pointer processing which is done in HW.
> > > > >           > >
> > > > >           > > Regards
> > > > >           > >
> > > > >           > > Juergen
> > > > >           > >
> > > > >           > > > -----Original Message-----
> > > > >           > > > From: Bernstein, Greg [SMTP:[email-masked]]
> > > > >           > > > Sent: Monday, May 14, 2001 5:55 AM
> > > > >           > > > To:   'ashritha thirumalai'; Fong, Man Wing;
> > > > > Maarten
> > > > > Vissers; Heiles Juergen
> > > > >           > > > Cc:   [email-masked]
> > > > >           > > > Subject:      RE: [IP-Optical] concatenation
> > > > > extensions in sonet/sdh
> > > > >           > > >
> > > > >           > > > Hi Sanjay see comments in line below.
> > > > >           > > > Greg B.
> > > > >           > > >
> > > > >           > > >       Dr. Greg M. Bernstein, Senior
> > > > > Scientist, Ciena
> > > > >           > > >       New phone: (510) 573-2237
> > > > >           > > >
> > > > >           > > >
> > > > >           > > >               -----Original Message-----
> > > > >           > > >               From:   ashritha thirumalai
> > > > > [mailto:[email-masked]]
> > > > >           > > >               Sent:   Saturday, May 12, 2001
> > > > > 9:54 AM
> > > > >           > > >               To:     Bernstein, Greg; Fong,
> > > > > Man Wing;
> > > > > Maarten Vissers;
> > > > >           > > > Heiles Juergen
> > > > >           > > >               Cc:
> > > > > [email-masked]
> > > > >           > > >               Subject:        RE:
> > > > > [IP-Optical]
> > > > > concatenation extensions in
> > > > >           > > > sonet/sdh
> > > > >           > > >
> > > > >           > > >               Dr. Bernstein,
> > > > >           > > >
> > > > >           > > >               Glad you replied.
> > > > >           > > >
> > > > >           > > >               A few further questions:
> > > > >           > > >
> > > > >           > > >               1. how are two different
> > > > > vendors
> > > > > implementing arb-conc
> > > > >           > > >               going to inter-operate? (i.e.
> > > > > how are
> > > > > bytes in
> > > > >           > > >               an arb-concatenated channel
> > > > > multiplexed
> > > > > into the
> > > > >           > > >               rest of Sonet/SDH timeslots?)
> > > > >           > > >               > For non-standard sizes this
> > > > > needs some
> > > > > work. I'm happy to
> > > > >           > > > work anyone in this area. Starting with the
> > > > > standard
> > > > > sizes isn't a problem
> > > > >           > > > we just use the already standardized
> > > > > mappings.
> > > > >           > > >               2. would you be able to list
> > > > > some
> > > > > vendors that
> > > > >           > > >               do (or claim to) support
> > > > > arb-concat?
> > > > >           > > >               > Ciena's CoreDirector for
> > > > > one. I know
> > > > > of other vendors but
> > > > >           > > > I'm not sure if they've publicly announced.
> > > > >           > > >               3. and a repeat question. why
> > > > > should one
> > > > > go with
> > > > >           > > >               arb-concat when virt-cont
> > > > > (kludgy as it
> > > > > may be)
> > > > >           > > >               has been standardized. (in my
> > > > > limited
> > > > > understanding
> > > > >           > > >               of virt-conc, it does avoid
> > > > > the
> > > > > "re-grooming" that
> > > > >           > > >               you alluded to).
> > > > >           > > >               > Well virtual concatenation
> > > > > can do
> > > > > everything but it>
> > > > >           > > > requires the edge equipment to be upgraded.
> > > > > If folks
> > > > > want to preserve their
> > > > >           > > > investments around the edge and
> > > > > incrementally upgrade
> > > > > the core then any line
> > > > >           > > > connecting two pieces of equipment
> > > > > supporting
> > > > > arbitrary concatenation
> > > > >           > > > doesn't need to be re-groomed or be used
> > > > > inefficiently.  Hence it's a good
> > > > >           > > > feature for core equipment, but maybe not so
> > > > > hot
> > > > > compared to virtual
> > > > >           > > > concatenation at the edge.
> > > > >           > > >
> > > > >           > > >               greatly appreciate a reply.
> > > > >           > > >
> > > > >           > > >               Thanx,
> > > > >           > > >               Sanjay.
> > > > >           > > >
> > > > >           > > >
> > > > >           > > >
> > > > >           > > >
> > > > >           > > >               --- "Bernstein, Greg"
> > > > > <[email-masked]>
> > > > > wrote:
> > > > >           > > >               > Hi sorry to be out of the
> > > > > loop for a
> > > > > while.  Man
> > > > >           > > >               > Wing's assesment and the
> > > > >           > > >               > concerns about upgrades are
> > > > > fairly
> > > > > correct except:
> > > > >           > > >               > (1) With the new generation
> > > > > of
> > > > > SONET/SDH cross
> > > > >           > > >               > connects arbitrary is a
> > > > >           > > >               > feature.  I can think of at
> > > > > least one
> > > > > new and very
> > > > >           > > >               > popular switch that has
> > > > >           > > >               > this feature.
> > > > >           > > >               > (2) I also know of access
> > > > > equipment
> > > > > vendors that
> > > > >           > > >               > offer this feature (but not
> > > > >           > > >               > virtual concatenation).
> > > > >           > > >               > (3) There is a bit more
> > > > > fundamental
> > > > > reason behind
> > > > >           > > >               > the usefulness of
> > > > >           > > >               > arbitrary concatenation.
> > > > > Avoiding the
> > > > > need to
> > > > >           > > >               > "re-groom" the circuits on a
> > > > >           > > >               > line (the nasty service
> > > > > impacting
> > > > > process of
> > > > >           > > >               > remapping circuits to time
> > > > >           > > >               > slots so that you can add a
> > > > > new
> > > > > concatenated circuit
> > > > >           > > >               > within the standard
> > > > >           > > >               > contiguous concatenation
> > > > > constraints).
> > > > >           > > >               > As to how it got into the
> > > > > ODSI
> > > > > specification, the
> > > > >           > > >               > answer is fairly simple,
> > > > >           > > >               > folks (including myself)
> > > > > asked for it
> > > > > to be
> > > > >           > > >               > included, just like in the
> > > > > GMPLS
> > > > >           > > >               > specification.  I haven't
> > > > > found a
> > > > > customer out there
> > > > >           > > >               > that likes to re-groom
> > > > >           > > >               > traffic (or the bandwidth
> > > > > inefficiency
> > > > > from not
> > > > >           > > >               > regrooming).
> > > > >           > > >               >
> > > > >           > > >               > Greg B.
> > > > >           > > >               >
> > > > > ***********************************
> > > > >           > > >               > Dr. Greg M. Bernstein
> > > > >           > > >               > Senior Scientist, Ciena
> > > > > Corporation
> > > > >           > > >               >
> > > > >           > > >               > -----Original Message-----
> > > > >           > > >               > From: ashritha thirumalai
> > > > >           > > >               > [mailto:[email-masked]]
> > > > >           > > >               > Sent: Friday, May 11, 2001
> > > > > 1:50 PM
> > > > >           > > >               > To: Fong, Man Wing; Maarten
> > > > > Vissers;
> > > > > Heiles Juergen
> > > > >           > > >               > Cc:
> > > > > [email-masked]
> > > > >           > > >               > Subject: RE: [IP-Optical]
> > > > > concatenation extensions
> > > > >           > > >               > in sonet/sdh
> > > > >           > > >               >
> > > > >           > > >               >
> > > > >           > > >               > Well, arb-conct is most
> > > > > really useful
> > > > > for data
> > > > >           > > >               > (i.e. Packet-Over-Sonet).
> > > > > i.e. one can
> > > > > provide
> > > > >           > > >               > an STS19c or so for a 1GbE
> > > > > pipe (as
> > > > > opposed to
> > > > >           > > >               > an STS48c as is currently
> > > > > being done).
> > > > > This
> > > > >           > > >               > goal is same as that of
> > > > > virt-conc.
> > > > >           > > >               >
> > > > >           > > >               > I am not really sure how an
> > > > > interconnection will
> > > > >           > > >               > be problematic with a DACS?
> > > > > Could you
> > > > > elaborate
> > > > >           > > >               > kindly?
> > > > >           > > >               >
> > > > >           > > >               > Thanx,
> > > > >           > > >               > Sanjay
> > > > >           > > >               > --- "Fong, Man Wing"
> > > > > <[email-masked]>
> > > > >           > > >               > wrote:
> > > > >           > > >               > > Hi Sanjay,
> > > > >           > > >               > >
> > > > >           > > >               > > Here is my 2 cents worth
> > > > > of
> > > > > comments.
> > > > >           > > >               > >
> > > > >           > > >               > > 3. arb. conc. as well as
> > > > > virt. conc.
> > > > > require
> > > > >           > > >               > > upgrades
> > > > >           > > >               > >    at the end points,
> > > > > since all
> > > > > systems in a ring
> > > > >           > > >               > >    will be of the same
> > > > > vendor
> > > > > anyway. (i.e. if one
> > > > >           > > >               > >    system supports arb.
> > > > > conc. so
> > > > > will the rest in
> > > > >           > > >               > >    the ring).
> > > > >           > > >               > > Not quiet true. There
> > > > > might be a
> > > > > problem when
> > > > >           > > >               > > interconnecting with a
> > > > > cross
> > > > >           > > >               > > connect system. For my
> > > > > understanding, I can't
> > > > >           > > >               > think
> > > > >           > > >               > > of any cross connect
> > > > >           > > >               > > system support arbitrary
> > > > > concatenation.
> > > > >           > > >               > >
> > > > >           > > >               > > Regards,
> > > > >           > > >               > > Man Wing
> > > > >           > > >               > >
> > > > >           > > >               > > -----Original Message-----
> > > > >           > > >               > > From:       ashritha
> > > > > thirumalai
> > > > >           > > >               > >
> > > > > [mailto:[email-masked]]
> > > > >           > > >               > > Sent:       Friday, May
> > > > > 11, 2001
> > > > > 11:55 AM
> > > > >           > > >               > > To: Maarten Vissers;
> > > > > Heiles Juergen
> > > > >           > > >               > > Cc: 'ashritha thirumalai';
> > > > >           > > >               > >
> > > > > [email-masked]
> > > > >           > > >               > > Subject:    Re:
> > > > > [IP-Optical]
> > > > > concatenation extensions
> > > > >           > > >               > > in sonet/sdh
> > > > >           > > >               > >
> > > > >           > > >               > > Thanks Juergen and Maarten
> > > > > for you
> > > > > valuable
> > > > >           > > >               > > feedback.
> > > > >           > > >               > >
> > > > >           > > >               > > Here's my dilemma:
> > > > >           > > >               > >
> > > > >           > > >               > > 1. arb. concatenation is a
> > > > > natural
> > > > > and elegant
> > > > >           > > >               > >    extension to sonet/sdh
> > > > > contigous-concatenation.
> > > > >           > > >               >
> > > > >           > > >               > >
> > > > >           > > >               > > 2. arb. concatenation
> > > > > scales very
> > > > > well with rate. >
> > > > >           > > >               > >    imagine the buffering
> > > > > required
> > > > > for OC768 or i
> > > > >           > > >               > >    dare say, OC3072 in a
> > > > > framer
> > > > > device supporting
> > > > >           > > >               > >    virtual concatenation.
> > > > > (while an
> > > > > ANSI draft
> > > > >           > > >               > >    recommends a minimum of
> > > > > 1 frame's
> > > > > worth of
> > > > >           > > >               > >    buffering, this is
> > > > > hardly
> > > > > sufficient. most
> > > > >           > > >               > people
> > > > >           > > >               > >    want about 16 frames
> > > > > worth of
> > > > > buffering).
> > > > >           > > >               > >
> > > > >           > > >               > > 3. in a given ring, it is
> > > > > virtually
> > > > > unknown to
> > > > >           > > >               > >    intermix systems from
> > > > > two
> > > > > vendors.
> > > > >           > > >               > >    therefore, a system
> > > > > (say and ADM)
> > > > > supporting
> > > > >           > > >               > >    arb. concatenation can
> > > > > gracefully
> > > > > co-exist with
> > > > >           > > >               > >    its sibling systems on
> > > > > the same
> > > > > ring.
> > > > >           > > >               > >
> > > > >           > > >               > > 4. now the question is
> > > > > what happens
> > > > > at end-points.
> > > > >           > > >               >
> > > > >           > > >               > >    well, the end-points
> > > > > (especially
> > > > > the receive)
> > > > >           > > >               > >    will have to support
> > > > > arb
> > > > > concatenation.
> > > > >           > > >               > >    (if there is a cross
> > > > > connect, it
> > > > >           > > >               > >    could possibly be
> > > > > handled by
> > > > > software alone).
> > > > >           > > >               > >
> > > > >           > > >               > >    On the other hand,
> > > > > virtual
> > > > > concatenation will
> > > > >           > > >               > >    need support as well at
> > > > > the
> > > > > end-points. i.e.
> > > > >           > > >               > >    current systems will
> > > > > need to be
> > > > > upgraded.
> > > > >           > > >               > >
> > > > >           > > >               > > my summary (i hope you
> > > > > will critique
> > > > > this):
> > > > >           > > >               > >
> > > > >           > > >               > > 1. arb. conc. is a more
> > > > > elegant
> > > > > solution.
> > > > >           > > >               > > 2. arb. conc. scales quite
> > > > > well with
> > > > > rate, while
> > > > >           > > >               > >    vir. conc. gets uglier
> > > > > and uglier
> > > > > to implement.
> > > > >           > > >               >
> > > > >           > > >               > > 3. arb. conc. as well as
> > > > > virt. conc.
> > > > > require
> > > > >           > > >               > > upgrades
> > > > >           > > >               > >    at the end points,
> > > > > since all
> > > > > systems in a ring
> > > > >           > > >               > >    will be of the same
> > > > > vendor
> > > > > anyway. (i.e. if one
> > > > >           > > >               > >    system supports arb.
> > > > > conc. so
> > > > > will the rest in
> > > > >           > > >               > >    the ring).
> > > > >           > > >               > > 4. why is ODSI making a
> > > > > mention of
> > > > > arb.
> > > > >           > > >               > > concatenation
> > > > >           > > >               > >    in their functional
> > > > > spec?
> > > > >           > > >               > >
> > > > >           > > >               > > Thanx,
> > > > >           > > >               > > Sanjay.
> > > > >           > > >               > > --- Maarten Vissers
> > > > > <[email-masked]> wrote:
> > > > >           > > >               > > > Sanjay,
> > > > >           > > >               > > >
> > > > >           > > >               > > > Arbitrary concatenation
> > > > > was
> > > > > present in the very
> > > > >           > > >               > > > first versions of T.105
> > > > >           > > >               > > > and G.707 (called G.709
> > > > > at the
> > > > > time). It was
> > > > >           > > >               > never
> > > > >           > > >               > > > implemented, until
> > > > >           > > >               > > > ATM people decided
> > > > > (without
> > > > > consultation with
> > > > >           > > >               > > > transport people) to
> > > > >           > > >               > > > define ATM over
> > > > > VC-4-4c/STS-12c.
> > > > > The problems
> > > > >           > > >               > this
> > > > >           > > >               > > > has caused initially
> > > > >           > > >               > > > in the networks was
> > > > > tremendous;
> > > > > VC-4-4c/STS-12c
> > > > >           > > >               > > > couldn't be transported
> > > > >           > > >               > > > as a tributary signal in
> > > > > e.g.
> > > > > STM-16/OC-48
> > > > >           > > >               > > signals,
> > > > >           > > >               > > > it could only be
> > > > >           > > >               > > > transported within an
> > > > > STM-4/OC-12
> > > > > directly on
> > > > >           > > >               > > fiber
> > > > >           > > >               > > > (very expensive!!).
> > > > >           > > >               > > > Only when new network
> > > > > elements
> > > > > where installed
> > > > >           > > >               > > > supporting
> > > > >           > > >               > > > VC-4-4c/STS-12c this
> > > > > ATM-service
> > > > > could be
> > > > >           > > >               > handled
> > > > >           > > >               > > by
> > > > >           > > >               > > > the transport
> > > > >           > > >               > > > networks at normal
> > > > > costs. To
> > > > > transport
> > > > >           > > >               > > > VC-4-4c/STS-12c over the
> > > > > original
> > > > >           > > >               > > > SDH networks,
> > > > > contiguous/virtual
> > > > > concatenation
> > > > >           > > >               > > > conversion function has
> > > > >           > > >               > > > been defined (see
> > > > > G.707); special
> > > > > cont/virt conc
> > > > >           > > >               > > > conversion interface
> > > > >           > > >               > > > port units have been
> > > > > designed and
> > > > > installed.
> > > > >           > > >               > > >
> > > > >           > > >               > > > Arbitrary concatenation
> > > > > has been
> > > > > taken out in
> > > > >           > > >               > the
> > > > >           > > >               > > > latest versions of the
> > > > >           > > >               > > > two standards for the
> > > > > reasons
> > > > > mentioned by
> > > > >           > > >               > Juergen
> > > > >           > > >               > > > and indicated above.
> > > > >           > > >               > > > I would say that most
> > > > > likely 99%
> > > > > of the existing
> > > > >           > > >               > > > SONET/SDH networks do
> > > > >           > > >               > > > not support arbitrary
> > > > > concatenation, and there
> > > > >           > > >               > are
> > > > >           > > >               > > > no client signals
> > > > >           > > >               > > > defined that are mapped
> > > > > into
> > > > > arbitrary
> > > > >           > > >               > > concatenated
> > > > >           > > >               > > > signals. So I would
> > > > >           > > >               > > > assume that arbitrary
> > > > > concatenation is a dead
> > > > >           > > >               > > body,
> > > > >           > > >               > > > not worth to invest
> > > > >           > > >               > > > a single penny in.
> > > > > Virtual
> > > > > concatenation is the
> > > > >           > > >               > > > future.
> > > > >           > > >               > > >
> > > > >           > > >               > > > Regards,
> > > > >           > > >               > > >
> > > > >           > > >               > > > Maarten
> > > > >           > > >               > > >
> > > > >           > > >               > > > Heiles Juergen wrote:
> > > > >           > > >               > > > >
> > > > >           > > >               > > > > Sanjay,
> > > > >           > > >               > > > >
> > > > >           > > >               > > > > arbitary contiguous
> > > > > concatenation has to be
> > > > >           > > >               > > > supported by all network
> > > > > elements
> > > > > along the>
> > > > >           > > >               > path,>
> > > > >           > > >               > > > while virtual
> > > > > concatenation needs
> > > > > only support
> > > > >           > > >               > at
> > > > >           > > >               > > > the end systems
> > > > > terminating
> > > > > virtual
> > > > >           > > >               > concatenation
> > > > >           > > >               > > > and providing access to
> > > > > the client
> > > > > signal.
> > > > >           > > >               > > > > Arbitary contiguous
> > > > > concatenation is not
> > > > >           > > >               > > > standardized and support
> > > > > only by
> > > > > several
> > > > >           > > >               > vendors.
> > > > >           > > >               > > > Exisitng networks don't
> > > > > support
> > > > > it. It would
> > > > >           > > >               > > require
> > > > >           > > >               > > > a replacement of most
> > > > > network
> > > > > elements,
> > > > >           > > >               > something
> > > > >           > > >               > > > operators don't want.
> > > > > With virtual
> > > > > concatenation
> > > > >           > > >               > > you
> > > > >           > > >               > > > can go through exisitng
> > > > > networks.
> > > > > Only the end
> > > > >           > > >               > > > systems that support the
> > > > > specific
> > > > > client signal
> > > > >           > > >               > > have
> > > > >           > > >               > > > to support virtual
> > > > > concatenation
> > > > > also.
> > > > >           > > >               > > > > Furthermore virtual
> > > > > concatenation allows to
> > > > >           > > >               > > > disribute the individual
> > > > > VCs/STS-SPEs over
> > > > >           > > >               > several
> > > > >           > > >               > > > STM/OC signals, which is
> > > > > not
> > > > > possible with
> > > > >           > > >               > > > contiguous
> > > > > concatenation. An
> > > > > application for
> > > > >           > > >               > this
> > > > >           > > >               > > is
> > > > >           > > >               > > > the transport of a 10
> > > > > Gbit/s
> > > > > paylaod over
> > > > >           > > >               > 4xOC-48
> > > > >           > > >               > > in
> > > > >           > > >               > > > a OC-48 based WDM
> > > > > system.
> > > > >           > > >               > > > > The LCAS (Link
> > > > > Capacity
> > > > > Adjustment Scheme)
> > > > >           > > >               > > allows
> > > > >           > > >               > > > to modify the number of
> > > > > virtual
> > > > > concatenated
> > > > >           > > >               > > signals
> > > > >           > > >               > > > (and as such the
> > > > > transport
> > > > > bandwidth) on the
> > > > >           > > >               > fly.
> > > > >           > > >               > > > > In my view virtual
> > > > > concatenation
> > > > > has a longer
> > > > >           > > >               > > > lifetime.
> > > > >           > > >               > > > >
> > > > >           > > >               > > > > Regards
> > > > >           > > >               > > > >
> > > > >           > > >               > > > > Juergen
> > > > >           > > >               > > > >
> > > > >           > > >               > > > > > -----Original
> > > > > Message-----
> > > > >           > > >               > > > > > From: ashritha
> > > > > thirumalai
> > > > >           > > >               > > >
> > > > > [SMTP:[email-masked]]
> > > > >           > > >               > > > > > Sent: Monday, May
> > > > > 07, 2001
> > > > > 9:05 PM
> > > > >           > > >               > > > > > To:
> > > > > [email-masked]
> > > > >           > > >               > > > > > Cc:
> > > > > [email-masked]
> > > > >           > > >               > > > > > Subject:
> > > > > [IP-Optical]
> > > > > concatenation
> > > > >           > > >               > > > extensions in sonet/sdh
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > All,
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > A newbie question.
> > > > > (and a
> > > > > digression from
> > > > >           > > >               > > > current
> > > > >           > > >               > > > > > threads)
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > Virtual
> > > > > concatenation seems to
> > > > > have been
> > > > >           > > >               > > > accepted
> > > > >           > > >               > > > > > as standard
> > > > > procedure.
> > > > > Lucent/Agere, Cypress
> > > > >           > > >               > > etc
> > > > >           > > >               > > > > > seem to have sonet
> > > > > framers
> > > > > that support
> > > > >           > > >               > > virtual
> > > > >           > > >               > > > > > concatenation.
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > However, there has
> > > > > been some
> > > > > discussion on
> > > > >           > > >               > > > > > arbitrary
> > > > > concatenation as
> > > > > well. arbitrary
> > > > >           > > >               > > > > > concatenation seems
> > > > > to be a
> > > > > graceful
> > > > >           > > >               > extension
> > > > >           > > >               > > > > > of sonet/sdh's
> > > > > contiguous
> > > > > concatenation,
> > > > >           > > >               > while
> > > > >           > > >               > > > > > virtual
> > > > > concatenation seems
> > > > > like such a
> > > > >           > > >               > hack.
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > I invite your
> > > > > opinions and
> > > > > comments on the
> > > > >           > > >               > > > > > applications,
> > > > > relevance and
> > > > > potential
> > > > >           > > >               > > lifetimes
> > > > >           > > >               > > > > > of virtual and
> > > > > arbitrary
> > > > > concatenation
> > > > >           > > >               > > schemes.
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > > Thanx,
> > > > >           > > >               > > > > > Sanjay.
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > >
> > > > >           > > >               > > >
> > > > >           > > >               >
> > > > > __________________________________________________
> > > > >           > > >               > > > > > Do You Yahoo!?
> > > > >           > > >               > > > > > Yahoo! Auctions -
> > > > > buy the
> > > > > things you want at
> > > > >           > > >               > > > great prices
> > > > >           > > >               > > > > >
> > > > > http://auctions.yahoo.com/
> > > > >           > > >               > > > > >
> > > > >           > > >               > > > > >
> > > > >           > > >               > >
> > > > > _______________________________________________
> > > > >           > > >               > > > > > IP-Optical mailing
> > > > > list
> > > > >           > > >               > > > > >
> > > > > [email-masked]
> > > > >           > > >               > > > > >
> > > > >           > > >               > > >
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >           > > >               > > > >
> > > > >           > > >               > > > >
> > > > >           > > >               >
> > > > > _______________________________________________
> > > > >           > > >               > > > > IP-Optical mailing
> > > > > list
> > > > >           > > >               > > > >
> > > > > [email-masked]
> > > > >           > > >               > > > >
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical>
> > > > >           > > >               > > begin:vcard
> > > > >           > > >               > > > n:Vissers;Maarten
> > > > >           > > >               > > > tel;cell:+31 62 061 3945
> > > > >           > > >               > > > tel;fax:+31 35 687 5976
> > > > >           > > >               > > > tel;home:+31 35 526 5463
> > > > >           > > >               > > > tel;work:+31 35 687 4270
> > > > >           > > >               > > > x-mozilla-html:FALSE
> > > > >           > > >               > > > org:Lucent Technologies
> > > > > Nederland;NA&CPSE
> > > > >           > > >               > > > version:2.1
> > > > >           > > >               > > >
> > > > > email;internet:[email-masked]
> > > > >           > > >               > > >
> > > > > adr;quoted-printable:;;Botterstraat
> > > > >           > > >               > > > 45=0D=0A=0D=0A;1271 XL
> > > > > Huizen;;;The Netherlands>
> > > > >           > > >               > >>  > > fn:Maarten Vissers
> > > > >           > > >               > > > end:vcard
> > > > >           > > >               > > >
> > > > >           > > >               > >
> > > > >           > > >               > >
> > > > >           > > >               > >
> > > > > __________________________________________________
> > > > >           > > >               > > Do You Yahoo!?
> > > > >           > > >               > > Yahoo! Auctions - buy the
> > > > > things you
> > > > > want at great
> > > > >           > > >               > > prices
> > > > >           > > >               > > http://auctions.yahoo.com/
> > > > >           > > >               > >
> > > > >           > > >               > >
> > > > > _______________________________________________
> > > > >           > > >               > > IP-Optical mailing list
> > > > >           > > >               > >
> > > > > [email-masked]
> > > > >           > > >               > >
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >           > > >               >
> > > > >           > > >               >
> > > > >           > > >               >
> > > > > __________________________________________________
> > > > >           > > >               > Do You Yahoo!?
> > > > >           > > >               > Yahoo! Auctions - buy the
> > > > > things you
> > > > > want at great
> > > > >           > > >               > prices
> > > > >           > > >               > http://auctions.yahoo.com/
> > > > >           > > >               >
> > > > >           > > >               >
> > > > > _______________________________________________
> > > > >           > > >               > IP-Optical mailing list
> > > > >           > > >               >
> > > > > [email-masked]
> > > > >           > > >               >
> > > > >           > > >
> > > > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > > >           > > >
> > > > >           > > >
> > > > >           > > >
> > > > > __________________________________________________
> > > > >           > > >               Do You Yahoo!?
> > > > >           > > >               Yahoo! Auctions - buy the
> > > > > things you
> > > > > want at great prices
> > > > >           > > >               http://auctions.yahoo.com/
> > > > >           > >
> > > > >           > >
> > > > > _______________________________________________
> > > > >           > > IP-Optical mailing list
> > > > >           > > [email-masked]
> > > > >           > >
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Auctions - buy the things you want at great prices
> > > > http://auctions.yahoo.com/
> > > >
> > > > _______________________________________________
> > > > IP-Optical mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > >
> >
> > _______________________________________________
> > IP-Optical mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/ip-optical
--------------A1A8AA663DBC054B94796453
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------A1A8AA663DBC054B94796453--

Delivery-date: Thu, 17 May 2001 00:48:18 -0700
From: Heiles Juergen <[email-masked]>
To: "'Michael Waldo'" <[email-masked]>, "Bernstein, Greg" <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Thu, 17 May 2001 09:45:32 +0200

It seems that we have some confusion concerning arbitary concatenation. That happens when we talk about something that is not standardized and proprietary. So next time we better get a detailed definiton of the proprietary solution before it is included in order to check if it fits the definitions.
Coming back to concatenation I see the following types:

Standard contiguous concatenation as defined in G.707 for VC-4 and in T1.105 for STS-1-SPE:
Uses X contiguous time slots within a STM/STS signal. x=4,16,64,256 for VC-4 and X=3,12,48,192, 768 for STS-1-SPE
The first time slot can only be at certain time slots.
The first time slot has a valid pointer , all other time slots have a concatenation indication. One set of path overhead is available for the whole signal.
-> we only need to identify the first time slot and the number of time slots (covered by GMPLS draft)

Virtual concatenation as defined in G.707 and T1.105 for every VC level:
Uses X time slots, which can be in any position and even distributed over everal STM/STS signals.
Every timeslot (individual signal) has its own pointer and path overhead and is treated indivdually at intermediate notes.
-> we need to identify all time slots (covered by GMPLS draft for a virtual cocnateantion that uses the same route for all individual signals)

Arbitary contiguous concatenation, not standardized extensiion of standard contiguous concatenation (that seems to be what is most peoples understanding of arbitary concatenation):
Same as standard contiguous concatenation, without the limits on X and the position of the first time slot
-> we only need to identify the first time slot and the number of time slots (covered by GMPLS draft)

Greg's arbitary concatenation (or non-contiguous contiguous concatenation); not standardized, proprietary solution (here I can only guess):
Uses X time slots which can be at any position within a STM/STS signal. The positons of the time slots have to be in ascending order. The first time slot has a valid pointer , all other time slots have a concatenation indication. One set of path overhead is available for the whole signal.
Some kind of in-band signaling (within the overhead) is required in order to identify the time slots that belong togehter if automatic adjustment of pointer processing to the signal type is needed
-> we need to identify every time slots
This signal type is not covered by the GMPLS draft. It is different from virtual concatenation as the signal processing (pointer, overhead) is different. As it is proprietary and not straight forward from the standard contiguous concatenation different implementations might exist that do not interwork and a identification for each implementation is required.

Juergen

> -----Original Message-----
> From:	Michael Waldo [SMTP:[email-masked]]
> Sent:	Thursday, May 17, 2001 12:42 AM
> To:	Bernstein, Greg
> Cc:	'Mannie, Eric'; [email-masked]; [email-masked]
> Subject:	Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
> 
> your (1) sounds more like virtual concatenation to me
> 
> (2) is what I have considered to be arbitrary concatenation. This could be
> useful when compared to standard contiguous concatenation because it could make
> more efficient use of the bandwidth within the SONET line (SDH MS) eg, using an
> STS-2c when only 100Mbs is needed. Standard contiguous concatenation payload
> values being 3c, 12c, 48c, 192c for SONET.
> 
> Considering virtual concatenation, arbitrary concatenation doesn't seem to have
> as much appeal (pretty useless).
> 
> Has the term "arbitrary concatenation" been defined anywhere? I've seen
> contiguous and virtual definitions, but I looked through the references in this
> draft, (as well as G.707 and T1.105) and I could not find the "arbitrary"
> definition.
> 
> 
> -Waldo
> 
> 
> "Bernstein, Greg" wrote:> 
> 
> > We started out with the simple term "arbitrary concatenation" a while back
> > to mean arbitrary in size and in timeslots used.  I'm not sure what was
> > meant when we added the "contiguous" to this.  Was it:
> > (1)     Treat this as one big signal within a single SONET Line (SDH MS),
> > with potentially arbitrary timeslots used.
> > (2)     Treat this as one big signal within a single SONET line (SDH MS),
> > with the timeslot numbering lying within a single range, i.e.,  X through Y,
> > with X < Y.
> >
> > If (1) then we need a list of time slots. If (2) then only the beginning
> > time slot is needed.  The problem with (2) is that it is a pretty useless
> > feature, i.e., doesn't prevent the need for re-grooming and seemed like a
> > mistake from the rather long gestation period for this specification rather
> > than something truly intended.
> >
> > Greg B.
> >         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >         New phone: (510) 573-2237
> >
> >                 -----Original Message-----
> >                 From:   Mannie, Eric [mailto:[email-masked]]
> >                 Sent:   Wednesday, May 16, 2001 12:44 PM
> >                 To:     Bernstein, Greg; [email-masked]; [email-masked]
> >                 Subject:        RE: Small issue on
> > draft-ietf-ccamp-gmpls-sdh-00.txt
> >
> >                 Dear All,
> >
> >                 Sorry I was confused, the original text of the draft is
> > correct:
> >
> >                 With any kind of ***contiguous*** concatenation there is one
> > big signal, so
> >                 one and only one label (pointer) is needed (otherwise it is
> > not a contiguous
> >                 concatenation). With any kind of virtual concatenation,
> > there are several
> >                 VC's, so one label (pointer) per VC is needed. Even if all
> > the VC's
> >                 virtually concatenated are contiguous (by coincidence) we
> > still need to
> >                 identify each of them.
> >
> >                 Arbitrary and standard concatenations are orthogonal with
> > contiguous and
> >                 virtual concatenations.
> >
> >                 Arbitrary means anything that is not standard.
> >
> >                 We use a code to differentiate between standard and
> > arbitrary contiguous
> >                 concatenation to avoid that a downstream node returns a
> > timeslot at a
> >                 position not supported by the upstream node. The upstream
> > node indicates the
> >                 number and types of signals to be concatenated and the
> > downstream node
> >                 cannot change it (it can just accept or refuse).
> >
> >                 We don't need a code to differentiate between standard
> > versus arbitrary
> >                 virtual concatenation because there is no restriction anyway
> > on the timeslot
> >                 positions that can return the downstream node. Again, the
> > upstream node
> >                 indicates the number and types of signals to be concatenated
> > and the
> >                 downstream node cannot change that (it can just accept or
> > refuse). SDH 1996
> >                 restricts the virtual concatenation to some well defined
> > signals, while SDH
> >                 2000 allows everything that make sense. But for the previous
> > reasons we
> >                 don't need to differentiate between the two (thing about the
> > reason why you
> >                 put a signaling element in a signaling message).
> >
> >                 Agreed ?
> >
> >                 Kind regards,
> >
> >                 Eric
> >
> >                 -----Original Message-----
> >                 From: Bernstein, Greg [mailto:[email-masked]]
> >                 Sent: Wednesday, May 16, 2001 5:33 PM
> >                 To: [email-masked]; [email-masked]
> >                 Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt> 
> >
> >                 Hi in the draf> t draft-ietf-ccamp-gmpls-sdh-00.txt it says:
> >
> >                    In case of any type of contiguous concatenation (e.g.
> > standard or
> >                    arbitrary concatenation), only one label appears in the
> > Label
> >                    field. That label is the lowest signal of the
> > contiguously
> >                    concatenated signal. By lowest signal we mean the one
> > having the
> >                    lowest label when compared as integer values, i.e. the
> > first
> >                    component signal of the concatenated signal encountered
> > when
> >                    descending the tree.
> >
> >                    In case of virtual concatenation, the explicit ordered
> > list of all
> >                    labels in the concatenation is given. Each label
> > indicates a
> >                    component of the virtually concatenated signal.
> >
> >                 This does not reflect the intent of arbitrary concatenation-
> > arbitrary, size
> >                 and placement of timeslots.  Otherwise the main benefit of
> > arbitrary
> >                 concatenation, preventing re-grooming is lost.  Corrected
> > text could read:
> >
> >                     In the case of standard contiguous, only one label
> > appears in the Label
> >                    field. That label is the lowest signal of the standard
> > contiguously
> >                    concatenated signal. By lowest signal we mean the one
> > having the
> >                    lowest label when compared as integer values, i.e. the
> > first
> >                    component signal of the concatenated signal encountered
> > when
> >                    descending the tree.
> >
> >                    In the cases of arbitrary or virtual concatenation, the
> > explicit ordered
> >                 list of all
> >                    labels in the concatenation is given. Each label
> > indicates a
> >                    component of the arbitrary or virtually concatenated
> > signal.
> >
> >                 Greg B.
> >                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
> >                         New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 19:13:28 -0700
From: Fong Liaw <[email-masked]>
To: 'George Swallow' <[email-masked]>, [email-masked], [email-masked]
Subject: RE: GMPLS Last Calls - generalized-04/rsvp-te-03
Date: Wed, 16 May 2001 19:12:12 -0700

Hi, 

Here are my comments/questions. I apologize if 
I overlook the text that might already explain 
my questions. A pointer will do in that case.  

Thanks.   -Fong

Regarding <draft-ietf-mpls-generalized-signaling-04.txt>

1. In section 3, it says that "generalized label does not
   contain a type filed, instead the nodes are expected
   to know from context what type of label to expect".
   This principle is applied to all other label object
   except LABEL_SET. Is there a particular reason to 
   include "label type" (section 3.5.1) in LABEL_SET object ?

2. Section 3.1.1, why does LSP Enc. Type includes "Packet",
   "Ethernet V2/DIX", and "Ethernet 802.3" ? Aren't they all
   packet and their label type can be derived from its link ?
   If not, don't we also need ATM, FrameRelay in the code point,
   in particular section 3.2.1.2 "Other Labels" talks about
   ATM, FrameRelay labels.

   I have doubt as to whether we really need LSP encoding type
   since that is a service discovery issue and should
   be known before signaling, in particular in the context
   of RSVP where upstream selects the link. Can some one 
   explain the benefit of having it, besides from verifying
   the consistency of the request and the link type ?

3. Section 3.1.2 bandwidth encoding. The text said that 
   these bandwidth encoding does not apply to SONET/SDH
   technology. I believe they also do not apply to ANSI/ETSI
   PDH technology, for the same reason we exclude SONET/SDH. 
   Isn't it more precise to say which technology the bandwidth 
   encoding applies to ?

4. Section 3.2.1.1 Port and Wavelength Labels. The description 
   of "Label" using the term "sender" and "receiver". In RSVP
   these two terms have special meaning (upstream and downstream),
   so I am not clear whether "sender" means the sender of the
   (RESV) message or the "sender" of the LSP. This is particular
   troublesome when it is referenced, such as "The information
   carried in a suggested label is identical to a generalized
   label". Suggest to use "upstream" or "downstream".
    
5. Section 3.3 Waveband Switching. How do we
   distinguish 3 wavelength labels from waveband labels ?
   Or is this always used in conjunction with "lambda LSP" ?

   The text also said waveband Identifier is "The value is
   selected by the sender and reused in all subsequent related
   messages." What are the subsequent related message that 
   would include waveband identifier but not the waveband label 
   object ?

   The same issue with using "sender" here. Suggest use
   upstream or downstream. 

6. Section 3.5.1 Required Information for Label Set.
   Can each SubChannel x be a list of labels, 
   e.g. for an STS-12 each of them can include 12 SKLM
   values ? So, if I have 24 time slot that can be used
   for an STS-12 connection, I have to specify all combination
   that are allowed, or can I just specify the 24 SKLM 
   values as subchannel 1 when requesting a STS-12 connection ?
   If so, why do I need more than one "subchannels" ?

<draft-ietf-mpls-generalized-rsvp-te-03.txt>

1. section 2.1.2. Does it mean one must accept both "control load"
   and "guarantee service" in flowspec ?

2. section 5.1. Procedure for Explicit Label Control.
   The text said that "the preceding subobject must be a strict object",
   isn't it enough to say that "the preceding object must uniquely
   identify a link ?"

>  -----Original Message-----
>  From: George Swallow [mailto:[email-masked]]
>  Sent: Monday, May 14, 2001 10:52 AM
>  To: [email-masked]; [email-masked]
>  Subject: GMPLS Last Calls
>  
>  
>  This message initiates a last call on four GMPLS drafts.  The last
>  call is being issued jointly in the MPLS and CCAMP workgroups.
>  
>  The drafts are:
>  
>      1.  Generalized MPLS - Signaling Functional Description
>  
>             <draft-ietf-mpls-generalized-signaling-04.txt>
>  
>  
>      2.  Generalized MPLS Signaling - RSVP-TE Extensions
>  
>             <draft-ietf-mpls-generalized-rsvp-te-03.txt>
>  
>  
>      3.  Generalized MPLS Signaling - CR-LDP Extensions
>  
>             <draft-ietf-mpls-generalized-cr-ldp-03.txt>
>  
>  
>      4.  GMPLS Extensions for SONET and SDH Control
>  
>             <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>
>  
>  
>  The last call closes May 29, 12 pm GMT.
>  
>  
>  -  V2KG (Vijay, Vijay, Kireeti, & George)
>  
>  
>  =============================================================
>  =========
>  George Swallow       Cisco Systems                   (978) 244-8143
>                       250 Apollo Drive
>                       Chelmsford, Ma 01824
>  
>  
>  

Delivery-date: Wed, 16 May 2001 17:52:46 -0700
Date: Wed, 16 May 2001 20:50:16 -0400
From: Tom Scott <[email-masked]>
Organization: VedatelCo
To: CCAMP WG List <[email-masked]>
Subject: re: Network Models

Laurent,

A unified model of the Internet doesn't exist, yet. But it's reassuring
to know that you're interested in it.

Recall Bert and Scott's ascii art:

Applications         +-------+  +-------+        (new) Hour glass
that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                 \   +-------+  +-------+               /
                  \     +----------------------+       /
                   \    |         CCAMP        |      /
                    \   |-----------+----------|     /  
                    /   |   C       |    M   --|------ IGP LSA ext
                   /    | control   | measure  |     \  
                  /     +----------------------+      \
Technologies to  / +----+ +----+ +----+ +----+ +----+  \
measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                   +----+ +----+ +----+ +----+ +----+

As you indicate, to move in the direction of completeness one would
explicitly include: all three planes (user/data, control, management);
all four GMPLS transports (packets/cells, time slots, lambdas, strands);
a unified model of information flows including routing updates, policy
and SNMP-related exchanges; the unification of control and management
protocols called for in Maarten Vissers' CD (ASTN Layer Network
Architecture); the PWE3/MSS initiatives; and a few other things like
ASM/SDL analysis of it all ala sdl-forum.org (always leaving the
backdoor open). 

As indicated in the diagram above, the target application would be
traffic engineering, as specified in Jerry Ash's TE draft in a unified
next-generation SNMP framework.

-- From a logical point of view, TT
------------------/\----------------------
Tom Nelson Scott         1411 Sheffield Dr
VedatelCo           Bowling Green OH 43402
"Java/XML Rules"     "In IP/MPLS We Trust"
            "E Pluribus Fiber"  
------------------\/----------------------

-------- Original Message --------
Subject: [IP-Optical] Network Models
Date: Tue, 15 May 2001 10:07:54 +0200
From: Laurent Silvio Ciavaglia <[email-masked]>
Organization: Alcatel Research & Innovation
To: [email-masked], [email-masked],
[email-masked],[email-masked]

Dear all,

I am interested in finding information about network models, i.e. peer
vs overlay vs augmented or integrated... I am looking for some scenari
comparison + implications (routing, policing, TE, signaling) of such
models, how do network models fit in the GMPLS framework ?
If anyone can provide me with some pointers...

Regards
Laurent C.

Delivery-date: Wed, 16 May 2001 16:13:54 -0700
From: Hai Vodinh <[email-masked]>
To: 'Michael Waldo' <[email-masked]>
Cc: "'Mannie, Eric'" <[email-masked]>, [email-masked],  [email-masked], "Bernstein, Greg" <[email-masked]>
Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Wed, 16 May 2001 16:04:43 -0700

Michael,

Greg's (1) has the additional restriction of "one big signal within a single
SONET Line (SDH MS)" so it is not like Virtual Concatenation which has no
such restriction.  Base components (sts-1, sts-3c) of sonet vc signals can
have diverse paths.

Hai

-----Original Message-----
From: Michael Waldo [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 3:42 PM
To: Bernstein, Greg
Cc: 'Mannie, Eric'; [email-masked]; [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

your (1) sounds more like virtual concatenation to me

(2) is what I have considered to be arbitrary concatenation. This could be
useful when compared to standard contiguous concatenation because it could
make
more efficient use of the bandwidth within the SONET line (SDH MS) eg, using
an
STS-2c when only 100Mbs is needed. Standard contiguous concatenation payload
values being 3c, 12c, 48c, 192c for SONET.

Considering virtual concatenation, arbitrary concatenation doesn't seem to
have
as much appeal (pretty useless).

Has the term "arbitrary concatenation" been defined anywhere? I've seen
contiguous and virtual definitions, but I looked through the references in
this
draft, (as well as G.707 and T1.105) and I could not find the "arbitrary"
definition.

-Waldo

"Bernstein, Greg" wrote:

> We started out with the simple term "arbitrary concatenation" a while back
> to mean arbitrary in size and in timeslots used.  I'm not sure what was
> meant when we added the "contiguous" to this.  Was it:
> (1)     Treat this as one big signal within a single SONET Line (SDH MS),
> with potentially arbitrary timeslots used.
> (2)     Treat this as one big signal within a single SONET line (SDH MS),
> with the timeslot numbering lying within a single range, i.e.,  X through
Y,
> with X < Y.
>
> If (1) then we need a list of time slots. If (2) then only the beginning
> time slot is needed.  The problem with (2) is that it is a pretty useless
> feature, i.e., doesn't prevent the need for re-grooming and seemed like a
> mistake from the rather long gestation period for this specification
rather
> than something truly intended.
>
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
>
>                 -----Original Message-----
>                 From:   Mannie, Eric [mailto:[email-masked]]
>                 Sent:   Wednesday, May 16, 2001 12:44 PM
>                 To:     Bernstein, Greg; [email-masked]; [email-masked]
>                 Subject:        RE: Small issue on
> draft-ietf-ccamp-gmpls-sdh-00.txt
>
>                 Dear All,
>
>                 Sorry I was confused, the original text of the draft is
> correct:
>
>                 With any kind of ***contiguous*** concatenation there is
one
> big signal, so
>                 one and only one label (pointer) is needed (otherwise it
is
> not a contiguous
>                 concatenation). With any kind of virtual concatenation,
> there are several
>                 VC's, so one label (pointer) per VC is needed. Even if all
> the VC's
>                 virtually concatenated are contiguous (by coincidence) we
> still need to
>                 identify each of them.
>
>                 Arbitrary and standard concatenations are orthogonal with
> contiguous and
>                 virtual concatenations.
>
>                 Arbitrary means anything that is not standard.
>
>                 We use a code to differentiate between standard and
> arbitrary contiguous
>                 concatenation to avoid that a downstream node returns a
> timeslot at a
>                 position not supported by the upstream node. The upstream
> node indicates the
>                 number and types of signals to be concatenated and the
> downstream node
>                 cannot change it (it can just accept or refuse).
>
>                 We don't need a code to differentiate between standard
> versus arbitrary
>                 virtual concatenation because there is no restriction
anyway
> on the timeslot
>                 positions that can return the downstream node. Again, the
> upstream node
>                 indicates the number and types of signals to be
concatenated
> and the
>                 downstream node cannot change that (it can just accept or
> refuse). SDH 1996
>                 restricts the virtual concatenation to some well defined
> signals, while SDH
>                 2000 allows everything that make sense. But for the
previous
> reasons we
>                 don't need to differentiate between the two (thing about
the
> reason why you
>                 put a signaling element in a signaling message).
>
>                 Agreed ?
>
>                 Kind regards,
>
>                 Eric
>
>                 -----Original Message-----
>                 From: Bernstein, Greg [mailto:[email-masked]]
>                 Sent: Wednesday, May 16, 2001 5:33 PM
>                 To: [email-masked]; [email-masked]
>                 Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
>
>                 Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:
>
>                    In case of any type of contiguous concatenation (e.g.
> standard or
>                    arbitrary concatenation), only one label appears in the
> Label
>                    field. That label is the lowest signal of the
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
>
>                    In case of virtual concatenation, the explicit ordered
> list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the virtually concatenated signal.
>
>                 This does not reflect the intent of arbitrary
concatenation-
> arbitrary, size
>                 and placement of timeslots.  Otherwise the main benefit of
> arbitrary
>                 concatenation, preventing re-grooming is lost.  Corrected
> text could read:
>
>                     In the case of standard contiguous, only one label
> appears in the Label
>                    field. That label is the lowest signal of the standard
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
>
>                    In the cases of arbitrary or virtual concatenation, the
> explicit ordered
>                 list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the arbitrary or virtually concatenated
> signal.
>
>                 Greg B.
>                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                         New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 15:50:26 -0700
Date: Thu, 17 May 2001 00:49:12 +0200
From: Dimitri Papadimitriou <[email-masked]>
Organization: Alcatel Bell - IPO NSG
To: "Bernstein, Greg" <[email-masked]>
CC: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

This is a multi-part message in MIME format.
--------------A99028FA63B0C1DCE5A5AA37
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Greg et all,

By taking a look on the version -00 of the draft (published in October
2000 - at that time draft-ietf-mpls-generalized-signalling-00.txt 
includes sonet/sdh extensions) it was clearly mentioned "arbitrary 
contiguous concatenation" in the document !

[...]
Requested Grouping Type (RGT): 4 bits

This field indicates the SDH/SONET type of grouping requested
for the LSP, it is used to constraint the type of concatenation. 
The values are defined in the following table:

Value    Grouping type
-----    ----------------------------------
  0      (Implies no concatenation/bundling when RNC = RT = 0)
  1      Virtual concatenation         
  2      Contiguous standard concatenation             
  3      Contiguous arbitrary concatenation
  4      Inverse Multiplexing
[...]

So either i don't understand what "start out" means or you probably
refer to an older version of the document or...  but clearly the
meaning of "contiguous arbitrary concatenation" has not change since
then.

The reference at that time was the document draft-mack-crane-gmpls-
signaling-enhancements-00.txt - section 6.

[...]
Virtual concatenation requires co-routing and implies a bonding 
function at the endpoints of the group.  For contiguous standard 
concatenation, there must be a standard number of components 
(4, 16, 64, etc. for SDH; 3, 12, 48, etc. for SONET), and they 
must be in one higher order container. For contiguous arbitrary 
concatenation, the number of components is arbitrary (2, 3, 4, à) 
and they still must be routed in one higher order container.
[...]

However in your draft draft-bms-sdhsonet-mpls-control-frmwrk-00.txt      
(published in November 2000), you mention the term "flexible" or 
"arbitrary concatenation" in section 6.1.2:

[...]
Due to these disadvantages some SONET framer manufacturers now
support "flexible"  or  arbitrary concatenation, i.e., no restrictions
on the size of an STS-Mc (as long as M <= N) and no constraints on the
STS-1 timeslots used to convey it, i.e., the signals can use any 
combination of available time slots.
[...]

So, it does not surprise me that this discrepancy occurs... since
we speak about different types of concatenation and "arbitrary 
concatenation" is a third type of concatenation (in addition to 
contiguous and virtual concatenation defined in ITU-T/T1 standards) 

Regards,
Dimitri.

"Bernstein, Greg" wrote:
> 
> We started out with the simple term "arbitrary concatenation" a while back
> to mean arbitrary in size and in timeslots used.  I'm not sure what was
> meant when we added the "contiguous" to this.  Was it:
> (1)     Treat this as one big signal within a single SONET Line (SDH MS),
> with potentially arbitrary timeslots used.
> (2)     Treat this as one big signal within a single SONET line (SDH MS),
> with the timeslot numbering lying within a single range, i.e.,  X through Y,
> with X < Y.
> 
> If (1) then we need a list of time slots. If (2) then only the beginning
> time slot is needed.  The problem with (2) is that it is a pretty useless
> feature, i.e., doesn't prevent the need for re-grooming and seemed like a
> mistake from the rather long gestation period for this specification rather
> than something truly intended.
> 
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
> 
>                 -----Original Message-----
>                 From:   Mannie, Eric [mailto:[email-masked]]
>                 Sent:   Wednesday, May 16, 2001 12:44 PM
>                 To:     Bernstein, Greg; [email-masked]; [email-masked]
>                 Subject:        RE: Small issue on
> draft-ietf-ccamp-gmpls-sdh-00.txt
> 
>                 Dear All,
> 
>                 Sorry I was confused, the original text of the draft is
> correct:
> 
>                 With any kind of ***contiguous*** concatenation there is one
> big signal, so
>                 one and only one label (pointer) is needed (otherwise it is
> not a contiguous
>                 concatenation). With any kind of virtual concatenation,
> there are several
>                 VC's, so one label (pointer) per VC is needed. Even if all
> the VC's
>                 virtually concatenated are contiguous (by coincidence) we
> still need to
>                 identify each of them.
> 
>                 Arbitrary and standard concatenations are orthogonal with
> contiguous and
>                 virtual concatenations.
> 
>                 Arbitrary means anything that is not standard.
> 
>                 We use a code to differentiate between standard and
> arbitrary contiguous
>                 concatenation to avoid that a downstream node returns a
> timeslot at a
>                 position not supported by the upstream node. The upstream
> node indicates the
>                 number and types of signals to be concatenated and the
> downstream node
>                 cannot change it (it can just accept or refuse).
> 
>                 We don't need a code to differentiate between standard
> versus arbitrary
>                 virtual concatenation because there is no restriction anyway
> on the timeslot
>                 positions that can return the downstream node. Again, the
> upstream node
>                 indicates the number and types of signals to be concatenated
> and the
>                 downstream node cannot change that (it can just accept or
> refuse). SDH 1996
>                 restricts the virtual concatenation to some well defined
> signals, while SDH
>                 2000 allows everything that make sense. But for the previous
> reasons we
>                 don't need to differentiate between the two (thing about the
> reason why you
>                 put a signaling element in a signaling message).
> 
>                 Agreed ?
> 
>                 Kind regards,
> 
>                 Eric
> 
>                 -----Original Message-----
>                 From: Bernstein, Greg [mailto:[email-masked]]
>                 Sent: Wednesday, May 16, 2001 5:33 PM
>                 To: [email-masked]; [email-masked]
>                 Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
> 
>                 Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:
> 
>                    In case of any type of contiguous concatenation (e.g.
> standard or
>                    arbitrary concatenation), only one label appears in the
> Label
>                    field. That label is the lowest signal of the
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
> 
>                    In case of virtual concatenation, the explicit ordered
> list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the virtually concatenated signal.
> 
>                 This does not reflect the intent of arbitrary concatenation-
> arbitrary, size
>                 and placement of timeslots.  Otherwise the main benefit of
> arbitrary
>                 concatenation, preventing re-grooming is lost.  Corrected
> text could read:
> 
>                     In the case of standard contiguous, only one label
> appears in the Label
>                    field. That label is the lowest signal of the standard
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
> 
>                    In the cases of arbitrary or virtual concatenation, the
> explicit ordered
>                 list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the arbitrary or virtually concatenated
> signal.
> 
>                 Greg B.
>                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                         New phone: (510) 573-2237
--------------A99028FA63B0C1DCE5A5AA37
Content-Type: text/x-vcard; charset=us-ascii;
 name="dimitri.papadimitriou.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dimitri Papadimitriou
Content-Disposition: attachment;
 filename="dimitri.papadimitriou.vcf"

begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:[email-masked]
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard

--------------A99028FA63B0C1DCE5A5AA37--

Delivery-date: Wed, 16 May 2001 15:42:24 -0700
Date: Wed, 16 May 2001 17:41:38 -0500
From: Michael Waldo <[email-masked]>
To: "Bernstein, Greg" <[email-masked]>
CC: "'Mannie, Eric'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

your (1) sounds more like virtual concatenation to me

(2) is what I have considered to be arbitrary concatenation. This could be
useful when compared to standard contiguous concatenation because it could make
more efficient use of the bandwidth within the SONET line (SDH MS) eg, using an
STS-2c when only 100Mbs is needed. Standard contiguous concatenation payload
values being 3c, 12c, 48c, 192c for SONET.

Considering virtual concatenation, arbitrary concatenation doesn't seem to have
as much appeal (pretty useless).

Has the term "arbitrary concatenation" been defined anywhere? I've seen
contiguous and virtual definitions, but I looked through the references in this
draft, (as well as G.707 and T1.105) and I could not find the "arbitrary"
definition.

-Waldo

"Bernstein, Greg" wrote:

> We started out with the simple term "arbitrary concatenation" a while back
> to mean arbitrary in size and in timeslots used.  I'm not sure what was
> meant when we added the "contiguous" to this.  Was it:
> (1)     Treat this as one big signal within a single SONET Line (SDH MS),
> with potentially arbitrary timeslots used.
> (2)     Treat this as one big signal within a single SONET line (SDH MS),
> with the timeslot numbering lying within a single range, i.e.,  X through Y,
> with X < Y.
>
> If (1) then we need a list of time slots. If (2) then only the beginning
> time slot is needed.  The problem with (2) is that it is a pretty useless
> feature, i.e., doesn't prevent the need for re-grooming and seemed like a
> mistake from the rather long gestation period for this specification rather
> than something truly intended.
>
> Greg B.
>         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>         New phone: (510) 573-2237
>
>                 -----Original Message-----
>                 From:   Mannie, Eric [mailto:[email-masked]]
>                 Sent:   Wednesday, May 16, 2001 12:44 PM
>                 To:     Bernstein, Greg; [email-masked]; [email-masked]
>                 Subject:        RE: Small issue on
> draft-ietf-ccamp-gmpls-sdh-00.txt
>
>                 Dear All,
>
>                 Sorry I was confused, the original text of the draft is
> correct:
>
>                 With any kind of ***contiguous*** concatenation there is one
> big signal, so
>                 one and only one label (pointer) is needed (otherwise it is
> not a contiguous
>                 concatenation). With any kind of virtual concatenation,
> there are several
>                 VC's, so one label (pointer) per VC is needed. Even if all
> the VC's
>                 virtually concatenated are contiguous (by coincidence) we
> still need to
>                 identify each of them.
>
>                 Arbitrary and standard concatenations are orthogonal with
> contiguous and
>                 virtual concatenations.
>
>                 Arbitrary means anything that is not standard.
>
>                 We use a code to differentiate between standard and
> arbitrary contiguous
>                 concatenation to avoid that a downstream node returns a
> timeslot at a
>                 position not supported by the upstream node. The upstream
> node indicates the
>                 number and types of signals to be concatenated and the
> downstream node
>                 cannot change it (it can just accept or refuse).
>
>                 We don't need a code to differentiate between standard
> versus arbitrary
>                 virtual concatenation because there is no restriction anyway
> on the timeslot
>                 positions that can return the downstream node. Again, the
> upstream node
>                 indicates the number and types of signals to be concatenated
> and the
>                 downstream node cannot change that (it can just accept or
> refuse). SDH 1996
>                 restricts the virtual concatenation to some well defined
> signals, while SDH
>                 2000 allows everything that make sense. But for the previous
> reasons we
>                 don't need to differentiate between the two (thing about the
> reason why you
>                 put a signaling element in a signaling message).
>
>                 Agreed ?
>
>                 Kind regards,
>
>                 Eric
>
>                 -----Original Message-----
>                 From: Bernstein, Greg [mailto:[email-masked]]
>                 Sent: Wednesday, May 16, 2001 5:33 PM
>                 To: [email-masked]; [email-masked]
>                 Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
>
>                 Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:
>
>                    In case of any type of contiguous concatenation (e.g.
> standard or
>                    arbitrary concatenation), only one label appears in the
> Label
>                    field. That label is the lowest signal of the
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
>
>                    In case of virtual concatenation, the explicit ordered
> list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the virtually concatenated signal.
>
>                 This does not reflect the intent of arbitrary concatenation-
> arbitrary, size
>                 and placement of timeslots.  Otherwise the main benefit of
> arbitrary
>                 concatenation, preventing re-grooming is lost.  Corrected
> text could read:
>
>                     In the case of standard contiguous, only one label
> appears in the Label
>                    field. That label is the lowest signal of the standard
> contiguously
>                    concatenated signal. By lowest signal we mean the one
> having the
>                    lowest label when compared as integer values, i.e. the
> first
>                    component signal of the concatenated signal encountered
> when
>                    descending the tree.
>
>                    In the cases of arbitrary or virtual concatenation, the
> explicit ordered
>                 list of all
>                    labels in the concatenation is given. Each label
> indicates a
>                    component of the arbitrary or virtually concatenated
> signal.
>
>                 Greg B.
>                         Dr. Greg M. Bernstein, Senior Scientist, Ciena
>                         New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 15:08:03 -0700
From: "Bernstein, Greg" <[email-masked]>
To: "'Mannie, Eric'" <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Wed, 16 May 2001 15:05:58 -0700

We started out with the simple term "arbitrary concatenation" a while back
to mean arbitrary in size and in timeslots used.  I'm not sure what was
meant when we added the "contiguous" to this.  Was it:
(1)	Treat this as one big signal within a single SONET Line (SDH MS),
with potentially arbitrary timeslots used.
(2)	Treat this as one big signal within a single SONET line (SDH MS),
with the timeslot numbering lying within a single range, i.e.,  X through Y,
with X < Y.

If (1) then we need a list of time slots. If (2) then only the beginning
time slot is needed.  The problem with (2) is that it is a pretty useless
feature, i.e., doesn't prevent the need for re-grooming and seemed like a
mistake from the rather long gestation period for this specification rather
than something truly intended.

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

		-----Original Message-----
		From:	Mannie, Eric [mailto:[email-masked]]
		Sent:	Wednesday, May 16, 2001 12:44 PM
		To:	Bernstein, Greg; [email-masked]; [email-masked]
		Subject:	RE: Small issue on
draft-ietf-ccamp-gmpls-sdh-00.txt

		Dear All,

		Sorry I was confused, the original text of the draft is
correct:

		With any kind of ***contiguous*** concatenation there is one
big signal, so
		one and only one label (pointer) is needed (otherwise it is
not a contiguous
		concatenation). With any kind of virtual concatenation,
there are several
		VC's, so one label (pointer) per VC is needed. Even if all
the VC's
		virtually concatenated are contiguous (by coincidence) we
still need to
		identify each of them.

		Arbitrary and standard concatenations are orthogonal with
contiguous and
		virtual concatenations.

		Arbitrary means anything that is not standard.

		We use a code to differentiate between standard and
arbitrary contiguous
		concatenation to avoid that a downstream node returns a
timeslot at a
		position not supported by the upstream node. The upstream
node indicates the
		number and types of signals to be concatenated and the
downstream node
		cannot change it (it can just accept or refuse).

		We don't need a code to differentiate between standard
versus arbitrary
		virtual concatenation because there is no restriction anyway
on the timeslot
		positions that can return the downstream node. Again, the
upstream node
		indicates the number and types of signals to be concatenated
and the
		downstream node cannot change that (it can just accept or
refuse). SDH 1996
		restricts the virtual concatenation to some well defined
signals, while SDH
		2000 allows everything that make sense. But for the previous
reasons we
		don't need to differentiate between the two (thing about the
reason why you
		put a signaling element in a signaling message).

		Agreed ?

		Kind regards,

		Eric

		-----Original Message-----
		From: Bernstein, Greg [mailto:[email-masked]]
		Sent: Wednesday, May 16, 2001 5:33 PM
		To: [email-masked]; [email-masked]
		Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

		Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:

		   In case of any type of contiguous concatenation (e.g.
standard or
		   arbitrary concatenation), only one label appears in the
Label
		   field. That label is the lowest signal of the
contiguously
		   concatenated signal. By lowest signal we mean the one
having the
		   lowest label when compared as integer values, i.e. the
first
		   component signal of the concatenated signal encountered
when
		   descending the tree.

		   In case of virtual concatenation, the explicit ordered
list of all
		   labels in the concatenation is given. Each label
indicates a
		   component of the virtually concatenated signal.

		This does not reflect the intent of arbitrary concatenation-
arbitrary, size
		and placement of timeslots.  Otherwise the main benefit of
arbitrary
		concatenation, preventing re-grooming is lost.  Corrected
text could read:

		    In the case of standard contiguous, only one label
appears in the Label
		   field. That label is the lowest signal of the standard
contiguously
		   concatenated signal. By lowest signal we mean the one
having the
		   lowest label when compared as integer values, i.e. the
first
		   component signal of the concatenated signal encountered
when
		   descending the tree.

		   In the cases of arbitrary or virtual concatenation, the
explicit ordered
		list of all
		   labels in the concatenation is given. Each label
indicates a
		   component of the arbitrary or virtually concatenated
signal.

		Greg B.
			Dr. Greg M. Bernstein, Senior Scientist, Ciena 
			New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 13:30:51 -0700
From: "Saha, Sayandeb" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: UPSTREAM_COMPONENT_INTERFACE_ID  question 
Date: Wed, 16 May 2001 16:29:43 -0400

Kireeti,

draft-kompella-mpls-bundle-05.txt (section 5.2.1) speaks about the
UPSTREAM_COMPONENT_INTERFACE_ID object which is to be
included as a part of the <sender descriptor> for bidirectional LSPs
when using Explicit Indication by Unnumbered. This seems to be an
exception which allows one to specify a component for the upstream
traffic.
Specification of a component for upstream traffic is not supported for
other indication types in Bundling (Implicit Indication and Explicit
Indication by IP address), but instead is inferred.  Also in the
non-bundling
case, when signaling unnumbered interfaces, the ERO only includes 
the upstream router_id and the outgoing interface Id, again nothing about
the upstream link on which traffic should be carried.

My question:
What is the point in having a UPSTREAM_COMPONENT_INTERFACE_ID
for the Explicit Indication by Unnumbered case, when there is nothing
similar
for other cases?  Isn't the  DOWNSTREAM_COMPONENT_INTERFACE_ID 
enough to let us know which link should be selected for reverse direction of
the Bidirectional LSP? Am I missing something here?

-Sayan

Delivery-date: Wed, 16 May 2001 12:46:03 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Wed, 16 May 2001 21:44:12 +0200

Dear All,

Sorry I was confused, the original text of the draft is correct:

With any kind of ***contiguous*** concatenation there is one big signal, so
one and only one label (pointer) is needed (otherwise it is not a contiguous
concatenation). With any kind of virtual concatenation, there are several
VC's, so one label (pointer) per VC is needed. Even if all the VC's
virtually concatenated are contiguous (by coincidence) we still need to
identify each of them.

Arbitrary and standard concatenations are orthogonal with contiguous and
virtual concatenations.

Arbitrary means anything that is not standard.

We use a code to differentiate between standard and arbitrary contiguous
concatenation to avoid that a downstream node returns a timeslot at a
position not supported by the upstream node. The upstream node indicates the
number and types of signals to be concatenated and the downstream node
cannot change it (it can just accept or refuse).

We don't need a code to differentiate between standard versus arbitrary
virtual concatenation because there is no restriction anyway on the timeslot
positions that can return the downstream node. Again, the upstream node
indicates the number and types of signals to be concatenated and the
downstream node cannot change that (it can just accept or refuse). SDH 1996
restricts the virtual concatenation to some well defined signals, while SDH
2000 allows everything that make sense. But for the previous reasons we
don't need to differentiate between the two (thing about the reason why you
put a signaling element in a signaling message).

Agreed ?

Kind regards,

Eric

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 5:33 PM
To: [email-masked]; [email-masked]
Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:

   In case of any type of contiguous concatenation (e.g. standard or
   arbitrary concatenation), only one label appears in the Label
   field. That label is the lowest signal of the contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In case of virtual concatenation, the explicit ordered list of all
   labels in the concatenation is given. Each label indicates a
   component of the virtually concatenated signal.

This does not reflect the intent of arbitrary concatenation- arbitrary, size
and placement of timeslots.  Otherwise the main benefit of arbitrary
concatenation, preventing re-grooming is lost.  Corrected text could read:

    In the case of standard contiguous, only one label appears in the Label
   field. That label is the lowest signal of the standard contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In the cases of arbitrary or virtual concatenation, the explicit ordered
list of all
   labels in the concatenation is given. Each label indicates a
   component of the arbitrary or virtually concatenated signal.

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 10:36:03 -0700
From: "Mannie, Eric" <[email-masked]>
To: "'Bernstein, Greg'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Wed, 16 May 2001 19:34:14 +0200

Hi all,

That's right Greg, thanks.

I am guilty, I introduced this bug when I updated the text I believe. Sorry.

I'll correct it.

Kind regards,

Eric

-----Original Message-----
From: Bernstein, Greg [mailto:[email-masked]]
Sent: Wednesday, May 16, 2001 5:33 PM
To: [email-masked]; [email-masked]
Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt

Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:

   In case of any type of contiguous concatenation (e.g. standard or
   arbitrary concatenation), only one label appears in the Label
   field. That label is the lowest signal of the contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In case of virtual concatenation, the explicit ordered list of all
   labels in the concatenation is given. Each label indicates a
   component of the virtually concatenated signal.

This does not reflect the intent of arbitrary concatenation- arbitrary, size
and placement of timeslots.  Otherwise the main benefit of arbitrary
concatenation, preventing re-grooming is lost.  Corrected text could read:

    In the case of standard contiguous, only one label appears in the Label
   field. That label is the lowest signal of the standard contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In the cases of arbitrary or virtual concatenation, the explicit ordered
list of all
   labels in the concatenation is given. Each label indicates a
   component of the arbitrary or virtually concatenated signal.

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

Delivery-date: Wed, 16 May 2001 08:35:12 -0700
From: "Bernstein, Greg" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Small issue on draft-ietf-ccamp-gmpls-sdh-00.txt
Date: Wed, 16 May 2001 08:33:12 -0700

Hi in the draft draft-ietf-ccamp-gmpls-sdh-00.txt it says:

   In case of any type of contiguous concatenation (e.g. standard or
   arbitrary concatenation), only one label appears in the Label
   field. That label is the lowest signal of the contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In case of virtual concatenation, the explicit ordered list of all
   labels in the concatenation is given. Each label indicates a
   component of the virtually concatenated signal.

This does not reflect the intent of arbitrary concatenation- arbitrary, size
and placement of timeslots.  Otherwise the main benefit of arbitrary
concatenation, preventing re-grooming is lost.  Corrected text could read:

    In the case of standard contiguous, only one label appears in the Label
   field. That label is the lowest signal of the standard contiguously
   concatenated signal. By lowest signal we mean the one having the
   lowest label when compared as integer values, i.e. the first
   component signal of the concatenated signal encountered when
   descending the tree.

   In the cases of arbitrary or virtual concatenation, the explicit ordered
list of all
   labels in the concatenation is given. Each label indicates a
   component of the arbitrary or virtually concatenated signal.

Greg B.
	Dr. Greg M. Bernstein, Senior Scientist, Ciena 
	New phone: (510) 573-2237

Delivery-date: Tue, 15 May 2001 23:51:40 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: FW:  Non-member submission from [[email-masked]]   
Date: Wed, 16 May 2001 08:50:14 +0200

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Sent: 	Monday, May 14, 2001 1:35 PM
> To: 	[email-masked]
> Subject: 	BOUNCE [email-masked]:    Non-member submission from
> [[email-masked]]   
> 
> >From [email-masked] Mon May 14 04:35:03 2001
> Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
> 	by psg.com with esmtp (Exim 3.16 #1)
> 	id 14zGcw-0001el-00
> 	for [email-masked]; Mon, 14 May 2001 04:35:02 -0700
> Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
> 	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06937;
> 	Mon, 14 May 2001 07:34:53 -0400 (EDT)
> Message-Id: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: Multipart/Mixed; Boundary="NextPart"
> To: IETF-Announce: ;
> Cc: [email-masked]
> From: [email-masked]
> Reply-to: [email-masked]
> Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> Date: Mon, 14 May 2001 07:34:52 -0400
> Sender: [email-masked]
> 
> --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Common Control and Measurement Plane
> Working Group of the IETF.
> 
> 	Title		: GMPLS Extensions for SONET and SDH Control
> 	Author(s)	: E. Mannie et al.
> 	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 	Pages		: 18
> 	Date		: 11-May-01
> 	
> This document is a companion to the Generalized MPLS signaling
> documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines
> the SONET/SDH technology specific information needed when using
> GMPLS signaling.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.tx
> t
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> --OtherAccess
> Content-Type: Message/External-body;
> 	access-type="mail-server";
> 	server="[email-masked]"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> --OtherAccess
> Content-Type: Message/External-body;
> 	name="draft-ietf-ccamp-gmpls-sonet-sdh-00.txt";
> 	site="ftp.ietf.org";
> 	access-type="anon-ftp";
> 	directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID:	<[email-masked]>
> 
> --OtherAccess--
> 
> --NextPart--
> 
> 
> 
> 

Delivery-date: Tue, 15 May 2001 20:17:04 -0700
From: [email-masked]
Reply-to: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Tue, 15 May 2001 20:14:50 -0700

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS Extensions for SONET and SDH Control
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
	Pages		: 18
	Date		: 11-May-01
	
This document is a companion to the Generalized MPLS signaling
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines
the SONET/SDH technology specific information needed when using
GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 15 May 2001 09:23:49 -0700
To: [email-masked]
From: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [[email-masked]]   
Date: Mon, 14 May 2001 04:35:03 -0700

>From [email-masked] Mon May 14 04:35:03 2001
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
Date: Mon, 14 May 2001 07:34:52 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS Extensions for SONET and SDH Control
	Author(s)	: E. Mannie et al.
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
	Pages		: 18
	Date		: 11-May-01
	
This document is a companion to the Generalized MPLS signaling
documents, [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP].  It defines
the SONET/SDH technology specific information needed when using
GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 15 May 2001 07:56:48 -0700
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 15 May 2001 16:53:50 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Original-CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: ASTN Layer Network Architecture

This is a multi-part message in MIME format.
--------------649D95B4D06CFFD96338287E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tammy,

Thanks for your comments. See below for my thoughts...

[email-masked] wrote:
> 
> Maarten,
> I found your contribution very helpful and I have some
> comments/questions.
> 
> 1) You said Network Engineering does:
> ***
> Monitored are how much of the available links are utilized. After
> reaching a threshold (which could be % utilization & rate of change of
> utilization & possibly also # of failed connection attempts), a request
> to the server LNCP is made for new trails. Network engineering should
> also monitor the bandwidth demand from a source/destination
> relationship, in order to identify the traffic patterns in the network.
> Where necessary, a layer network's architecture can be optimised by
> e.g. adding direct links between two heavily interconnected nodes.
> Decisions are taken based on policies set by the network operator.
> It is also worth being able to calculate the number of current open
> connections and the maximum number of open connections allowed (due to
> limits in either capacity or connection identifiers). To do network
> engineering you need to know something about the average holding time
> of the connection and the call request rate
> ***
> But I currently see these as traffic engineering functions.
> 
> You said Traffic Engineering does:
> ***
> - creates connections in the LNCP interconnecting the layer network
> links via matrix connections in the fabrics
> ****
> But I currently see these as network engineering functions.

It seems we have opposite understandings here. 
"Network engineering" for me relates to engineering the (layer) network,
i.e. making sure all necessary resources are available. Resources that
can be managed by the (automatic) network engineering process are the
links of the layer network.

"Traffic engineering" on the other hand relates to engineering the
traffic flows, i.e. making sure that the network is utilised to the
highest degree possible, to maximize throughput (increases customer
satisfaction) and profit (increases operator satisfaction).

It seems strange for me, to specify the opposite "network engineering
engineers the traffic flows" and "traffic engineering engineers the
network"...

> 
> 2) In figure 3, you show 3 different sized boxes for the different
> connection types contained with in each other.  It is not clear to me
> why the containment relationship and why they are different sizes.  Do
> the sizes reflect the expected ratios for the different types of
> connections?

Agree. The outer blue box (PC) should be shrunk, and not longer include
the other two boxes (SC, SPC). The PC and SC set are complementary now,
and have no overlap. The SPC set is a subset of the SC set, and the SPC
box will thus be smaller than the SC box. No further meaning is tried to
be reflected by the size of the boxes (but we may start a contest,
predict the percentages of the 3 connection types in e.g. 2007 and bury
it under a tree in Turin... :-)  ).

I will adapt the figure accordingly.

> 
> 3) I think the answer to the question in figure 4 is yes.  I would
> expect that as traffic and service requirements change over time,
> network resources will move between the management and control plane
> control.

OK. Consequential question is now if this is a feature that belongs
already to the first phase of ASON, or to a later phase?

> 
> 4) You have identified a pamLockedLinkCapacity.  I would like you to
> consider extending the definition to be pamMaintenanceLinkCapacity so
> that it will include all Links that are disabled as well as locked and
> possibly those under test.

I assumed that pamLockedLinkCapacity would reflect the number of link
connections in the administrative state "locked", and that a link
connection could enter this state for multiple reasons. 

I expected to trigger you here :-) as you introduced this capability
last year (during ODUk-LCK signal definition and application study) to
me. Perhaps you can take the lead here and create a complete
definition...

As far as I can see we have the 
- "administrative state" (7.1.3/X.731) with its states "unlocked",
"shutting down" and "locked"
- "operational state" (7.1.1/X.731) with its states "disabled" and
"enabled" ==> is this operational state implied when you referred to
"link (connection?)s that are disabled"?
- "usage state" (7.1.2/X.731) with its states "idle", "active" and
"busy" ==> isn't this more extensively represented by the four "pamXXX"
parameters in G.853.8? I.e. can we ignore this state?

Is pamMaintenanceLinkCapacity the best term representing all
applications as well as its usage in the traffic engineering process?
The pamMaintenanceLinkCapacity represents the number of link connections
which are currently not accessible by the routing process within traffic
engineering.

We need to define the rules for pamMaintenanceLinkCapacity (or other
term); i.e. when is its value increased, decreased and which other
pamXXX values are then consequentially decreased/increased.

Up to now:
	pamMaximumLinkCapacity =	pamPotentialLinkCapacity +
					pamProvisionedLinkCapacity +
					pamAvailableLinkCapacity

Will pamMaintenanceLinkCapacity be just an extra term in this
expression? E.g. 
	pamMaximumLinkCapacity =	pamPotentialLinkCapacity +
					pamProvisionedLinkCapacity +
					pamAvailableLinkCapacity +
					pamMaintenanceLinkCapacity

If the above will be the case, how would we address the "shutting down"
situation; if there are e.g. 5 link connections in shutting down state,
then they are still ProvisionedLinkCapacity and at the same time also
MaintenanceLinkCapacity... most likely we can ignore this detail and
consider that these e.g. 5 link connections are not longer part of
ProvisionedLinkCapacity.

What contributes to pamMaintenanceLinkCapacity? E.g. number of link
connections in admin states locked and shutting down, number of link
connections in operational state disabled, ... other?

The operational state "disabled" represents the number of link
connections that are "DOWN" (i.e. failed), we do not have to bother with
additional parameters indicting that a particular link has e.g. lost 90%
of its capacity to the a network failure... that sounds nice...

> 
> 5) In the case of the SPC, where there is sharing of provisioning
> between the control plane and the management plane, which one is
> responsible for verification of connectivity and clean-up from failed
> set-up and release operations?  I think somewhere we need to have a
> discussion of this interaction.

The control plane is responsible. The management plane has handed all
info necessary to the control plane; see also as a first example annex
E. Also when the SPC is released, the managmeent plane initiates the
release, but the control plane is responsible for correct release.

> 
> 6) I was thinking that it might be nice to be able to set up a primary
> route in the management plane (e.g. PC) and a protection route in the
> control plane (e.g. SPC).  Currently this seems to present coordination
> problems. Is this something that would be worth further investigation?

I think this is very problematic. Protection requires route diversity,
and if you use two different instances (MP, CP) for the two routes, I
don't see how route diversity can be obtained.

> 
> 7) It seems to me that the UNI brings up the subject of Service
> management which you have not addressed in this contribution.  This is
> not to reflect negatively on the contribution as you have covered quite
> a lot of material with this contribution.  I was just wondering what
> your thoughts were about this going forward.

I haven't arrived at this yet... I have had some discussions with some
of my colleagues on billing principles (use of performance monitoring
information); i.e. use of tandem connection monitoring or of
differential PM (case no TCM is available)...

Can you present some more of your thoughts behind service management...
might be helpful as we move forward to have a first reference that we
can consider at each step.

> 
> Tammy

Regards,

Maarten
--------------649D95B4D06CFFD96338287E
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:[email-masked]
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------649D95B4D06CFFD96338287E--

Envelope-to: [email-masked]
Delivery-date: Mon, 14 May 2001 10:57:50 -0700
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: GMPLS Last Calls
Date: Mon, 14 May 2001 13:52:23 -0400
From: George Swallow <[email-masked]>

This message initiates a last call on four GMPLS drafts.  The last
call is being issued jointly in the MPLS and CCAMP workgroups.

The drafts are:

    1.  Generalized MPLS - Signaling Functional Description

           <draft-ietf-mpls-generalized-signaling-04.txt>

    2.  Generalized MPLS Signaling - RSVP-TE Extensions

           <draft-ietf-mpls-generalized-rsvp-te-03.txt>

    3.  Generalized MPLS Signaling - CR-LDP Extensions

           <draft-ietf-mpls-generalized-cr-ldp-03.txt>

    4.  GMPLS Extensions for SONET and SDH Control

           <draft-ietf-ccamp-gmpls-sonet-sdh-00.txt>

The last call closes May 29, 12 pm GMT.

-  V2KG (Vijay, Vijay, Kireeti, & George)

======================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

Delivery-date: Sun, 13 May 2001 09:28:27 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: Call for volunteers for Requirements Design Team
Date: Sun, 13 May 2001 18:27:22 +0200

Call for volunteers for Requirements Design Team

We have had various discussion about one or more design teams.
And we have had verbal calls for volunteers, however, it seems
we have not yet done a call for volunteers on any mailing list.

So lets re-start.

We have decided that we want one "Design Team" in the TEWG. 
The team will collect and publish an initial set of requirements
as Internet Draft(s). These requirements will feed into TEWG, 
CCAMP and IPO, possibly other working groups.

This is the mission we want to give the team (Thanks Rob) is to
collect requirements for:

 Network Hierarchy:
   Network hierarchy in this context refers to abstraction of
   part of a network's topology and the routing and signaling 
   mechanism needed to support the topological abstraction. 
   Abstraction may be used as a mechanism to build large 
   networks or as a technique for enforcing administrative, 
   topological or geographic boundaries. For example, network 
   hierarchy might be used to separate the metropolitan and 
   long-haul regions of a network or to separate the regional
   and backbone sections of a network.

 Survivability Techniques
   Survivability techniques refers to the numerous methods to 
   restore service when a network failure occurs. A specific 
   method may be used throughout an entire network or a per-LSP
   basis; some of the techniques may be implemented in hardware.
   Survivability techniques may be on a per-link basis or on a 
   per-path basis.

We are looking for volunteers who are OPERATORS. It is not that
we do not like vendors but we feel that it is important to have
people who will be useing the technology say what they think 
are the requirements.  Everyone will get a chance to comment 
on the drafts in the normal WG way.
The volunteers should be willing to commit to all of this:
 
   - evaluate requirements that people put forward to the DT,
   - contribute their own requirments to the team
   - write/contribute text to the internet draft to serve as
     the output of th2 DT. This I-D will then go to the TE-WG
     for WG evaluation.

The time frame is as follows:

- Volunteers need to respond to Scott ([email-masked]) and
  Bert ([email-masked]) by next Friday (May 18th). 
  Pls send an email with 

     subjectline: Volunteer for TEWG DT
     In body of email: 
        explain why you qualify and how much time you can make
        available between now and July 1st.
  
  It would be good if those who think they volunteered before will
  also send such an email, so as to make sure you are still
  on the list of volunteers.

- Design team selected and announced by ADs and WG chairs
  before May 23rd.

- Mailing list to collect input will be establised b May 23rd, 
  Anyone can send in requirements up till June 1st. You can 
  start to prepare your sugegstion now and make sure that you 
  document the requirement and the motivation/justification 
  for the requirement.

- Design team will evaluate requirements and documents and will
  prioritize them in a Internet Draft. 

- Design team will publishe I-D by June 21st as input to TE-WG

- TEWG will discuss this I-D on mailing lists and try to get 
  consensus on the final requirements before London IETF.

The Design Team will do a lot of discussions/evalueations via email.
We leave it up to the DT to decide if they need conference calls
and/or a face-to-face meeting.

Bert and Scott

Envelope-to: [email-masked]
Delivery-date: Sun, 13 May 2001 06:28:32 -0700
Date: Sun, 13 May 2001 09:24:07 -0400 (EDT)
From: Scott Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked]
Subject: REMINDER! - iID summaries due soon

reminder - we need these summaries by next Friday - otherwise we will
assume that we do not need to worry about the ID

also - you need to be specific in where you think the ID fits - just saying
"fits in MPLS" is not enough - say where in the MPLS work

Scott & Bert

---------------------------------------------
All, but specifically I-D Authors/Editors

Over the last several months, we have seen A LOT of I-Ds submitted/posted
which appear to be targeted for one or more WGs in the new sub-IP area.
(ccamp, gsmp, ipo, iporpr, tewg, mpls and ppvpn) These are mostly
individual I-Ds, that is those that do not start with 
        draft-ietf-<someWgName>
but this mesage referrs to ALL I-Ds related to the Sub IP WGs.
In fact we believe we have some 200-300 of such documents.

It is sort of impossible to try and read them all and decide in which WG
(if any) they might fit. So in order to help us (WG chairs and ADs) to 
work our way through all these documents, we want the AUTHORS/EDITORS of 
such existing documents to do the following:

- Before May 18th, pls send ONE SINGLE email per I-D to the email alias
  
       [email-masked]

  That email should be formatted and contain content as
  explained below.

  Pls DO NOT send these emails to any WG mailing list. 

  The idsummary mailing list will be archived publically at 

      ftp://subip.ietf.org/pub/lists/idsummary*

  Since these are non-WG documents (yet) any comments/discussion
  can/should take place at: 

      [email-masked]

  But initially the idea is to just collect the data.

- When doing a revision of these documents or writing a new I-D,
  please pls add a section at the beginning of your document that contains
  the same information we are asking for here so that readers of your
  document can also see it.

All these emails will be archived and the WG chairs, ADs, Technical
Advisors
and Directorate will review them and report back (target is end of May)
what we want to do with each of the documents.

If we do not receive a note about an I-D we will assume that the I-D
authors/editors do not intend to publish it as a RFC.

Further, if you assume this pictorial overview of the work we are doing
in the sub-IP area, then pls indicate where in the picture your document
fits.

   --- pictorial overview of work in the sup-IP area --------------

  The Working Groups at the top are those that will use the
  Common Control and Measurement Protocols that we're 
  defining in the CCAMP WG.

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

  The technologies at the bottom allow us to create paths and so those
  are the ones we want to measure and control via the Common Control
  and Measurement Protocols coming out of CCAMP. One of those 
  technologies (MPLS) is defined by IETF, others are (have been) defined 
  in other standards organisations. However, we want to focus mainly on 
  the use of such technologies for IP.

  So for example the IPO and IPORPR WGs are assumed to be active at 
  the bottom because we want to focus on the IP use of such technologies.

Bert and Scott
--------------------
The ONE SINGLE email per I-D should be as follows:

-  Subject: <targetWgName> <nameOfID>
   
   the targetWgName is the WG that you as authors/editors
   think that this document should live in. If you have no specific
   WG as the target WG, then use subIP as the name.

   the nameOfID is the filename of the draft, e.g. draft-xxx-yyy-zzz-00.txt

- In the body of the email must have the following sections with these 
  section titles:

NAME OF I-D:

  Write it down as a URL so we can click on it to see it.  e.g. 

  http://www.ietf.org/internet-drafts/draft-xxx-yyy-zzz-00.txt

SUMMARY

  This should contain a summary of the content of the document
  Potentially it can be the abstract. But pls make sure that it helps
  the reader undestand what the document is all about.
  PLEASE TRY TO KEEP IT DOWN TO TWO PARAGRAPHS

RELATED DOCUMENTS

  A list of URLs for other I-Ds (or non-IETF documents) that you think
relate,
  compete, complement or overlap with your document.  "none" if none

WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

WHY IS IT TARGETED AT THIS WG

  You must explain how the ID addresses a workitem in the current WG
  charter as listed on the WG charter page on the IETF web site. If
  it addresses only part of a work item, then please explain if there
  are other documents that could be merged with this one to become one
  document to address the complete work item.

JUSTIFICATION

  Why do you think it is justified for the WG to consider this document.

  In the case that you cannot explain how this document addresses
  a specific WG charter work item, then explain and justify why the
  WG should even consider this work and what the description of 
  a possible new work item would be for the WG. Suggest possible
  milestones for that work item.

  Please realize, that new work items need wide support within a
  WG, but also they need agreement from the WG chairs and ADs,
  and even when they get that, the whole IESG and IAB must review and
  approve new-work items before they get added to a WG charter.

  Please understand that we already have a lot of work in our WG
  charters, and that we would rather see that finished (or at least
  be well undeway) before we undertake any new work items.

Delivery-date: Thu, 10 May 2001 11:00:56 -0700
Date: Thu, 10 May 2001 13:42:54 +0200
From: Maarten Vissers <[email-masked]>
Subject: Re: Question about logical link in Link bundling
To: "Fong, Man Wing" <[email-masked]>
Cc: Debanjan Saha <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], 'Kireeti Kompella' <[email-masked]>, [email-masked]
Organization: Lucent Technologies
Original-CC: Debanjan Saha <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_SrJ8usdlRRZOdH8gEI15PA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Man Wing,

The virtual concatenation capability included in the transport NEs is
targeted to support pay-as-you-grow ethernet connections through the
transport network, which ingress/egress the transport network via
physical ethernet interfaces (10M, 100M, 1G, 10G). This capability is
not intended (at least not in today's view) to support an OC12c (STM-4
with VC-4-4c) as ingress/egress physical interface to the transport
network.

The fact that the transport NEs are extended with this virtual
concatenation capability is an intermediate step (early availibility) in
the pay-as-you-grow ethernet connections offer. The final step should
bring the virtual concatenation endpoints to the routers again, such
that in the emerging automatic switched transport network, routers can
dial up additional (or release superfluous) bandwidth, in a hitless
manner (using LCAS from the endpoints).

This will keep the OC12 (in general OC-N) interfaces on the routers
(using VSR optics similar to those used in ehternet today), and removes
the need to perform an additional conversion in the ingress/egress ports
of the transport network (saving costs also here). In addition, the
routers are now again free in selecting the protocol between them
(IP/ethernet, IP/PPP/HDLC, IP/PPP/GFP, MPLS/GFP, IP/ATM, ...) while the
transport network will transparently pass through the virtual
concatenated signal including(its payload with the particular protocol).

Regards,

Maarten

"Fong, Man Wing" wrote:
> 
> Maarten,
> 
> Very good point and description. The last case that you describe using VC
> would be a good alternative to support the bandwidth on demand. Now that the
> inverse muxing capability is being transferred from the router to the
> transport NEs. In this case, (Debanjan, you're right), the user would use an
> OC-12c interface on a router instead of the channelized OC-12 interface to
> save cost for this application (BOD).
> 
> Thanks,
> Man Wing
> 
>  -----Original Message-----
> From:   Maarten Vissers [mailto:[email-masked]]
> Sent:   Wednesday, May 09, 2001 5:06 AM
> To:     Debanjan Saha
> Cc:     'Fong, Man Wing'; Bala Rajagopalan; [email-masked]; 'Kireeti Kompella';
> [email-masked]
> Subject:        Re: Question about logical link in Link bundling
> 
>  << File: Card for Maarten Vissers >> Debanjan,
> 
> Just a thought... those 12 DS3s terminating on the same router (and
> providing access to 12 MPLS links) may terminate at the other ends on 12
> different routers. With one physical (OC12) interface you have now made
> (with the help of the transport network) connections with 12 other
> routers. Very cost effective...
> 
> Ofcourse you don't need a DS3 to be present in the STS1 is the router at
> the other end of the transport network has a EC1 of (channelised) OC-N
> interface. In this case you may deploy direct mapping of MPLS into STS1
> payload (via PPP/HDLC or the new GFP encapsulation).
> 
> One further cost reduction step (for the case there are e.g. only 5
> other routers connected) is to use STS1 virtual concatenation with GFP
> encapsulation of MPLS. You can now size each of the 5 STS pipes between
> 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12.
> 
> Regards,
> 
> Maarten
> 
> Debanjan Saha wrote:
> >
> > Fong,
> > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
> > However, if all of them are terminating on
> > the same LSR, I'm not sure why you'll use a channelized
> > OC-12 and not an OC-12c.
> >
> > Debanjan

--Boundary_(ID_SrJ8usdlRRZOdH8gEI15PA)
Content-type: text/x-vcard; name=mvissers.vcf; charset=us-ascii
Content-description: Card for Maarten Vissers
Content-disposition: attachment; filename=mvissers.vcf
Content-transfer-encoding: 7BIT

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--Boundary_(ID_SrJ8usdlRRZOdH8gEI15PA)--

Delivery-date: Thu, 10 May 2001 10:41:40 -0700
Date: Thu, 10 May 2001 10:37:36 -0700
From: Sudheer Dharanikota <[email-masked]>
Reply-To: [email-masked]
Organization: Nayna Networks, Inc.
To: Martin Dubuc <[email-masked]>
CC: [email-masked], Jonathan Lang <[email-masked]>, George Young <[email-masked]>
Subject: Re: Question on LMP

Hi Guys:

I know we can use the addresses from the IP packet for this
use.. unless the source IP address is changed in the middle
by things like NAT ( :-) ).

But if you look at protocols like RSVP or OSPF - they have
sufficient information in their PDUs to do the demultiplexing.
For example, RSVP sender template and OSPF router ID (in the
common message header) can do this job.

Don't you think it is worth following the path taken by the
experianced guys.. and put some demux informtion in the LMP
PDU itself?

Cheers,

sudheer

Martin Dubuc wrote:

> Sudheer,
> 
> Local source IP address is not part of the LMP message, but it is part of
> the IP packet in which the LMP message is contained.
> 
> Martin
> 
> -----Original Message-----
> From: Sudheer Dharanikota [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2001 6:55 PM
> To: [email-masked]
> Subject: Question on LMP
> 
> 
> I have a small question/clarification needed on LMP...
> 
> How does the LMP determine from where the (Link summary etc.)
> packets are received if the remote CCId or local source IP
> address is not part of the LMP packets?
> 
> THank you for the help.
> 
> - sudheer

Delivery-date: Thu, 10 May 2001 09:29:39 -0700
From: Jonathan Lang <[email-masked]>
To: 'Martin Dubuc' <[email-masked]>, George Young <[email-masked]>, 'Sudheer Dharanikota' <[email-masked]>,  [email-masked], Jonathan Lang <[email-masked]>
Subject: RE: Question on LMP
Date: Thu, 10 May 2001 09:25:21 -0700

Martin,
  As you suggest (and as per the discussion in Minneapolis) we have further
decoupled the dependence of the control channel from the data-bearing links
by removing the CCId from the link-specific messages.  The source IP address
identifies the originator of the LMP message.

-Jonathan

> -----Original Message-----
> From: Martin Dubuc [mailto:[email-masked]]
> Sent: Thursday, May 10, 2001 8:04 AM
> To: George Young; 'Sudheer Dharanikota'; [email-masked]; Jonathan
> Lang (E-mail)
> Subject: RE: Question on LMP
> 
> 
> George,
> 
> I have heard that in the upcoming version of LMP draft, there 
> won't be any
> Control Channel Id field in the LinkSummary message.
> 
> This change was requested because there is no one-to-one 
> association between
> TE links and individual control channels in version 02 of 
> LMP. All control
> channels between a node pair manage all TE links between the 
> same node pair
> at the same level. LinkSummary message for a TE link could be 
> sent on any of
> the control channels. As such, the Control Channel Id field in the
> LinkSummary message is not as much required.
> 
> If one can rely on the source IP address of the LMP message 
> to identify the
> originator of the message - given that it is easy to map the source IP
> address to the Node ID, then this should solve the problem. However,
> thinking about it some more, I am not sure this assumption is right.
> 
> Any comments on that Jonathan?
> 
> Martin 
> 
> -----Original Message-----
> From: George Young [mailto:[email-masked]]
> Sent: Thursday, May 10, 2001 10:04 AM
> To: 'Sudheer Dharanikota'; [email-masked]
> Subject: RE: Question on LMP
> 
> 
> Hello Sudheer,
> 
> The Config and ConfigAck Messages contain a Node ID which 
> allows correlation
> with the Control Channel Id.
> 
> Regards,
> George.
> 
> -----Original Message-----
> From: Sudheer Dharanikota [mailto:[email-masked]]
> Sent: Wednesday, May 09, 2001 6:55 PM
> To: [email-masked]
> Subject: Question on LMP
> 
> 
> I have a small question/clarification needed on LMP...
> 
> How does the LMP determine from where the (Link summary etc.)
> packets are received if the remote CCId or local source IP
> address is not part of the LMP packets?
> 
> THank you for the help.
> 
> - sudheer
> 

Delivery-date: Thu, 10 May 2001 08:11:33 -0700
From: Martin Dubuc <[email-masked]>
To: George Young <[email-masked]>, 'Sudheer Dharanikota' <[email-masked]>, [email-masked], "Jonathan Lang (E-mail)" <[email-masked]>
Subject: RE: Question on LMP
Date:  Thu, 10 May 2001 11:04:10 -0400

George,

I have heard that in the upcoming version of LMP draft, there won't be any
Control Channel Id field in the LinkSummary message.

This change was requested because there is no one-to-one association between
TE links and individual control channels in version 02 of LMP. All control
channels between a node pair manage all TE links between the same node pair
at the same level. LinkSummary message for a TE link could be sent on any of
the control channels. As such, the Control Channel Id field in the
LinkSummary message is not as much required.

If one can rely on the source IP address of the LMP message to identify the
originator of the message - given that it is easy to map the source IP
address to the Node ID, then this should solve the problem. However,
thinking about it some more, I am not sure this assumption is right.

Any comments on that Jonathan?

Martin 

-----Original Message-----
From: George Young [mailto:[email-masked]]
Sent: Thursday, May 10, 2001 10:04 AM
To: 'Sudheer Dharanikota'; [email-masked]
Subject: RE: Question on LMP

Hello Sudheer,

The Config and ConfigAck Messages contain a Node ID which allows correlation
with the Control Channel Id.

Regards,
George.

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 6:55 PM
To: [email-masked]
Subject: Question on LMP

I have a small question/clarification needed on LMP...

How does the LMP determine from where the (Link summary etc.)
packets are received if the remote CCId or local source IP
address is not part of the LMP packets?

THank you for the help.

- sudheer

Delivery-date: Thu, 10 May 2001 07:12:27 -0700
From: George Young <[email-masked]>
To: 'Sudheer Dharanikota' <[email-masked]>, [email-masked]
Subject: RE: Question on LMP
Date:  Thu, 10 May 2001 10:04:17 -0400

Hello Sudheer,

The Config and ConfigAck Messages contain a Node ID which allows correlation
with the Control Channel Id.

Regards,
George.

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 6:55 PM
To: [email-masked]
Subject: Question on LMP

I have a small question/clarification needed on LMP...

How does the LMP determine from where the (Link summary etc.)
packets are received if the remote CCId or local source IP
address is not part of the LMP packets?

THank you for the help.

- sudheer

Delivery-date: Thu, 10 May 2001 06:05:56 -0700
From: Martin Dubuc <[email-masked]>
To: 'Sudheer Dharanikota' <[email-masked]>, [email-masked]
Subject: RE: Question on LMP
Date:  Thu, 10 May 2001 09:00:06 -0400

Sudheer,

Local source IP address is not part of the LMP message, but it is part of
the IP packet in which the LMP message is contained.

Martin

-----Original Message-----
From: Sudheer Dharanikota [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 6:55 PM
To: [email-masked]
Subject: Question on LMP

I have a small question/clarification needed on LMP...

How does the LMP determine from where the (Link summary etc.)
packets are received if the remote CCId or local source IP
address is not part of the LMP packets?

THank you for the help.

- sudheer

Delivery-date: Thu, 10 May 2001 04:44:28 -0700
Cc: Debanjan Saha <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Date: Thu, 10 May 2001 13:42:54 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Fong, Man Wing" <[email-masked]>
Original-CC: Debanjan Saha <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Question about logical link in Link bundling

This is a multi-part message in MIME format.
--------------FC9EDFA8EF9D477928E13512
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Man Wing,

The virtual concatenation capability included in the transport NEs is
targeted to support pay-as-you-grow ethernet connections through the
transport network, which ingress/egress the transport network via
physical ethernet interfaces (10M, 100M, 1G, 10G). This capability is
not intended (at least not in today's view) to support an OC12c (STM-4
with VC-4-4c) as ingress/egress physical interface to the transport
network.

The fact that the transport NEs are extended with this virtual
concatenation capability is an intermediate step (early availibility) in
the pay-as-you-grow ethernet connections offer. The final step should
bring the virtual concatenation endpoints to the routers again, such
that in the emerging automatic switched transport network, routers can
dial up additional (or release superfluous) bandwidth, in a hitless
manner (using LCAS from the endpoints).

This will keep the OC12 (in general OC-N) interfaces on the routers
(using VSR optics similar to those used in ehternet today), and removes
the need to perform an additional conversion in the ingress/egress ports
of the transport network (saving costs also here). In addition, the
routers are now again free in selecting the protocol between them
(IP/ethernet, IP/PPP/HDLC, IP/PPP/GFP, MPLS/GFP, IP/ATM, ...) while the
transport network will transparently pass through the virtual
concatenated signal including(its payload with the particular protocol).

Regards,

Maarten

"Fong, Man Wing" wrote:
> 
> Maarten,
> 
> Very good point and description. The last case that you describe using VC
> would be a good alternative to support the bandwidth on demand. Now that the
> inverse muxing capability is being transferred from the router to the
> transport NEs. In this case, (Debanjan, you're right), the user would use an
> OC-12c interface on a router instead of the channelized OC-12 interface to
> save cost for this application (BOD).
> 
> Thanks,
> Man Wing
> 
>  -----Original Message-----
> From:   Maarten Vissers [mailto:[email-masked]]
> Sent:   Wednesday, May 09, 2001 5:06 AM
> To:     Debanjan Saha
> Cc:     'Fong, Man Wing'; Bala Rajagopalan; [email-masked]; 'Kireeti Kompella';
> [email-masked]
> Subject:        Re: Question about logical link in Link bundling
> 
>  << File: Card for Maarten Vissers >> Debanjan,
> 
> Just a thought... those 12 DS3s terminating on the same router (and
> providing access to 12 MPLS links) may terminate at the other ends on 12
> different routers. With one physical (OC12) interface you have now made
> (with the help of the transport network) connections with 12 other
> routers. Very cost effective...
> 
> Ofcourse you don't need a DS3 to be present in the STS1 is the router at
> the other end of the transport network has a EC1 of (channelised) OC-N
> interface. In this case you may deploy direct mapping of MPLS into STS1
> payload (via PPP/HDLC or the new GFP encapsulation).
> 
> One further cost reduction step (for the case there are e.g. only 5
> other routers connected) is to use STS1 virtual concatenation with GFP
> encapsulation of MPLS. You can now size each of the 5 STS pipes between
> 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12.
> 
> Regards,
> 
> Maarten
> 
> Debanjan Saha wrote:
> >
> > Fong,
> > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
> > However, if all of them are terminating on
> > the same LSR, I'm not sure why you'll use a channelized
> > OC-12 and not an OC-12c.
> >
> > Debanjan
--------------FC9EDFA8EF9D477928E13512
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------FC9EDFA8EF9D477928E13512--

Delivery-date: Wed, 09 May 2001 17:31:57 -0700
From: "manoj juneja" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: GMPLS Doubts...
Date: Wed, 09 May 2001 17:30:18 -0700

Hi All,

I have gone through the draft-ietf-mpls-generalized-signaling-03.txt and 
draft-ietf-mpls-generalized-cr-ldp-02.txt drafts. I have certain doubts 
regarding these drafts.

1.  It is mentioned in the draft that label set may be either restricted to 
a single hop or the whole LSP path. Can u please clarify
that this decision should be based on what criteria or it is just a local 
node decision.

2. It is mentioned that LSP characteristics may be used by transit
nodes e.g. to support PHP (section 3.1). Can u please explain how ?
Is this case only possible in PSC ?

3. In section 3.1.1, it is written that lambda encoding type refers
to switching of wavelengths. Does it also include the waveband ? Why
there is not a separate LSP encoding type as waveband ? How does a
transit node can identify that a waveband label is requested instead of a 
lambda label ?

4. In section 3.3.1, it is mentioned that waveband Id is selected by
the sender and reused in all subsequent related messages. Can u please
clarify that what are all those subsequent messages ?

5. In section 3.5, four different cases are explained where the
label set concept may be useful. Can u please calrify the 4th case
further ?

6. Is waveband Id locally signifcant i.e. between the two adjacent
nodes or is it globally unique for whole LSP path ?

7. Can the generalized label TLV be present in Label Release/Withdraw 
messages ?

8. Is there any new draft coming on O-UNI from IETF ?

11. Is anybody defining the clear interworking between O-UNI and GMPLS ?

12. In section 5, it is mentioned that acceptable label set may be present 
in notification message to indicate what all labels are acceptable ?
Can u please clarify what actions a node have to take once it receives the 
notification message with acceptable label set ?

Please help me in understanding these drafts.

Thanks,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Delivery-date: Wed, 09 May 2001 15:56:22 -0700
Date: Wed, 09 May 2001 15:54:55 -0700
From: Sudheer Dharanikota <[email-masked]>
Organization: Nayna Networks, Inc.
To: [email-masked]
Subject: Question on LMP

I have a small question/clarification needed on LMP...

How does the LMP determine from where the (Link summary etc.)
packets are received if the remote CCId or local source IP
address is not part of the LMP packets?

THank you for the help.

- sudheer

Envelope-to: [email-masked]
Delivery-date: Wed, 09 May 2001 11:56:08 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "Edward Harrison" <[email-masked]>, <[email-masked]>, "Thomas D. Nadeau" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: GMPLS TE MIB
Date: Wed, 9 May 2001 14:49:56 -0400

Thanks Dan,

Yes, we're aware of this issue and are discussing it.  The current 64 bit field
is something of a place holder.

Our concerns are
- to allow flexible configuration of different label types
- to keep the MIB from sprawling
- to arrive at a label type that can be used to index a GMPLS LSR MIB

Best regards,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, May 09, 2001 1:12 PM
Subject: RE: GMPLS TE MIB

> Hi Adrian,
>
>  The SYNTAX of the MplsGeneralizedLabel TC specifies a fixed length of
> 64 bits. This conflicts with the GMPLS functional specification which
> defines a generalized label as being of variable length. The SYNTAX
> is inconsistent with the length of the Waveband label, for example.
>
> -Dan

Delivery-date: Wed, 09 May 2001 10:23:58 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: RE: GMPLS TE MIB
Date: Wed, 9 May 2001 13:12:14 -0400 

Hi Adrian,

 The SYNTAX of the MplsGeneralizedLabel TC specifies a fixed length of
64 bits. This conflicts with the GMPLS functional specification which
defines a generalized label as being of variable length. The SYNTAX
is inconsistent with the length of the Waveband label, for example.

-Dan 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 10:06 AM
To: [email-masked]; [email-masked]
Subject: GMPLS TE MIB

We have submitted a draft to extend the TE-MIB to support
GMPLS.
This is available at
http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp
ls-te-mib-00.txt

We would welcome your thoughts and comments

Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]

Delivery-date: Wed, 09 May 2001 08:20:19 -0700
From: "Fong, Man Wing" <[email-masked]>
To: 'Maarten Vissers' <[email-masked]>, Debanjan Saha <[email-masked]>
Cc: "Fong, Man Wing" <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], 'Kireeti Kompella' <[email-masked]>, [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Wed, 9 May 2001 10:16:05 -0500 

Maarten, 

Very good point and description. The last case that you describe using VC
would be a good alternative to support the bandwidth on demand. Now that the
inverse muxing capability is being transferred from the router to the
transport NEs. In this case, (Debanjan, you're right), the user would use an
OC-12c interface on a router instead of the channelized OC-12 interface to
save cost for this application (BOD). 

Thanks,
Man Wing

 -----Original Message-----
From: 	Maarten Vissers [mailto:[email-masked]] 
Sent:	Wednesday, May 09, 2001 5:06 AM
To:	Debanjan Saha
Cc:	'Fong, Man Wing'; Bala Rajagopalan; [email-masked]; 'Kireeti Kompella';
[email-masked]
Subject:	Re: Question about logical link in Link bundling

 << File: Card for Maarten Vissers >> Debanjan,

Just a thought... those 12 DS3s terminating on the same router (and
providing access to 12 MPLS links) may terminate at the other ends on 12
different routers. With one physical (OC12) interface you have now made
(with the help of the transport network) connections with 12 other
routers. Very cost effective... 

Ofcourse you don't need a DS3 to be present in the STS1 is the router at
the other end of the transport network has a EC1 of (channelised) OC-N
interface. In this case you may deploy direct mapping of MPLS into STS1
payload (via PPP/HDLC or the new GFP encapsulation).

One further cost reduction step (for the case there are e.g. only 5
other routers connected) is to use STS1 virtual concatenation with GFP
encapsulation of MPLS. You can now size each of the 5 STS pipes between
1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12.

Regards,

Maarten

Debanjan Saha wrote:
> 
> Fong,
> You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
> However, if all of them are terminating on
> the same LSR, I'm not sure why you'll use a channelized
> OC-12 and not an OC-12c.
> 
> Debanjan

Delivery-date: Wed, 09 May 2001 08:19:17 -0700
From: "Fong, Man Wing" <[email-masked]>
To: 'Debanjan Saha' <[email-masked]>, "Fong, Man Wing" <[email-masked]>, Bala Rajagopalan <[email-masked]>,  [email-masked], 'Kireeti Kompella' <[email-masked]>
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Wed, 9 May 2001 10:14:17 -0500 

Debanjan,

As I mentioned in the email, the key is to provide bandwidth on demand.
Certainly, if the user needs the STS-12c link up all the time, the OC-12c
interface will make more sense. However, if the user doesn't need it all the
time, the OC-12c interface will tie the whole STS-12c BW. So that applying
link bundling on the channelized OC-12 interface can bundle a few channels
to create the right size link the user need between the routers, and the
unused STSs within the transport network can be used in somewhere else. 

What do you think?

Man Wing

 -----Original Message-----
From: 	Debanjan Saha [mailto:[email-masked]] 
Sent:	Tuesday, May 08, 2001 7:25 PM
To:	'Fong, Man Wing'; Bala Rajagopalan; [email-masked]; 'Kireeti Kompella'
Cc:	[email-masked]
Subject:	RE: Question about logical link in Link bundling

Fong,
You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
However, if all of them are terminating on
the same LSR, I'm not sure why you'll use a channelized
OC-12 and not an OC-12c.

Debanjan

-----Original Message-----
From: Fong, Man Wing [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 5:04 PM
To: 'Bala Rajagopalan'; [email-masked]; 'Kireeti Kompella'
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling

Bala,

Correct me if I am wrong. For my understanding, a channelized OC-12
interface can support 12 channels (12 logical DS3 interfaces). Some even
capable of defining logical interface within those DS3 channel to support
T1. Then, each logical DS3 interfaces can create a (logical) link to the
remote routers' DS3 interfaces. The original used of the channelized OC-12
interface is to reduce the cabling and additional equipment cost and labor
cost at the central location. Since it is a channelized interface, I
believe, it would not allow the user to use it as an OC-12c interface. By
applying link bundling on that, now you can size your pipe whatever you want
upto the maximum BW (in this case, it will be STS-12c). In addition, using
O-UNI, you will get a true bandwidth on demand.

Just a thought.

Man Wing

 

Envelope-to: [email-masked]
Delivery-date: Wed, 09 May 2001 07:14:19 -0700
Message-ID: <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: GMPLS TE MIB
Date: Wed, 9 May 2001 10:06:21 -0400

We have submitted a draft to extend the TE-MIB to support
GMPLS.
This is available at
http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp
ls-te-mib-00.txt

We would welcome your thoughts and comments

Adrian
--
Adrian Farrel
Movaz Networks Inc.
[email-masked]

Delivery-date: Wed, 09 May 2001 03:06:49 -0700
Cc: "'Fong, Man Wing'" <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Date: Wed, 09 May 2001 12:06:23 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: Debanjan Saha <[email-masked]>
Original-CC: "'Fong, Man Wing'" <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Question about logical link in Link bundling

This is a multi-part message in MIME format.
--------------7178821E76A65B83EA95C59F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Debanjan,

Just a thought... those 12 DS3s terminating on the same router (and
providing access to 12 MPLS links) may terminate at the other ends on 12
different routers. With one physical (OC12) interface you have now made
(with the help of the transport network) connections with 12 other
routers. Very cost effective... 

Ofcourse you don't need a DS3 to be present in the STS1 is the router at
the other end of the transport network has a EC1 of (channelised) OC-N
interface. In this case you may deploy direct mapping of MPLS into STS1
payload (via PPP/HDLC or the new GFP encapsulation).

One further cost reduction step (for the case there are e.g. only 5
other routers connected) is to use STS1 virtual concatenation with GFP
encapsulation of MPLS. You can now size each of the 5 STS pipes between
1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12.

Regards,

Maarten

Debanjan Saha wrote:
> 
> Fong,
> You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
> However, if all of them are terminating on
> the same LSR, I'm not sure why you'll use a channelized
> OC-12 and not an OC-12c.
> 
> Debanjan
> 
> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2001 5:04 PM
> To: 'Bala Rajagopalan'; [email-masked]; 'Kireeti Kompella'
> Cc: [email-masked]
> Subject: RE: Question about logical link in Link bundling
> 
> Bala,
> 
> Correct me if I am wrong. For my understanding, a channelized OC-12
> interface can support 12 channels (12 logical DS3 interfaces). Some even
> capable of defining logical interface within those DS3 channel to support
> T1. Then, each logical DS3 interfaces can create a (logical) link to the
> remote routers' DS3 interfaces. The original used of the channelized OC-12
> interface is to reduce the cabling and additional equipment cost and labor
> cost at the central location. Since it is a channelized interface, I
> believe, it would not allow the user to use it as an OC-12c interface. By
> applying link bundling on that, now you can size your pipe whatever you want
> upto the maximum BW (in this case, it will be STS-12c). In addition, using
> O-UNI, you will get a true bandwidth on demand.
> 
> Just a thought.
> 
> Man Wing
> 
>  -----Original Message-----
> From:   Bala Rajagopalan [mailto:[email-masked]]
> Sent:   Tuesday, May 08, 2001 3:24 PM
> To:     'Fong, Man Wing'; [email-masked]; 'Kireeti Kompella'
> Cc:     [email-masked]
> Subject:        RE: Question about logical link in Link bundling
> 
> Hello,
> 
> I'm a bit confused by the question. If you
> had a channelized OC-12 link, wouldn't you
> just advertise it with suitable Min Reservable
> Bw values to indicate that it can carry lower
> granularity traffic? In other words, why would
> you introduce the notion of a "logical" link
> in this case?
> 
> REgards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked]
> 
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Monday, April 30, 2001 3:31 PM
> > To: [email-masked]; 'Kireeti Kompella'
> > Cc: [email-masked]
> > Subject: Question about logical link in Link bundling
> >
> >
> > Hi All,
> >
> > From "draft-kompella-mpls-bundle-05.txt", it indicates that
> > multiple links
> > between two LSRs can be bundled as a single link to improve
> > the routing
> > scalability. Apparently, it can be used to bundle multiple links from
> > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> > etc...) to be a single link. However, can it be used to
> > bundle logical links
> > like T1s in channelized T3, or DS3s, STS-3c in channelized
> > OC-12 interface?
> >
> > Thanks.
> >
> > Regards,
> > Man Wing
> >
> >
> >
--------------7178821E76A65B83EA95C59F
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------7178821E76A65B83EA95C59F--

Delivery-date: Wed, 09 May 2001 02:56:17 -0700
Cc: "'Bala Rajagopalan'" <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Date: Wed, 09 May 2001 11:53:47 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
To: "Fong, Man Wing" <[email-masked]>
Original-CC: "'Bala Rajagopalan'" <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Question about logical link in Link bundling

This is a multi-part message in MIME format.
--------------700A3D4014597873ABD418F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Man Wing,

An OC12 interface port (when connect to another OC12 interface port)
provides what is called a "topological link" in ITU-T Rec. G.852.2 to
its client (HOVC/STS) layer network. This topological link supports one
or more HOVC/STS link connections, as expressed in terms defined in
G.853.8 "pre-provisioned adaptation management":

- pamMaxProvisionableCapacity: The pamMaxProvisionableCapacity attribute
provides the value that represents the maximum capacity that could be
provisioned for a link from the server trail of this link. However, this
maximum may not be provisioned for this link if several links are
supported by the same server trail: in this case, they are sharing the
maximum capacity.

- pamPotentialLinkCapacity: The pamPotentialLinkCapacity attribute
provides a value that represents the potential capacity that could be
provisioned on a link from the capacity that has not already been
provisioned from the server trail of this link.

- pamProvisionedLinkCapacity: The pamProvisionedLinkCapacity attribute
provides the capacity provisioned on a link.

- pamAvailableLinkCapacity: The pamAvailableLinkCapacity attribute
represents the provisioned capacity that is not assigned.

For an OC12, the following may be supported:

- example 1 - STS1, STS3c and STS12c supported:
pamMaxProvisionableCapacity:	STS1: 12;	STS3c: 4;	STS12c: 1
pamPotentialLinkCapacity: 	STS1: 12;	STS3c: 4;	STS12c: 1
pamProvisionedLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0
pamAvailableLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0

- example 2 - only STS3c supported:
pamMaxProvisionableCapacity:	STS1: 0;	STS3c: 4;	STS12c: 0
pamPotentialLinkCapacity: 	STS1: 0;	STS3c: 4;	STS12c: 0
pamProvisionedLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0
pamAvailableLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0

- example 3 - STS1 and STS12c supported:
pamMaxProvisionableCapacity:	STS1: 12;	STS3c: 0;	STS12c: 1
pamPotentialLinkCapacity: 	STS1: 12;	STS3c: 0;	STS12c: 1
pamProvisionedLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0
pamAvailableLinkCapacity:  	STS1: 0;	STS3c: 0;	STS12c: 0

The above examples are assuming an initial situation in which none of
the link connections is already providing service. For the case 1 STS1
and 1 STS3c link connection are providing service example 1 would have
its parameters presented as:

- example 1 - STS1, STS3c and STS12c supported and 1 STS1 and 1 STS3c
link connection used:
pamMaxProvisionableCapacity:	STS1: 12;	STS3c: 4;	STS12c: 1
pamPotentialLinkCapacity: 	STS1: 6;	STS3c: 2;	STS12c: 0
pamProvisionedLinkCapacity:  	STS1: 1;	STS3c: 1;	STS12c: 0
pamAvailableLinkCapacity:  	STS1: 2;	STS3c: 0;	STS12c: 0

See for more examples my ASTN layer network architecture document.

Note that DS3's, T1's, etc are not visible at this point in the layer
network structure. 
The HOVC/STS layer network deals with VC3/STS1, VC4/STS3c,
VC-4-4c/STS12c, VC-4-16c/STS48c, VC-4-64c/STS192c and VC-4-256c/STS768c
signals and groups of these signals (AUG-X/STSG-X, groups supporting
virtual concatenation, other groups).
In addition, these signals may be terminated in trail termination points
(TTP) within an Access Group (AG), providing access to its client
signals. Such client signals can be a e.g. DS3, E4, ATM, ethernet, IP,
MPLS and LOVC/VT signals.

For the case the HOVC/STS layer network connects two STS1 or two VC4
ports, the STS1 or VC4 path that is now present provides e.g. a LOVC/VT
topological link to the LOVC/VT layer network. 
Alternatively, if the payload would have been ATM, it would have
provided a ATM VP topological link to the ATM VP layer network. 
For the case the payload would have been DS3, it would have provided a
DS3 link connection to e.g. a customer.

In the LOVC/VT layer network T1's are not directly visible either. It
are the VC11/VT1.5, VC12, VC3 signal and groups of these signals. Only
when such signal is terminated in a TTP within an AG in this layer
network, access to its client signals (e.g. a T1) is provided.

So for the LOVC/VT layer entwork, STS1 and VC4 are the interface ports
providing LOVC/VT (topological) links. some examples:

For a VC4, the following may be supported:

- example 1 - VC11/VT1.5, VC12 and VC3 supported:
pamMaxProvisionableCapacity:	VC11/VT1.5: 84;	VC12: 63;	VC3: 3
pamPotentialLinkCapacity: 	VC11/VT1.5: 84;	VC12: 63;	VC3: 3
pamProvisionedLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0
pamAvailableLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0

- example 2 - VC12 and VC3 supported:
pamMaxProvisionableCapacity:	VC11/VT1.5: 0;	VC12: 63;	VC3: 3
pamPotentialLinkCapacity: 	VC11/VT1.5: 0;	VC12: 63;	VC3: 3
pamProvisionedLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0
pamAvailableLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0

- example 1 - VC11/VT1.5, VC12 and VC3 supported and 1 VC12 and 1 VC3
link connection:
pamMaxProvisionableCapacity:	VC11/VT1.5: 84;	VC12: 63;	VC3: 3
pamPotentialLinkCapacity: 	VC11/VT1.5: 52;	VC12: 39;	VC3: 1
pamProvisionedLinkCapacity:  	VC11/VT1.5: 0;	VC12: 1;	VC3: 0
pamAvailableLinkCapacity:  	VC11/VT1.5: 0;	VC12: 2;	VC3: 0

Now consider that there is one OC12 and one OC48 connection between the
two network elements. This would create an additional HOVC/STS
topological link supported by the OC48 connection. Assume that this OC48
supports from STS1 to STS48c, then the HOVC/STS link (i.e. the "bundle"
in GMPLS terminology) would be characterised as follows:

- example 1b - STS1, STS3c and STS12c supported on OC12 and STS1 to
STS48c supported on OC48:
pamMaxProvisionableCapacity:	STS1: 60; STS3c: 20; STS12c: 5;	STS48c: 1
pamPotentialLinkCapacity: 	STS1: 60; STS3c: 20; STS12c: 5;	STS48c: 1
pamProvisionedLinkCapacity:  	STS1: 0;  STS3c: 0;  STS12c: 0;	STS48c: 1
pamAvailableLinkCapacity:  	STS1: 0;  STS3c: 0;  STS12c: 0;	STS48c: 1

If instead of one VC4 also one STS1 path is present, an additional
LOVC/VT topological link would be provided by the STS1 path to the
LOVC/VT layer network. If this STS1 supports VT1.5 only, the LOVC/VT
link (i.e. the "bundle" in GMPLS terminology) would be characterised as
follows:

- example 2b - VC12 and VC3 supported on VC4 and VT1.5 on STS1:
pamMaxProvisionableCapacity:	VC11/VT1.5: 28;	VC12: 63;	VC3: 3
pamPotentialLinkCapacity: 	VC11/VT1.5: 28;	VC12: 63;	VC3: 3
pamProvisionedLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0
pamAvailableLinkCapacity:  	VC11/VT1.5: 0;	VC12: 0;	VC3: 0

Hope this helps understanding the multi layer aspects as well as
"bundling".

Regards,

Maarten

"Fong, Man Wing" wrote:
> 
> Bala,
> 
> Correct me if I am wrong. For my understanding, a channelized OC-12
> interface can support 12 channels (12 logical DS3 interfaces). Some even
> capable of defining logical interface within those DS3 channel to support
> T1. Then, each logical DS3 interfaces can create a (logical) link to the
> remote routers' DS3 interfaces. The original used of the channelized OC-12
> interface is to reduce the cabling and additional equipment cost and labor
> cost at the central location. Since it is a channelized interface, I
> believe, it would not allow the user to use it as an OC-12c interface. By
> applying link bundling on that, now you can size your pipe whatever you want
> upto the maximum BW (in this case, it will be STS-12c). In addition, using
> O-UNI, you will get a true bandwidth on demand.
> 
> Just a thought.
> 
> Man Wing
> 
>  -----Original Message-----
> From:   Bala Rajagopalan [mailto:[email-masked]]
> Sent:   Tuesday, May 08, 2001 3:24 PM
> To:     'Fong, Man Wing'; [email-masked]; 'Kireeti Kompella'
> Cc:     [email-masked]
> Subject:        RE: Question about logical link in Link bundling
> 
> Hello,
> 
> I'm a bit confused by the question. If you
> had a channelized OC-12 link, wouldn't you
> just advertise it with suitable Min Reservable
> Bw values to indicate that it can carry lower
> granularity traffic? In other words, why would
> you introduce the notion of a "logical" link
> in this case?
> 
> REgards,
> 
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: [email-masked]
> 
> > -----Original Message-----
> > From: Fong, Man Wing [mailto:[email-masked]]
> > Sent: Monday, April 30, 2001 3:31 PM
> > To: [email-masked]; 'Kireeti Kompella'
> > Cc: [email-masked]
> > Subject: Question about logical link in Link bundling
> >
> >
> > Hi All,
> >
> > From "draft-kompella-mpls-bundle-05.txt", it indicates that
> > multiple links
> > between two LSRs can be bundled as a single link to improve
> > the routing
> > scalability. Apparently, it can be used to bundle multiple links from
> > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> > etc...) to be a single link. However, can it be used to
> > bundle logical links
> > like T1s in channelized T3, or DS3s, STS-3c in channelized
> > OC-12 interface?
> >
> > Thanks.
> >
> > Regards,
> > Man Wing
> >
> >
> >
--------------700A3D4014597873ABD418F9
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------700A3D4014597873ABD418F9--

Delivery-date: Tue, 08 May 2001 17:23:53 -0700
From: Debanjan Saha <[email-masked]>
To: "'Fong, Man Wing'" <[email-masked]>, Bala Rajagopalan <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Tue, 8 May 2001 20:24:49 -0400 

Fong,
You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it.
However, if all of them are terminating on
the same LSR, I'm not sure why you'll use a channelized
OC-12 and not an OC-12c.

Debanjan

-----Original Message-----
From: Fong, Man Wing [mailto:[email-masked]]
Sent: Tuesday, May 08, 2001 5:04 PM
To: 'Bala Rajagopalan'; [email-masked]; 'Kireeti Kompella'
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling

Bala,

Correct me if I am wrong. For my understanding, a channelized OC-12
interface can support 12 channels (12 logical DS3 interfaces). Some even
capable of defining logical interface within those DS3 channel to support
T1. Then, each logical DS3 interfaces can create a (logical) link to the
remote routers' DS3 interfaces. The original used of the channelized OC-12
interface is to reduce the cabling and additional equipment cost and labor
cost at the central location. Since it is a channelized interface, I
believe, it would not allow the user to use it as an OC-12c interface. By
applying link bundling on that, now you can size your pipe whatever you want
upto the maximum BW (in this case, it will be STS-12c). In addition, using
O-UNI, you will get a true bandwidth on demand.

Just a thought.

Man Wing

 -----Original Message-----
From: 	Bala Rajagopalan [mailto:[email-masked]] 
Sent:	Tuesday, May 08, 2001 3:24 PM
To:	'Fong, Man Wing'; [email-masked]; 'Kireeti Kompella'
Cc:	[email-masked]
Subject:	RE: Question about logical link in Link bundling

Hello,

I'm a bit confused by the question. If you
had a channelized OC-12 link, wouldn't you
just advertise it with suitable Min Reservable
Bw values to indicate that it can carry lower
granularity traffic? In other words, why would
you introduce the notion of a "logical" link
in this case? 

REgards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 3:31 PM
> To: [email-masked]; 'Kireeti Kompella'
> Cc: [email-masked]
> Subject: Question about logical link in Link bundling
> 
> 
> Hi All,
> 
> From "draft-kompella-mpls-bundle-05.txt", it indicates that 
> multiple links
> between two LSRs can be bundled as a single link to improve 
> the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to 
> bundle logical links
> like T1s in channelized T3, or DS3s, STS-3c in channelized 
> OC-12 interface?
> 
> Thanks.
> 
> Regards,
> Man Wing
> 
> 
> 

Delivery-date: Tue, 08 May 2001 15:13:15 -0700
From: "Fong, Man Wing" <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>, [email-masked],  'Kireeti Kompella' <[email-masked]>
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Tue, 8 May 2001 17:10:30 -0500 

Of course, the routers connected to the optical network will use the
channelized interfaces.

Man Wing

 -----Original Message-----
From: 	Fong, Man Wing [mailto:[email-masked]] 
Sent:	Tuesday, May 08, 2001 5:04 PM
To:	'Bala Rajagopalan'; [email-masked]; 'Kireeti Kompella'
Cc:	[email-masked]
Subject:	RE: Question about logical link in Link bundling

Bala,

Correct me if I am wrong. For my understanding, a channelized OC-12
interface can support 12 channels (12 logical DS3 interfaces). Some even
capable of defining logical interface within those DS3 channel to support
T1. Then, each logical DS3 interfaces can create a (logical) link to the
remote routers' DS3 interfaces. The original used of the channelized OC-12
interface is to reduce the cabling and additional equipment cost and labor
cost at the central location. Since it is a channelized interface, I
believe, it would not allow the user to use it as an OC-12c interface. By
applying link bundling on that, now you can size your pipe whatever you want
upto the maximum BW (in this case, it will be STS-12c). In addition, using
O-UNI, you will get a true bandwidth on demand.

Just a thought.

Man Wing

 -----Original Message-----
From: 	Bala Rajagopalan [mailto:[email-masked]] 
Sent:	Tuesday, May 08, 2001 3:24 PM
To:	'Fong, Man Wing'; [email-masked]; 'Kireeti Kompella'
Cc:	[email-masked]
Subject:	RE: Question about logical link in Link bundling

Hello,

I'm a bit confused by the question. If you
had a channelized OC-12 link, wouldn't you
just advertise it with suitable Min Reservable
Bw values to indicate that it can carry lower
granularity traffic? In other words, why would
you introduce the notion of a "logical" link
in this case? 

REgards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 3:31 PM
> To: [email-masked]; 'Kireeti Kompella'
> Cc: [email-masked]
> Subject: Question about logical link in Link bundling
> 
> 
> Hi All,
> 
> From "draft-kompella-mpls-bundle-05.txt", it indicates that 
> multiple links
> between two LSRs can be bundled as a single link to improve 
> the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to 
> bundle logical links
> like T1s in channelized T3, or DS3s, STS-3c in channelized 
> OC-12 interface?
> 
> Thanks.
> 
> Regards,
> Man Wing
> 
> 
> 

Delivery-date: Tue, 08 May 2001 15:06:58 -0700
From: "Fong, Man Wing" <[email-masked]>
To: 'Bala Rajagopalan' <[email-masked]>, [email-masked],  'Kireeti Kompella' <[email-masked]>
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Tue, 8 May 2001 17:04:09 -0500 

Bala,

Correct me if I am wrong. For my understanding, a channelized OC-12
interface can support 12 channels (12 logical DS3 interfaces). Some even
capable of defining logical interface within those DS3 channel to support
T1. Then, each logical DS3 interfaces can create a (logical) link to the
remote routers' DS3 interfaces. The original used of the channelized OC-12
interface is to reduce the cabling and additional equipment cost and labor
cost at the central location. Since it is a channelized interface, I
believe, it would not allow the user to use it as an OC-12c interface. By
applying link bundling on that, now you can size your pipe whatever you want
upto the maximum BW (in this case, it will be STS-12c). In addition, using
O-UNI, you will get a true bandwidth on demand.

Just a thought.

Man Wing

 -----Original Message-----
From: 	Bala Rajagopalan [mailto:[email-masked]] 
Sent:	Tuesday, May 08, 2001 3:24 PM
To:	'Fong, Man Wing'; [email-masked]; 'Kireeti Kompella'
Cc:	[email-masked]
Subject:	RE: Question about logical link in Link bundling

Hello,

I'm a bit confused by the question. If you
had a channelized OC-12 link, wouldn't you
just advertise it with suitable Min Reservable
Bw values to indicate that it can carry lower
granularity traffic? In other words, why would
you introduce the notion of a "logical" link
in this case? 

REgards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 3:31 PM
> To: [email-masked]; 'Kireeti Kompella'
> Cc: [email-masked]
> Subject: Question about logical link in Link bundling
> 
> 
> Hi All,
> 
> From "draft-kompella-mpls-bundle-05.txt", it indicates that 
> multiple links
> between two LSRs can be bundled as a single link to improve 
> the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to 
> bundle logical links
> like T1s in channelized T3, or DS3s, STS-3c in channelized 
> OC-12 interface?
> 
> Thanks.
> 
> Regards,
> Man Wing
> 
> 
> 

Delivery-date: Tue, 08 May 2001 13:24:35 -0700
From: Bala Rajagopalan <[email-masked]>
To: "'Fong, Man Wing'" <[email-masked]>, [email-masked], "'Kireeti Kompella'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Question about logical link in Link bundling
Date: Tue, 8 May 2001 16:24:00 -0400 

Hello,

I'm a bit confused by the question. If you
had a channelized OC-12 link, wouldn't you
just advertise it with suitable Min Reservable
Bw values to indicate that it can carry lower
granularity traffic? In other words, why would
you introduce the notion of a "logical" link
in this case? 

REgards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Place
P.O. Box 901
Oceanport, NJ 07757-0901
Tel: (732) 923-4237
Fax: (732) 923-9804
Email: [email-masked] 

> -----Original Message-----
> From: Fong, Man Wing [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 3:31 PM
> To: [email-masked]; 'Kireeti Kompella'
> Cc: [email-masked]
> Subject: Question about logical link in Link bundling
> 
> 
> Hi All,
> 
> From "draft-kompella-mpls-bundle-05.txt", it indicates that 
> multiple links
> between two LSRs can be bundled as a single link to improve 
> the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to 
> bundle logical links
> like T1s in channelized T3, or DS3s, STS-3c in channelized 
> OC-12 interface?
> 
> Thanks.
> 
> Regards,
> Man Wing
> 
> 
> 

Delivery-date: Tue, 08 May 2001 13:05:05 -0700
Date: Tue, 08 May 2001 15:01:54 -0500
From: sambasiva mantha <[email-masked]>
Organization: Alcatel
To: Lou Berger <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: new rev of GMPLS signaling I-Ds

As mentioned in the attached email, has the draft for SONET/SDH published yet?

Thanks

Sambu

Lou Berger wrote:

> All,
>          It looks like the I-D folks are out (and not publishing) for a few
> days.  For those interested updated versions of the generalized signaling
> docs, they are available at:
>
> http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt
>
> Per the last IETF, these drafts don't include SONET/SDH specifics.  A new
> draft covering the specifics will be published in a few days.
>
> Lou (and co-authors)
>
> >Subject: Autoreply from Internet Draft Submission Manager
> >From: [email-masked] (Internet Draft Submission Manager)
> >
> >Hello,
> >
> >This message is being sent to acknowledge receipt of your submission
> >or message to [email-masked]
> >
> >The I-D administrator will be out of the office until Monday,
> >April 23rd. All submissions will be processed.
> >
> >Thank you. We appreciate your understanding and patience.

Delivery-date: Mon, 07 May 2001 11:14:54 -0700
From: "Saha, Sayandeb" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  UPSTREAM_COMPONENT_INTERFACE_ID  question 
Date: Mon, 7 May 2001 14:13:01 -0400 

draft-kompella-mpls-bundle-05.txt (section 5.2.1) speaks about the
UPSTREAM_COMPONENT_INTERFACE_ID object which is to be
included as a part of the <sender descriptor> for bidirectional LSPs
when using Explicit Indication by Unnumbered. This seems to be an
exception which allows one to specify a component for the upstream
traffic.
Specification of a component for upstream traffic is not supported for
other indication types in Bundling (Implicit Indication and Explicit
Indication by IP address), but instead is inferred.  Also in the
non-bundling
case, when signaling unnumbered interfaces, the ERO only includes 
the upstream router_id and the outgoing interface Id, again nothing about
the upstream link on which traffic should be carried.

My question:
What is the point in having a UPSTREAM_COMPONENT_INTERFACE_ID
for the Explicit Indication by Unnumbered case, when there is nothing
similar
for other cases?  Isn't the  DOWNSTREAM_COMPONENT_INTERFACE_ID 
enough to let us know which link should be selected for reverse direction of
the Bidirectional LSP? Am I missing something here?

-Sayan

Delivery-date: Mon, 07 May 2001 08:09:55 -0700
From: Heiles Juergen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Comments on G-PID
Date: Mon, 7 May 2001 17:08:01 +0200 

I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt.

Juergen

The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID intorduciton text
"An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload."

Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required.

Now to the detailed comments:
The follwoing G-PIDs have to be removed as they are not defined:
            8     Bit synchronous mapping of E3
            9     Byte synchronous mapping of E3
           12     Byte synchronous mapping of DS2/T2

As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore:
           19     Same as 12 but in a VC-12
           20     Same as 13 but in a VC-12
           21     Same as 14 but in a VC-12

SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals):
The whole set of SONET/SDH G-PIDs:
                Asynchronous mapping of E4 PDH framed
                Asynchronous mapping of E4 SDH framed
                Asynchronous mapping of E4 transparent
                Asynchronous mapping of DS3 M23
                Asynchronous mapping of DS3 C-Bit Parity
                Asynchronous mapping of DS3 transparent
                Asynchronous mapping of E3 PDH framed 
                Asynchronous mapping of E3 SDH framed 
                Asynchronous mapping of E3 transparent 
                Asynchronous mapping of DS2/T2
                Bit synchronous mapping of DS2/T2
                Asynchronous mapping of E1 framed
                Asynchronous mapping of E1 transparent
                Byte synchronous mapping of E1 framed
                Byte synchronous mapping of 31 * 64kbit/s
                Asynchronous mapping of DS1/T1 SF
                Asynchronous mapping of DS1/T1 ESF
                Asynchronous mapping of DS1/T1 transparent
                Bit synchronous mapping of DS1/T1 SF
                Bit synchronous mapping of DS1/T1 ESF
                Bit synchronous mapping of DS1/T1 transparent
                Byte synchronous mapping of DS1/T1 SF
                Byte synchronous mapping of DS1/T1 ESF
                VTG/TUG  
                STS Group/AUG
                POS - No Scrambling, 16 bit CRC
                POS - No Scrambling, 32 bit CRC
                POS - Scrambling, 16 bit CRC
                POS - Scrambling, 32 bit CRC
                ATM mapping
                FDDI mapping
                DQDB mapping
                GFP mapping
                LAPS IP (X.85)
                LAPS Ethernet (X.86)
                SDL, set-reset scrambler
                SDL, self-synchronizing scrambler
                O.181 test signal

Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be payload of an PDH LSP, only of a SONET/SDH and this is already defined. As I assume that no one will setup PDH LSPs the ANSI-PDH technology should be removed completley. The mapping into SONET/SDH is covered under SONET/SDH technology.

The G-PIDs

           33     Ethernet                               Lambda, Fiber specific
           34     SDH                                    Lambda, Fiber    "
           35     SONET                                  Lambda, Fiber    "
           36     Digital Wrapper                        Lambda, Fiber    "
           37     Lambda                                 Fiber            "
are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown?
"Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID.

Delivery-date: Mon, 07 May 2001 08:09:13 -0700
To: q12/15 <[email-masked]>, q14/15 <[email-masked]>, q10/13 <[email-masked]>
Cc: "t1x1.5" <[email-masked]>, ccamp <[email-masked]>
Date: Mon, 07 May 2001 17:05:28 +0200
From: Maarten Vissers <[email-masked]>
Organization: Lucent Technologies
Original-To: q12/15 <[email-masked]>, q14/15 <[email-masked]>, q10/13 <[email-masked]>
Original-CC: "t1x1.5" <[email-masked]>, ccamp <[email-masked]>
Subject: ASTN Layer Network Architecture

This is a multi-part message in MIME format.
--------------B14672130A3541BF475CFC98
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All,

The automatic switched transport network is a multi-layer network. The
architectural aspects of this multi layer nature for ASTN are to be
understood when developing the ASTN specifications (in ITU-T as well as
IETF and OIF). I have tried to address (some of) those aspects in the
following correspondence document:

http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-ln01.doc
http://ties.itu.int/u/tsg15/sg15/wp3/q12/0106/cd-astn-ln01.pdf

If you do not have access to the ITU-T TIES ftp area, you can download
your copy from: =

ftp://ftp.t1.org/T1X1/X1.5/1X151230.doc (for the moment still at
ftp://ftp.t1.org/pub/upload/1x151230.doc)
ftp://ftp.t1.org/T1X1/X1.5/1X151230.pdf

-----------------

Abstract
=3D=3D=3D=3D=3D=3D=3D=3D
Today's switched transport networks (i.e. voice, ATM, IP) are single
layer networks. The future switched optical network however is a
multi-layer network, posing additional requirements on its control plane
compared to the control plane of single layer switched networks.

This document introduces these multi layer aspects, the associated
relationships between the layer networks, the set of layer networks
within the switched optical network and its signals, the architecture of
each layer network, its components (fabrics, ports and links),
associated port management aspects, the need for common terminology with
connection management by the management plane, and more=85

The concepts of a semi automatic switched transport network (SASTN) and
a fully automatic switched transport network (FASTN) are defined.
Examples of connection creation in a multi-layer transport network are
presented for illustration of the principles.

This document doesn't describe the control plane functionality or
protocols, it presents the transport network architecture the control
plane has to operate. Current control plane specifications (G.dcm,
G.ndisc, G.sdisc and GMPLS) can be evaluated and where necessary adapted
as a result; i.e. the control plane must fit the transport plane, not
the other way around=85

The document shows that there can be either one control plane with
multiple instances (one per layer network) of the traffic engineering
and network engineering processes, or multiple control planes (one per
layer network) each with a traffic engineering and network engineering
process which are derived from a generic traffic engineering process and
network engineering process. I.e. one or multiple control planes is
about semantics only.

The document briefly addresses the implications of the multi layer
network for the "overlay" and "peering" relationships and the UNI, I-NNI
and E-NNI.

This document presents "work in progress"; updates will be created based
on additional knowledge gained and  feedback received. The objective is
to create text proposals for the ASTN/ASON series of recommendations for
the upcoming June 2001 Q.12/15 and Q.14/15 meeting.

-----------------

Please email me your comment, enhancements, extensions, ...

Regards,

Maarten
--------------B14672130A3541BF475CFC98
Content-Type: text/x-vcard; charset=us-ascii;
 name="mvissers.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Maarten Vissers
Content-Disposition: attachment;
 filename="mvissers.vcf"

begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Lucent Technologies Nederland;NA&CPSE
version:2.1
email;internet:[email-masked]
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard

--------------B14672130A3541BF475CFC98--

Delivery-date: Thu, 03 May 2001 06:26:21 -0700
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: ccamp-wg <[email-masked]>
Subject: ACTION: Summaries for sub-IP related Internet Drafts
Date: Thu, 3 May 2001 15:21:53 +0200 

ACTION: Summaries for sub-IP related Internet Drafts

-----------------------------------------
All, but specifically I-D Authors/Editors

Over the last several months, we have seen A LOT of I-Ds submitted/posted
which appear to be targeted for one or more WGs in the new sub-IP area.
(ccamp, gsmp, ipo, iporpr, tewg, mpls and ppvpn) These are mostly
individual I-Ds, that is those that do not start with 
        draft-ietf-<someWgName>
but this mesage referrs to ALL I-Ds related to the Sub IP WGs.
In fact we believe we have some 200-300 of such documents.

It is sort of impossible to try and read them all and decide in which WG
(if any) they might fit. So in order to help us (WG chairs and ADs) to 
work our way through all these documents, we want the AUTHORS/EDITORS of 
such existing documents to do the following:

- Before May 18th, pls send ONE SINGLE email per I-D to the email alias
  
       [email-masked]

  That email should be formatted and contain content as
  explained below.

  Pls DO NOT send these emails to any WG mailing list. 

  The idsummary mailing list will be archived publically at 

      ftp://subip.ietf.org/pub/lists/idsummary*

  Since these are non-WG documents (yet) any comments/discussion
  can/should take place at: 

      [email-masked]

  But initially the idea is to just collect the data.

- When doing a revision of these documents or writing a new I-D,
  please pls add a section at the beginning of your document that contains
  the same information we are asking for here so that readers of your
  document can also see it.

All these emails will be archived and the WG chairs, ADs, Technical Advisors
and Directorate will review them and report back (target is end of May)
what we want to do with each of the documents.

If we do not receive a note about an I-D we will assume that the I-D
authors/editors do not intend to publish it as a RFC.

Further, if you assume this pictorial overview of the work we are doing
in the sub-IP area, then pls indicate where in the picture your document
fits.

   --- pictorial overview of work in the sup-IP area --------------

  The Working Groups at the top are those that will use the
  Common Control and Measurement Protocols that we're 
  defining in the CCAMP WG.

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

  The technologies at the bottom allow us to create paths and so those
  are the ones we want to measure and control via the Common Control
  and Measurement Protocols coming out of CCAMP. One of those 
  technologies (MPLS) is defined by IETF, others are (have been) defined 
  in other standards organisations. However, we want to focus mainly on 
  the use of such technologies for IP.

  So for example the IPO and IPORPR WGs are assumed to be active at 
  the bottom because we want to focus on the IP use of such technologies.

Bert and Scott
--------------------
The ONE SINGLE email per I-D should be as follows:

-  Subject: <targetWgName> <nameOfID>
   
   the targetWgName is the WG that you as authors/editors
   think that this document should live in. If you have no specific
   WG as the target WG, then use subIP as the name.

   the nameOfID is the filename of the draft, e.g. draft-xxx-yyy-zzz-00.txt

- In the body of the email must have the following sections with these 
  section titles:

NAME OF I-D:

  Write it down as a URL so we can click on it to see it.  e.g. 

  http://www.ietf.org/internet-drafts/draft-xxx-yyy-zzz-00.txt

SUMMARY

  This should contain a summary of the content of the document
  Potentially it can be the abstract. But pls make sure that it helps
  the reader undestand what the document is all about.
  PLEASE TRY TO KEEP IT DOWN TO TWO PARAGRAPHS

RELATED DOCUMENTS

  A list of URLs for other I-Ds (or non-IETF documents) that you think
relate,
  compete, complement or overlap with your document.  "none" if none

WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     /  
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \  
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

WHY IS IT TARGETED AT THIS WG

  You must explain how the ID addresses a workitem in the current WG
  charter as listed on the WG charter page on the IETF web site. If
  it addresses only part of a work item, then please explain if there
  are other documents that could be merged with this one to become one
  document to address the complete work item.

JUSTIFICATION

  Why do you think it is justified for the WG to consider this document.

  In the case that you cannot explain how this document addresses
  a specific WG charter work item, then explain and justify why the
  WG should even consider this work and what the description of 
  a possible new work item would be for the WG. Suggest possible
  milestones for that work item.

  Please realize, that new work items need wide support within a
  WG, but also they need agreement from the WG chairs and ADs,
  and even when they get that, the whole IESG and IAB must review and
  approve new-work items before they get added to a WG charter.

  Please understand that we already have a lot of work in our WG
  charters, and that we would rather see that finished (or at least
  be well undeway) before we undertake any new work items.

Delivery-date: Wed, 02 May 2001 10:48:15 -0700
Date: Wed, 02 May 2001 13:50:07 -0400
To: Yakov Rekhter <[email-masked]>, "Fong, Man Wing" <[email-masked]>
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: Question about logical link in Link bundling 
Cc: [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]

At 10:00 AM 5/2/2001 -0700, Yakov Rekhter wrote:
>Man Wing,
>
> > >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links
> > between two LSRs can be bundled as a single link to improve the routing
> > scalability. Apparently, it can be used to bundle multiple links from
> > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> > etc...) to be a single link. However, can it be used to bundle logical 
> links
> > like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface?
>
>Could you please point me to the text in the draft that restricts
>its application to only physical interfaces ?

         Perhaps the text be clarified to explicitly include
logical links? I understood the text to read that both physical
and logical links were allowed. However, inclusion by implication
is probably not the best practice for a standards-track
document. :P

         --Tom

Delivery-date: Wed, 02 May 2001 10:43:32 -0700
From: "Fong, Man Wing" <[email-masked]>
To: 'Yakov Rekhter' <[email-masked]>
Cc: [email-masked], 'Kireeti Kompella' <[email-masked]>,  [email-masked]
Subject: RE: Question about logical link in Link bundling 
Date: Wed, 2 May 2001 12:41:45 -0500 

Yakov,

Thanks for clearing my doubt.

Regards,
Man Wing

 -----Original Message-----
From: 	Yakov Rekhter [mailto:[email-masked]] 
Sent:	Wednesday, May 02, 2001 12:01 PM
To:	Fong, Man Wing
Cc:	[email-masked]; 'Kireeti Kompella'; [email-masked]
Subject:	Re: Question about logical link in Link bundling 

Man Wing,

> >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple
links
> between two LSRs can be bundled as a single link to improve the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to bundle logical
links
> like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12
interface?

Could you please point me to the text in the draft that restricts
its application to only physical interfaces ?

Yakov.

Delivery-date: Wed, 02 May 2001 10:05:28 -0700
To: "Fong, Man Wing" <[email-masked]>
cc: [email-masked], "'Kireeti Kompella'" <[email-masked]>, [email-masked]
Subject: Re: Question about logical link in Link bundling 
Date: Wed, 02 May 2001 10:00:53 -0700
From: Yakov Rekhter <[email-masked]>

Man Wing,

> >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links
> between two LSRs can be bundled as a single link to improve the routing
> scalability. Apparently, it can be used to bundle multiple links from
> multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s,
> etc...) to be a single link. However, can it be used to bundle logical links
> like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface?

Could you please point me to the text in the draft that restricts
its application to only physical interfaces ?

Yakov.

Delivery-date: Tue, 01 May 2001 14:10:02 -0700
Date: Tue, 01 May 2001 17:04:33 -0400
To: "Saha, Sayandeb" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: CR_LDP Label Set question.
Cc: [email-masked],[email-masked]

See below.

At 03:57 PM 4/25/01, Saha, Sayandeb wrote:
>Hi,
>[...]
>       Label Type: 8 bits
>
>          Indicates the type and format of the labels carried in the TLV.
>          Values match the TLV type of the appropriate Label TLV.
>
>       How can a size of 8 bits for Label Type field suffice when clearly the
>tlv types are
>       much bigger in size like 0x0905 which require 12 bits.
>
>       Does this suggest the use of only the last octet of tlv_type in the
>Label Type field??
>
>-sayan

No, it suggests a bug in the documents.  It's been fixed a new version has 
been submitted and is available at:

         http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-04.txt
         http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-03.txt
         http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-03.txt

Good catch & thanks,

Lou