Subject: ***SPAM*** 99.361 (5) Add up to 4 inches to yours pxenis crg7c

From: "Lenora McKinley" <[email-masked]>
Date: Fri, 01 Feb 2008 06:52:23 +0000

Dear [email-masked]

http://dovosgehr.com

Do  you want Enlarge your Penis? 
ť Gain 3+ Inches In Length.
100% Money Back Guarantee.
ť *3 FREE Bottles Of ManSter !!

http://dovosgehr.com

Thanks
Cathy Vargas

[email-masked] wrote:
> Are you ready for BIG PENlS ?
1u2jjp1h0j-
out me now
http://dovosgehr.com/w.php

Delivery-date: Thu, 31 Jan 2008 10:54:23 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>, <[email-masked]>
Cc: "Dimitri Papadimitriou" <[email-masked]>
Subject: Re: Question on TLV Length Calculation
Date: Thu, 31 Jan 2008 10:52:43 -0000

Hi Lyndon,

I didn't see an answer to this on the list. Dimitri, do you have a view?

> Simple question on length calculation for RSVP-TE TLVs:  I've
> noticed that draft-ietf-ccamp-ethernet-traffic-parameters-03.txt
> has adopted a method of calculating TLV length from RFC 4420,
> where the length includes only the value portion of the TLV, and
> does not include the header (type and length bytes) or any padding
> bytes.
>
> This is a bit different from how length is computed for objects and
> sub-objects, where length includes header as well.  Having not
> followed the discussion on RFC 4420 closely, can someone clarify:
>
> -- is this method of length calculation to be followed on all new
> TLVs defined for RSVP-TE?
>
> -- if not, is there some basis for deciding what calculation to follow
> when defining a new TLV?

More important than the object and subobject length calculations, are the 
TLV length calculations defined in RFC 3471 where we have...
      Length: 16 bits
         Indicates the total length of the TLV, i.e., 4 + the length of
         the value field in octets.  A value field whose length is not a
         multiple of four MUST be zero-padded so that the TLV is four-
         octet aligned.

I would say that we should aim for consistency and that RFC 4420 was a 
mistake (mea culpa) caused by mirroring the capabilities advertisement 
features from a similar draft in the OSPF working group (OSPF TLVs use L = 
value length).

Consistency means following 3471 where possible (note that we can't go back 
and fix 4420 because it is deployed).

So the questions for Dimitri with 
draft-ietf-ccamp-ethernet-traffic-parameters-03.txt are:
- is there a reason to diverge from 3471?
- is it too late to fix this?

Thanks,
Adrian 

Delivery-date: Thu, 31 Jan 2008 10:38:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Thu, 31 Jan 2008 10:35:49 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Dimitri,

You asked a question below...which I have extracted/inserted below for
ease of reference:
> The
> co-ps mode has the richest scope for 'variation' in the DP=20
> labelling of
> traffic units (this is more than simply a destination proxy label
> BTW....this was a point I saw Adrian alluding to)....and one can even
> violate the rules of connections here and really screw-up any=20
> notion of deterministic resource management anyway.

does that imply change in the def. of L2SC as defined in RFC 3945 ? or
is it an add-on that is not impacting other RFC's mechanisms ? my
understanding is the latter but never got an answer whether or not this
is indeed the case (and proposal on how to spell this in the doc.)

NH=3D> I assume you are referring to the definition of a connection (wrt
to what L2Sc really means)?  A connection can only have a single source
and it must not re-order traffic units...a subtle corollary of this is
that a connection can only have a single traffic/QoS class.  This means
connections can only be p2p or p2mp in construction.  This is a
necessary requirement for resource assignment determinism.  Assuming one
does not violate these rules (and you can't in the co-cs mode) then
there is no need to include a SA label in the traffic units of a
connection....the parent connection object carries that semantic.
Further, because a connection represents a chosen set of link
connections (hops) between the source and the sink(s)then:
-	in the case of a p2p connection the label carrying the DA
information need only be link connection unique (across the population
of clients served by the lower layer network connection on that link),
ie it can be swapped hop by hop
-	in the case of a p2mp connection the label carrying the DA is a
'name' (proxy) that respresents a set of real DAs.

These labelling short-cuts is all works fine until there are
misconnectivity defects.  But if one wants to make the network more
robust to such defects (without even using any adjunct OAM flows at all)
then including the SA in each traffic unit and not-swapping the DA in
the case of p2p connections (ie just use the real DA and not a proxy for
it) has many benefits.  Now if you start with a traffic unit that was
originally designed for cl-ps operation and use it for a co-ps operation
then the above labelling information is already present, ie one has no
need to take short-cuts on removing the SA or making the DA only link
connection unique....the cl-ps mode cannot allow such short-cuts as
there is no connection that provides this information.

Now if one chooses to create mp2p merging constructs and there is also
no SA information then you have lost information on where the traffic
unit came from.....and this lost information must be provided by some
other means (usually an appeal to a higher layer entity =3D> which if
cl-ps (eg IP) allows SA recovery directly or if not cl-ps (eg ATM, etc)
requires a further label is added to provide this information, eg PW
label in MPLS).  But this is only dealing with the loss of SA
information caused by merging....we still have the issue that merging
constructs cannot have deterministic resource allocation.

I'm not sure that answers your question, because it assumes the above is
understood (implicit?) in the definition of what L2SC really means....I
suspect the above considerations have not really been taken into
account.

regards, Neil

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:[email-masked]]=20
> Sent: 30 January 2008 23:40
> To: Harrison,N,Neil,DMF R; [email-masked]; [email-masked]
> Cc: Niven-jenkins,B,Ben,DMF R; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
>=20
> =20
> neil,=20
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, January 30, 2008 7:14 PM
> > To: PAPADIMITRIOU Dimitri; [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked];=20
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > I personally think you are making a mountain out of a molehill here=20
> > Dimitri.
>=20
> the segmentation of SCs we have in RFC 3945 is sufficient to=20
> address your below decomposition. you have to consider that=20
> when a new techno is to be supported by GMPLS, stacks are not=20
> going to change the full engine/stack per specific technology -
>=20
> > And I thought I had explained why there are differences in the=20
> > treatment of layer networks depending on their mode...I=20
> clearly did a=20
> > bad job.
>=20
> don't worry, we very well understand the difference between a=20
> circuit-switched and packet-switched network.=20
>=20
> > Sure GMPLS is a generic OOB CP suite of protocols, but the=20
> details of=20
> > the parameters used used to describe the layer network being
> > considered will depend on:
> > -	for the co-cs mode whether we are dealing with resources which
> > are either regular time-slices, freq or space
> > -	for the co-ps mode there is only irregular time-slices.
>=20
> L2SC is in the latter.
> =20
> > And the labelling of such resource partitions is different in
> > each case
> > too...so just like it is impossible to have a common (ie=20
> > single instance
> > of) CP running 'IP to Optics' (or any functional component for that
> > matter) it is impossible to have an identical set of parameters
> > describing each mode....this is just the physics and the way=20
> > it is.  The
> > co-ps mode has the richest scope for 'variation' in the DP=20
> > labelling of
> > traffic units (this is more than simply a destination proxy label
> > BTW....this was a point I saw Adrian alluding to)....and=20
> one can even
> > violate the rules of connections here and really screw-up any=20
> > notion of deterministic resource management anyway.
>=20
> does that imply change in the def. of L2SC as defined in RFC=20
> 3945 ? or is it an add-on that is not impacting other RFC's=20
> mechanisms ? my understanding is the latter but never got an=20
> answer whether or not this is indeed the case (and proposal=20
> on how to spell this in the doc.)
>=20
> the addition to adrian's text is a way out. it is to be=20
> followed by discussions because the protocol aspects remain open.=20
>=20
> thanks,
> -d.
>=20
> > regards, Neil
> >=20
> > > -----Original Message-----
> > > From: PAPADIMITRIOU Dimitri
> > > [mailto:[email-masked]]=20
> > > Sent: 30 January 2008 17:23
> > > To: Howard Green; Loa Andersson
> > > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20
> > > [email-masked]; [email-masked]; [email-masked];=20
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > >=20
> > > =20
> > >=20
> > > > -----Original Message-----
> > > > From: Howard Green [mailto:[email-masked]]
> > > > Sent: Wednesday, January 30, 2008 12:09 PM
> > > > To: PAPADIMITRIOU Dimitri; Loa Andersson
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];=20
> > > > [email-masked]
> > > > Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > >=20
> > > > Hi
> > > > Dimitri seems to me to be making a very abstract and
> > > legalistic point.
> > >=20
> > > receive my total disagreement. an individual submission that
> > > asks to change an existing RFC requires discussion and=20
> > > particular attention (in part., when it is the protocol arch.=20
> > > document) - if this not possible then probably you have to=20
> > > write also a doc. asking for changing the IETF proces - and=20
> > > then you come back with your individual submission.
> > >  =20
> > > > The reason why this work is important is that the IEEE has been=20
> > > > evolving Ethernet to give it carrier class features, in=20
> respect of
> > > scalability,
> > > > OAM, and (with 802.1Qay) the possibility to use an
> > external control
> > > > plane.
> > >=20
> > > no one i think question this. and i don't think the poll is
> > > on this specific point. CCAMP or even IETF at large is not an=20
> > > authority to decide upon IEEE technos.
> > >=20
> > > > Some of these features will very likely require or enable
> > > added value
> > > > from extensions to the functionality of GMPLS - for
> > example, as has
> > > > already  been suggested, the addition of functionality
> > for creating
> > > > the OAM associations.
> > >=20
> > > indeed, and your colleague has already received a list of
> > > comments to be addressed before seeing any way forward w/ the=20
> > > proposed approach.=20
> > >=20
> > > > Therefore this will likely not be the same as the possible use=20
> > > > suggested in RFC3945, which may (at least in theory) have been=20
> > > > implemented somewhere.
> > >=20
> > > the exact problem, i mentionned a couple of times. your own
> > > comment shows that one may use GMPLS differently but may i=20
> > > ask WHY ? and what's the implications ?
> > >=20
> > > > Therefore the suggestion in the draft seems to make sense.
> > >=20
> > > why ?
> > >=20
> > > > I can't really see what important principle is being=20
> defended by=20
> > > > the insistence upon L2SC, which, as Don Fedyk
> > > stated, was
> > > > always somewhat underspecified.
> > >=20
> > > THE reason is that an interface SC or a related functionality
> > > has never resulted in a specific change in the base protocol=20
> > > building blocks. GMPLS is a generalized approach not a=20
> > > differentiated approach per interface.
> > >=20
> > > actually your last statement is not correct (L2SC is well
> > > specified in RFC 3945) AND by the way yours does not at all=20
> > > better specify it.
> > >=20
> > > > This is not something to be debated in the abstract. The
> > > work in ccamp
> > > > should allow sensible extension of functionality where it
> > > adds value,
> > > > and this needs to be discussed on a case by case basis.
> > > Therefore we
> > > > should make it a working group document and get on with it.
> > >=20
> > > -d.
> > > > regards Howard Green
> > > >=20
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > > Behalf Of PAPADIMITRIOU Dimitri
> > > > Sent: 30 January 2008 10:15
> > > > To: Loa Andersson
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];=20
> > > > [email-masked]
> > > > Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > >=20
> > > > loa,
> > > >=20
> > > >=20
> > > > i think the main point as ccamp is whether or not we poll
> > > for a change
> > > > or a continuation inline with RFC3945 -- when the present
> > > doc. states:
> > > >=20
> > > >   "It is expected that there will be no
> > > >    case where an Eth-LSP will be signaled, or an Eth-LSP
> > supporting
> > > >    interface will be represented, using the L2SC switching
> > > >    type/capability.  A new switching type/capability is
> > required to
> > > >    avoid any potential current usage of the L2SC switching
> > > >    type/capability in support of Ethernet.
> > > >=20
> > > > [...]
> > > >=20
> > > >   "The L2SC Interface Switching Capabilities MUST
> > > >    NOT be used to represent interfaces capable of supporting=20
> > > > Eth-LSPs."
> > > >=20
> > > > it raises three issues:
> > > >=20
> > > > a) what was the previous L2SC def. per RFC 3945 meant=20
> for if not=20
> > > > for use also in GMPLS Ethernet context ?
> > > >=20
> > > > b) why a "new one" ?
> > > >=20
> > > > this is not explained.
> > > >=20
> > > > c) what is the "new one" implying in terms of GMPLS ?
> > > >=20
> > > > for inst. in the intro "The intent of this document is to
> > reuse and
> > > > align with as much of the GMPLS protocols as possible."
> > leaves open
> > > > the issue of what as much as possible means.
> > > >=20
> > > > and on the other "Additions are made only to accommodate
> > > features of
> > > > Ethernet that are not already supported by GMPLS." so,
> > how shall i
> > > > interpreet the first sentence now ? inline with point=20
> a) and b) ?
> > > >=20
> > > >=20
> > > > the doc. in WG I-D status or not is not going to provide an
> > > answer to
> > > > these questions. sentences and statements in the doc.
> > > contradict each
> > > > other.
> > > >=20
> > > > thanks,
> > > > -d.
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Loa Andersson [mailto:[email-masked]]
> > > > > Sent: Tuesday, January 29, 2008 2:04 PM
> > > > > To: PAPADIMITRIOU Dimitri
> > > > > Cc: [email-masked]; [email-masked];=20
> > > > > [email-masked]; [email-masked]; [email-masked];=20
> > > > > [email-masked]
> > > > > Subject: Re: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > >=20
> > > > > Dimitri,
> > > > >=20
> > > > > it is possible that you have a point that needs to be
> > > > discussed, but
> > > > > is this really something that should stop us from adopting
> > > > the doc as
> > > > > a working group document.
> > > > >=20
> > > > > /Loa
> > > > >=20
> > > > > PAPADIMITRIOU Dimitri wrote:
> > > > > > neil,
> > > > > >=20
> > > > > >> -----Original Message-----
> > > > > >> From: [email-masked]=20
> [mailto:[email-masked]]
> > > > > >> Sent: Friday, January 25, 2008 2:27 PM
> > > > > >> To: PAPADIMITRIOU Dimitri; [email-masked];=20
> > > > > >> [email-masked]
> > > > > >> Cc: [email-masked]; [email-masked];=20
> [email-masked]
> > > > > >> Subject: RE: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>
> > > > > >> Dimitri....see if this helps...in-line
> > > > > >>
> > > > > >>> -----Original Message-----
> > > > > >>> From: [email-masked]
> > > [mailto:[email-masked]]
> > > > > >>> On Behalf Of
> > > > > PAPADIMITRIOU Dimitri
> > > > > >>> Sent: 25 January 2008 11:36
> > > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > [email-masked]
> > > > > >>> Subject: RE: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>>
> > > > > >>>
> > > > > >>> ben
> > > > > >>>
> > > > > >>>> -----Original Message-----
> > > > > >>>> From: Ben Niven-Jenkins
> > > [mailto:[email-masked]]
> > > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM
> > > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> > > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > [email-masked]
> > > > > >>>> Subject: Re: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > >>>>
> > > > > >>>> Dimitri,
> > > > > >>>>
> > > > > >>>> I find your mail somewhat puzzling.
> > > > > >>>>
> > > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> > > > > >>> in stone and
> > > > > >>>> nothing should modify/enhance the behaviour as specified
> > > > > >> in RFC3945
> > > > > >>>> which implies that when RFC3945 was produced the crystal
> > > > > ball was
> > > > > >>>> working extremely well and all possible future
> > > > > applications of the
> > > > > >>>> technology had
> > > > > >>>> been correctly envisaged.  I don't believe that
> > was the case.
> > > > > >>> this is not what i say. i am concerned in stating
> > > > beforehand RFC
> > > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet.
> > Why the doc.
> > > > > >>> does not deliver any tangible explanation.
> > > > > >> NH=3D> Is your problem that you cannot differentiate
> > > between the 3
> > > > > >> network modes (of co-cs, co-ps and cl-ps)?
> > > > > >=20
> > > > > > my concern wrt specific point you bring is that the today
> > > > > definition in
> > > > > > RFC 3945 for L2SC, and in the present case GMPLS for
> > > > Ethernet (with
> > > > > > local labels or domain-wide labels or any other equivalent
> > > > > to "co-ps")
> > > > > > does not result into a different definition than what's in.
> > > > > on the other
> > > > > > side, i do not see how would apply GMPLS for
> > > > connectionless/bridged
> > > > > > Ethernet.
> > > > > >=20
> > > > > > note also that GMPLS induces label from the=20
> interface and link=20
> > > > > > characteristic (i.e. there is no "label type" in the
> > > > > label/label request
> > > > > > object.
> > > > > >=20
> > > > > >> If so then looking at the work on
> > > > > >> unified modelling in SG15/Q12 may help you.  But to
> > give a more
> > > > > >> specific example here:  We can take an Ethernet
> > > traffic unit and
> > > > > >> create either a cl-ps and co-ps layer network based on
> > > this...in
> > > > > >> fact one
> > > > > can image 3
> > > > > >> different layer network cases here:
> > > > > >> -	traditional Etherent which does not have a=20
> > > > directed routing
> > > > > >> function, ie uses MAC learning, broadcast unknown,
> > > > STP...this is a
> > > > > >> cl-ps layer network
> > > > > >> -	Ethernet with an IGP providing a directed routing
> > > > > >> function....this is also a cl-ps layer network, but it is
> > > > > different to
> > > > > >> the one above
> > > > > >> -	Ethernet with a directed routing component=20
> > > > (centralised or
> > > > > >> distributed, ie IGP) and a signalling component that
> > can create
> > > > > >> connections....this would be a co-ps layer network.
> > > > > >>
> > > > > >> These are all based on a similar traffic unit, however
> > > > they form 3
> > > > > >> quite different layer networks (and in functional
> > architecture
> > > > > >> terms we would say 'the Characteristic Information is
> > > > different in
> > > > > >> the 3 cases').
> > > > > >>
> > > > > >> Now GMPLS is applying a reusable set of CP components
> > > > > (which is a very
> > > > > >> good thing, as Ben points out below) for any co-cs or
> > > > > co-ps mode layer
> > > > > >> network.  So we are setting up *connections* in
> > either a space,
> > > > > >> freq or time dimension of resource, and it is these
> > 3 resource
> > > > > dimensions that
> > > > > >> create the differences in parameters...however, the
> > notion of a
> > > > > >> connection is common across all these resource dimensions.
> > > > >  GMPLS does
> > > > > >> not apply to the cl-ps mode, as it plainly does not have
> > > > > connections.
> > > > > >=20
> > > > > > well indeed, and this is the reason why i do not see any
> > > > reason to
> > > > > > open the space for a different set of mechanisms that
> > > > would result
> > > > > > from this new interface switching definition.
> > > > > >=20
> > > > > > thanks,
> > > > > > -d.
> > > > > > =20
> > > > > >> That is at least how I look at this issue.
> > > > > >>
> > > > > >> regards, Neil
> > > > > >>>>> the question triggered by this poll is the following: if
> > > > > >>> GMPLS for
> > > > > >>>>> Ethernet is not inline with the existing stacks what is
> > > > > >>> the value of
> > > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> > > > > >>> without its
> > > > > >>>>> substance ? and in practice, the issue is, if it is not
> > > > > >>>> GMPLS per RFC
> > > > > >>>>> 3945, what's the value compared to any other
> > native control
> > > > > >>>> stack that
> > > > > >>>>> would be developed at IEEE for inst. for these techno's.
> > > > > >>>> If we ignore the peer model (which is unworkable in
> > > > reality IMO),
> > > >=20
> > > > > >>>> the value is obvious - significant reuse of=20
> existing code,=20
> > > > > >>>> techniques, knowledge, skills, etc.
> > > > > >>>>
> > > > > >>>> So, we should develop the control plane from scratch
> > > > > >>> because Ethernet
> > > > > >>>> requires a few modifications/enhancements (which I
> > > believe are
> > > > > >>>> backwards
> > > > > >>>> compatible) to RFC3945 - that IMO is ridiculous.
> > > > > >>> so you seem to agree with me. departing from RFC 3945
> > > > makes little
> > > >=20
> > > > > >>> sense. it would have been interesting to see the doc
> > > > delivering a
> > > > > >>> FIT of the GMPLS protocol arch. blocks and, in
> > > > particular, label
> > > > > >>> allocation and distribution for Ethernet.
> > > > > >>>
> > > > > >>> thanks,
> > > > > >>> -dimitri.
> > > > > >>>> Ben
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > >=20
> > > > >=20
> > > > > --
> > > > > Loa Andersson
> > > > >=20
> > > > > Principal Networking Architect
> > > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > > Kista, Sweden                      email: =20
> > [email-masked]
> > > > >                                             [email-masked]
> > > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20
>=20

Delivery-date: Wed, 30 Jan 2008 23:41:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Thu, 31 Jan 2008 00:40:15 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

=20
neil,=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: Wednesday, January 30, 2008 7:14 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> I personally think you are making a mountain out of a molehill here
> Dimitri. =20

the segmentation of SCs we have in RFC 3945 is sufficient to address
your below decomposition. you have to consider that when a new techno is
to be supported by GMPLS, stacks are not going to change the full
engine/stack per specific technology -

> And I thought I had explained why there are differences in the
> treatment of layer networks depending on their mode...I clearly did a
> bad job. =20

don't worry, we very well understand the difference between a
circuit-switched and packet-switched network.=20

> Sure GMPLS is a generic OOB CP suite of protocols, but the
> details of the parameters used used to describe the layer=20
> network being
> considered will depend on:
> -	for the co-cs mode whether we are dealing with resources which
> are either regular time-slices, freq or space
> -	for the co-ps mode there is only irregular time-slices.

L2SC is in the latter.
=20
> And the labelling of such resource partitions is different in=20
> each case
> too...so just like it is impossible to have a common (ie=20
> single instance
> of) CP running 'IP to Optics' (or any functional component for that
> matter) it is impossible to have an identical set of parameters
> describing each mode....this is just the physics and the way=20
> it is.  The
> co-ps mode has the richest scope for 'variation' in the DP=20
> labelling of
> traffic units (this is more than simply a destination proxy label
> BTW....this was a point I saw Adrian alluding to)....and one can even
> violate the rules of connections here and really screw-up any=20
> notion of deterministic resource management anyway.

does that imply change in the def. of L2SC as defined in RFC 3945 ? or
is it an add-on that is not impacting other RFC's mechanisms ? my
understanding is the latter but never got an answer whether or not this
is indeed the case (and proposal on how to spell this in the doc.)

the addition to adrian's text is a way out. it is to be followed by
discussions because the protocol aspects remain open.=20

thanks,
-d.

> regards, Neil=20
>=20
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri=20
> > [mailto:[email-masked]]=20
> > Sent: 30 January 2008 17:23
> > To: Howard Green; Loa Andersson
> > Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20
> > [email-masked]; [email-masked]; [email-masked];=20
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> >=20
> > =20
> >=20
> > > -----Original Message-----
> > > From: Howard Green [mailto:[email-masked]]
> > > Sent: Wednesday, January 30, 2008 12:09 PM
> > > To: PAPADIMITRIOU Dimitri; Loa Andersson
> > > Cc: [email-masked]; [email-masked];=20
> > > [email-masked]; [email-masked]; [email-masked];=20
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > Hi
> > > Dimitri seems to me to be making a very abstract and=20
> > legalistic point.
> >=20
> > receive my total disagreement. an individual submission that=20
> > asks to change an existing RFC requires discussion and=20
> > particular attention (in part., when it is the protocol arch.=20
> > document) - if this not possible then probably you have to=20
> > write also a doc. asking for changing the IETF proces - and=20
> > then you come back with your individual submission.
> >  =20
> > > The reason why this work is important is that the IEEE has
> > > been evolving
> > > Ethernet to give it carrier class features, in respect of=20
> > scalability,
> > > OAM, and (with 802.1Qay) the possibility to use an=20
> external control
> > > plane.=20
> >=20
> > no one i think question this. and i don't think the poll is=20
> > on this specific point. CCAMP or even IETF at large is not an=20
> > authority to decide upon IEEE technos.
> >=20
> > > Some of these features will very likely require or enable=20
> > added value=20
> > > from extensions to the functionality of GMPLS - for=20
> example, as has=20
> > > already  been suggested, the addition of functionality=20
> for creating=20
> > > the OAM associations.
> >=20
> > indeed, and your colleague has already received a list of=20
> > comments to be addressed before seeing any way forward w/ the=20
> > proposed approach.=20
> >=20
> > > Therefore this will likely not be the same as the
> > > possible use suggested in RFC3945, which may (at least
> > > in theory) have been implemented somewhere.=20
> >=20
> > the exact problem, i mentionned a couple of times. your own=20
> > comment shows that one may use GMPLS differently but may i=20
> > ask WHY ? and what's the implications ?
> >=20
> > > Therefore the suggestion in the draft seems to make sense.
> >=20
> > why ?
> >=20
> > > I can't really see what important principle is being
> > > defended by the insistence upon L2SC, which, as Don Fedyk=20
> > stated, was=20
> > > always somewhat underspecified.
> >=20
> > THE reason is that an interface SC or a related functionality=20
> > has never resulted in a specific change in the base protocol=20
> > building blocks. GMPLS is a generalized approach not a=20
> > differentiated approach per interface.
> >=20
> > actually your last statement is not correct (L2SC is well=20
> > specified in RFC 3945) AND by the way yours does not at all=20
> > better specify it.
> >=20
> > > This is not something to be debated in the abstract. The=20
> > work in ccamp=20
> > > should allow sensible extension of functionality where it=20
> > adds value,=20
> > > and this needs to be discussed on a case by case basis.=20
> > Therefore we=20
> > > should make it a working group document and get on with it.
> >=20
> > -d.
> > > regards Howard Green
> > >=20
> > > -----Original Message-----
> > > From: [email-masked]=20
> [mailto:[email-masked]] On=20
> > > Behalf Of PAPADIMITRIOU Dimitri
> > > Sent: 30 January 2008 10:15
> > > To: Loa Andersson
> > > Cc: [email-masked]; [email-masked];=20
> > > [email-masked]; [email-masked]; [email-masked];=20
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > loa,
> > >=20
> > >=20
> > > i think the main point as ccamp is whether or not we poll=20
> > for a change=20
> > > or a continuation inline with RFC3945 -- when the present=20
> > doc. states:
> > >=20
> > >   "It is expected that there will be no
> > >    case where an Eth-LSP will be signaled, or an Eth-LSP=20
> supporting
> > >    interface will be represented, using the L2SC switching
> > >    type/capability.  A new switching type/capability is=20
> required to
> > >    avoid any potential current usage of the L2SC switching
> > >    type/capability in support of Ethernet.
> > >=20
> > > [...]
> > >=20
> > >   "The L2SC Interface Switching Capabilities MUST
> > >    NOT be used to represent interfaces capable of supporting
> > > Eth-LSPs."
> > >=20
> > > it raises three issues:
> > >=20
> > > a) what was the previous L2SC def. per RFC 3945 meant for if
> > > not for use
> > > also in GMPLS Ethernet context ?
> > >=20
> > > b) why a "new one" ?
> > >=20
> > > this is not explained.
> > >=20
> > > c) what is the "new one" implying in terms of GMPLS ?
> > >=20
> > > for inst. in the intro "The intent of this document is to=20
> reuse and=20
> > > align with as much of the GMPLS protocols as possible."=20
> leaves open=20
> > > the issue of what as much as possible means.
> > >=20
> > > and on the other "Additions are made only to accommodate=20
> > features of=20
> > > Ethernet that are not already supported by GMPLS." so,=20
> how shall i=20
> > > interpreet the first sentence now ? inline with point a) and b) ?
> > >=20
> > >=20
> > > the doc. in WG I-D status or not is not going to provide an=20
> > answer to=20
> > > these questions. sentences and statements in the doc.=20
> > contradict each=20
> > > other.
> > >=20
> > > thanks,
> > > -d.
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Loa Andersson [mailto:[email-masked]]
> > > > Sent: Tuesday, January 29, 2008 2:04 PM
> > > > To: PAPADIMITRIOU Dimitri
> > > > Cc: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];=20
> > > > [email-masked]
> > > > Subject: Re: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > >=20
> > > > Dimitri,
> > > >=20
> > > > it is possible that you have a point that needs to be
> > > discussed, but
> > > > is this really something that should stop us from adopting
> > > the doc as
> > > > a working group document.
> > > >=20
> > > > /Loa
> > > >=20
> > > > PAPADIMITRIOU Dimitri wrote:
> > > > > neil,
> > > > >=20
> > > > >> -----Original Message-----
> > > > >> From: [email-masked] [mailto:[email-masked]]
> > > > >> Sent: Friday, January 25, 2008 2:27 PM
> > > > >> To: PAPADIMITRIOU Dimitri; [email-masked];
> > > > >> [email-masked]
> > > > >> Cc: [email-masked]; [email-masked]; [email-masked]
> > > > >> Subject: RE: Proposed WG Draft -=20
> > draft-gmpls-ethernet-arch-00.txt
> > > > >>
> > > > >> Dimitri....see if this helps...in-line
> > > > >>
> > > > >>> -----Original Message-----
> > > > >>> From: [email-masked]=20
> > [mailto:[email-masked]]=20
> > > > >>> On Behalf Of
> > > > PAPADIMITRIOU Dimitri
> > > > >>> Sent: 25 January 2008 11:36
> > > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> > [email-masked]
> > > > >>> Subject: RE: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > >>>
> > > > >>>
> > > > >>> ben
> > > > >>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Ben Niven-Jenkins=20
> > [mailto:[email-masked]]
> > > > >>>> Sent: Thursday, January 24, 2008 3:40 PM
> > > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> > > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> > [email-masked]
> > > > >>>> Subject: Re: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > >>>>
> > > > >>>> Dimitri,
> > > > >>>>
> > > > >>>> I find your mail somewhat puzzling.
> > > > >>>>
> > > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> > > > >>> in stone and
> > > > >>>> nothing should modify/enhance the behaviour as specified
> > > > >> in RFC3945
> > > > >>>> which implies that when RFC3945 was produced the crystal
> > > > ball was
> > > > >>>> working extremely well and all possible future
> > > > applications of the
> > > > >>>> technology had
> > > > >>>> been correctly envisaged.  I don't believe that=20
> was the case.
> > > > >>> this is not what i say. i am concerned in stating
> > > beforehand RFC
> > > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet.=20
> Why the doc.
> > > > >>> does not deliver any tangible explanation.
> > > > >> NH=3D> Is your problem that you cannot differentiate=20
> > between the 3
> > > > >> network modes (of co-cs, co-ps and cl-ps)?
> > > > >=20
> > > > > my concern wrt specific point you bring is that the today
> > > > definition in
> > > > > RFC 3945 for L2SC, and in the present case GMPLS for
> > > Ethernet (with
> > > > > local labels or domain-wide labels or any other equivalent
> > > > to "co-ps")
> > > > > does not result into a different definition than what's in.
> > > > on the other
> > > > > side, i do not see how would apply GMPLS for
> > > connectionless/bridged
> > > > > Ethernet.
> > > > >=20
> > > > > note also that GMPLS induces label from the interface and link
> > > > > characteristic (i.e. there is no "label type" in the
> > > > label/label request
> > > > > object.
> > > > >=20
> > > > >> If so then looking at the work on
> > > > >> unified modelling in SG15/Q12 may help you.  But to=20
> give a more
> > > > >> specific example here:  We can take an Ethernet=20
> > traffic unit and=20
> > > > >> create either a cl-ps and co-ps layer network based on=20
> > this...in=20
> > > > >> fact one
> > > > can image 3
> > > > >> different layer network cases here:
> > > > >> -	traditional Etherent which does not have a=20
> > > directed routing
> > > > >> function, ie uses MAC learning, broadcast unknown,
> > > STP...this is a
> > > > >> cl-ps layer network
> > > > >> -	Ethernet with an IGP providing a directed routing
> > > > >> function....this is also a cl-ps layer network, but it is
> > > > different to
> > > > >> the one above
> > > > >> -	Ethernet with a directed routing component=20
> > > (centralised or
> > > > >> distributed, ie IGP) and a signalling component that=20
> can create
> > > > >> connections....this would be a co-ps layer network.
> > > > >>
> > > > >> These are all based on a similar traffic unit, however
> > > they form 3
> > > > >> quite different layer networks (and in functional=20
> architecture
> > > > >> terms we would say 'the Characteristic Information is=20
> > > different in
> > > > >> the 3 cases').
> > > > >>
> > > > >> Now GMPLS is applying a reusable set of CP components
> > > > (which is a very
> > > > >> good thing, as Ben points out below) for any co-cs or
> > > > co-ps mode layer
> > > > >> network.  So we are setting up *connections* in=20
> either a space,
> > > > >> freq or time dimension of resource, and it is these=20
> 3 resource
> > > > dimensions that
> > > > >> create the differences in parameters...however, the=20
> notion of a
> > > > >> connection is common across all these resource dimensions.
> > > >  GMPLS does
> > > > >> not apply to the cl-ps mode, as it plainly does not have
> > > > connections.
> > > > >=20
> > > > > well indeed, and this is the reason why i do not see any
> > > reason to
> > > > > open the space for a different set of mechanisms that
> > > would result
> > > > > from this new interface switching definition.
> > > > >=20
> > > > > thanks,
> > > > > -d.
> > > > > =20
> > > > >> That is at least how I look at this issue.
> > > > >>
> > > > >> regards, Neil
> > > > >>>>> the question triggered by this poll is the following: if
> > > > >>> GMPLS for
> > > > >>>>> Ethernet is not inline with the existing stacks what is
> > > > >>> the value of
> > > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> > > > >>> without its
> > > > >>>>> substance ? and in practice, the issue is, if it is not
> > > > >>>> GMPLS per RFC
> > > > >>>>> 3945, what's the value compared to any other=20
> native control
> > > > >>>> stack that
> > > > >>>>> would be developed at IEEE for inst. for these techno's.
> > > > >>>> If we ignore the peer model (which is unworkable in
> > > reality IMO),
> > >=20
> > > > >>>> the value is obvious - significant reuse of existing code,
> > > > >>>> techniques, knowledge, skills, etc.
> > > > >>>>
> > > > >>>> So, we should develop the control plane from scratch
> > > > >>> because Ethernet
> > > > >>>> requires a few modifications/enhancements (which I=20
> > believe are
> > > > >>>> backwards
> > > > >>>> compatible) to RFC3945 - that IMO is ridiculous.
> > > > >>> so you seem to agree with me. departing from RFC 3945
> > > makes little
> > >=20
> > > > >>> sense. it would have been interesting to see the doc
> > > delivering a
> > > > >>> FIT of the GMPLS protocol arch. blocks and, in
> > > particular, label
> > > > >>> allocation and distribution for Ethernet.
> > > > >>>
> > > > >>> thanks,
> > > > >>> -dimitri.
> > > > >>>> Ben
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >=20
> > > > >=20
> > > > >=20
> > > >=20
> > > >=20
> > > > --
> > > > Loa Andersson
> > > >=20
> > > > Principal Networking Architect
> > > > Acreo AB                           phone:  +46 8 632 77 14
> > > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > > Kista, Sweden                      email: =20
> [email-masked]
> > > >                                             [email-masked]
> > > >=20
> > >=20
> > >=20
> >=20
>=20

Delivery-date: Wed, 30 Jan 2008 21:49:01 +0000
Date: Wed, 30 Jan 2008 16:47:29 -0500
To: "Adrian Farrel" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: <[email-masked]>

Adrian,
         This seems workable to me.  Also, I don't think it was the 
intent of the draft to preclude use of L2SC for current applications, 
but rather to use new values for the new types of ether switching.  I 
think your text disambiguates this issue.

Lou

At 10:27 AM 1/30/2008, Adrian Farrel wrote:
>All,
>
>We appear to be seeing good support for this document, and that 
>suggests that we should take it forward, but I would like to at 
>least make an attempt to close down the point raised by Dimitri. As 
>Howard points out, this is in danger of becoming a legalistic 
>discussion, but I've never been one to refuse the opportunity to 
>back to first principles...
>
>In RFC 3945 we have...
>
>   A link may support a set of encoding formats, where support means
>   that a link is able to carry and switch a signal of one or more of
>   these encoding formats.  The Switching Type indicates then the type
>   of switching that should be performed on a particular link for that
>   LSP.  This information is needed for links that advertise more than
>   one type of switching capability.
>
>   Nodes must verify that the type indicated in the Switching Type is
>   supported on the corresponding incoming interface; otherwise, the
>   node must generate a notification message with a "Routing
>   problem/Switching Type" indication.
>
>Now, the question is whether we are introducing one (or more) new 
>Switching Type and whether we need to be able to distinguish between 
>them. Suppose (for the sake of argument) that we will over time 
>introduce the ability to switch Ethernet frames under GMPLS control 
>based on several different label concepts:
>- 802.1Qay
>- destination MAC only
>- destination MAC and VLAN tag
>It is likely that a GMPLS-capable Ethernet switch will want to 
>support more than one of these switching paradigms on any single 
>interface. So we have to decide how, during signaling, we indicate 
>which type of LSP is requested.
>
>There are plenty of ways that this could be done. Currently we use a 
>combination of the parameters of the Generalized_Label_Request 
>object and the Sender_TSpec object. The TSpec is used in the case of 
>TDM (RFC 4606) and Ethernet to distinguish the Switching Granularity 
>(draft-ietf-ccamp-ethernet-traffic-parameters).
>
>As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt 
>causes a problem because it appears to say that *no* Ethernet Label 
>Switched Path (Eth-LSP) can be set up using an L2SC Switching Type.
>   It is expected that there will be no
>   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>   interface will be represented, using the L2SC switching
>   type/capability.
>
>However, the draft also says...
>   A new switching type/capability is required to
>   avoid any potential current usage of the L2SC switching
>   type/capability in support of Ethernet.
>
>And this clearly says that L2SC *is* allowed.
>
>Can we fix this by agreeing some new wording?
>
>==
>OLD
>   This document does not define any specific format for an Eth-LSP
>   label. Rather, it is expected that service specific documents will
>   define any signaling and routing extensions needed to support that
>   specific Ethernet service.  Depending on the requirements of a
>   service, it may be necessary to define multiple GMPLS extensions,
>   e.g., label formats, switching types, and Traffic Engineering (TE)
>   routing extensions.  It is expected that all such extensions will be
>   consistent with this document. It is expected that there will be no
>   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>   interface will be represented, using the L2SC switching
>   type/capability.  A new switching type/capability is required to
>   avoid any potential current usage of the L2SC switching
>   type/capability in support of Ethernet.
>NEW
>   This document does not define any specific format for an Eth-LSP
>   label. Rather, it is expected that service specific documents will
>   define any signaling and routing extensions needed to support that
>   specific Ethernet service.  Depending on the requirements of a
>   service, it may be necessary to define multiple GMPLS protocol
>   extensions and procedures. It is expected that all such extensions
>   will be consistent with this document.
>
>   It is expected that key a requirement will be to describe label
>   formats and encodings. It may also be necessary to provide a
>   mechanism to identify the required Ethernet service type in signaling
>   and a way to advertise the capabilities of Ethernet switches in the
>   routing protocols. These mechanisms must make it possible to
>   distinguish between requests for different paradigms including new,
>   future, and existing paradigms.
>
>   The Switching Type and Interface Switching Capability Descriptor
>   share a common set of values and are defined in [RFC3945], [RFC3471],
>   and [RFC4202] as indicators of the type of switching that should
>   ([RFC3471]) and can ([RFC4202]) be performed on a particular link for
>   an LSP. The L2SC switching type is available for use by
>   implementations performing layer 2 switching including ATM and
>   Ethernet. To support the continued use of that switching type by
>   existing implementations as well as to distinguish between each new
>   Ethernet switching paradigm, a new switching type is expected to be
>   needed for each new Ethernet switching paradigm that is supported.
>==
>
>Thanks,
>Adrian
>
>
>

Delivery-date: Wed, 30 Jan 2008 18:39:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 18:39:02 -0000

Dimitri,
Thanks.

Editors,
Please submit your I-D as draft-ietf-ccamp-gmpls-ethernet-arch-00.txt making 
the changes described below.

Thanks,
Adrian

----- Original Message ----- 
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; <[email-masked]>
Sent: Wednesday, January 30, 2008 6:32 PM
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

adrian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 30, 2008 4:28 PM
> To: [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>
> All,
>
> We appear to be seeing good support for this document, and
> that suggests
> that we should take it forward, but I would like to at least
> make an attempt
> to close down the point raised by Dimitri. As Howard points
> out, this is in
> danger of becoming a legalistic discussion, but I've never
> been one to
> refuse the opportunity to back to first principles...
>
> In RFC 3945 we have...
>
>    A link may support a set of encoding formats, where support means
>    that a link is able to carry and switch a signal of one or more of
>    these encoding formats.  The Switching Type indicates then the type
>    of switching that should be performed on a particular link for that
>    LSP.  This information is needed for links that advertise more than
>    one type of switching capability.
>
>    Nodes must verify that the type indicated in the Switching Type is
>    supported on the corresponding incoming interface; otherwise, the
>    node must generate a notification message with a "Routing
>    problem/Switching Type" indication.
>
> Now, the question is whether we are introducing one (or more)
> new Switching
> Type and whether we need to be able to distinguish between
> them. Suppose
> (for the sake of argument) that we will over time introduce
> the ability to
> switch Ethernet frames under GMPLS control based on several
> different label
> concepts:
> - 802.1Qay
> - destination MAC only
> - destination MAC and VLAN tag
> It is likely that a GMPLS-capable Ethernet switch will want
> to support more
> than one of these switching paradigms on any single
> interface. So we have to
> decide how, during signaling, we indicate which type of LSP
> is requested.
>
> There are plenty of ways that this could be done. Currently we use a
> combination of the parameters of the
> Generalized_Label_Request object and
> the Sender_TSpec object. The TSpec is used in the case of TDM
> (RFC 4606) and
> Ethernet to distinguish the Switching Granularity
> (draft-ietf-ccamp-ethernet-traffic-parameters).
>
> As I see it, the text at issue in
> draft-gmpls-ethernet-arch-00.txt causes a
> problem because it appears to say that *no* Ethernet Label
> Switched Path
> (Eth-LSP) can be set up using an L2SC Switching Type.
>    It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.
>
> However, the draft also says...
>    A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
>
> And this clearly says that L2SC *is* allowed.
>
> Can we fix this by agreeing some new wording?
>
> ==
> OLD
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS extensions,
>    e.g., label formats, switching types, and Traffic Engineering (TE)
>    routing extensions.  It is expected that all such
> extensions will be
>    consistent with this document. It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.  A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
> NEW
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS protocol
>    extensions and procedures. It is expected that all such extensions
>    will be consistent with this document.
>
>    It is expected that key a requirement will be to describe label
>    formats and encodings. It may also be necessary to provide a
>    mechanism to identify the required Ethernet service type
> in signaling
>    and a way to advertise the capabilities of Ethernet switches in the
>    routing protocols. These mechanisms must make it possible to
>    distinguish between requests for different paradigms including new,
>    future, and existing paradigms.
>
>    The Switching Type and Interface Switching Capability Descriptor
>    share a common set of values and are defined in [RFC3945],
> [RFC3471],
>    and [RFC4202] as indicators of the type of switching that should
>    ([RFC3471]) and can ([RFC4202]) be performed on a
> particular link for
>    an LSP. The L2SC switching type is available for use by
>    implementations performing layer 2 switching including ATM and
>    Ethernet. To support the continued use of that switching type by
>    existing implementations as well as to distinguish between each new
>    Ethernet switching paradigm, a new switching type is expected to be
>    needed for each new Ethernet switching paradigm that is supported.

i can live with this at the condition that a statement is added about
either we do ack assessment on further implications or do not imply any
change on other GMPLS building blocks (note: there is a main difference
between change and extensions).

thanks,
-d.

> ==
> Thanks,
> Adrian

Delivery-date: Wed, 30 Jan 2008 18:33:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 19:32:32 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

adrian=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 30, 2008 4:28 PM
> To: [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> All,
>=20
> We appear to be seeing good support for this document, and=20
> that suggests=20
> that we should take it forward, but I would like to at least=20
> make an attempt=20
> to close down the point raised by Dimitri. As Howard points=20
> out, this is in=20
> danger of becoming a legalistic discussion, but I've never=20
> been one to=20
> refuse the opportunity to back to first principles...
>=20
> In RFC 3945 we have...
>=20
>    A link may support a set of encoding formats, where support means
>    that a link is able to carry and switch a signal of one or more of
>    these encoding formats.  The Switching Type indicates then the type
>    of switching that should be performed on a particular link for that
>    LSP.  This information is needed for links that advertise more than
>    one type of switching capability.
>=20
>    Nodes must verify that the type indicated in the Switching Type is
>    supported on the corresponding incoming interface; otherwise, the
>    node must generate a notification message with a "Routing
>    problem/Switching Type" indication.
>=20
> Now, the question is whether we are introducing one (or more)=20
> new Switching=20
> Type and whether we need to be able to distinguish between=20
> them. Suppose=20
> (for the sake of argument) that we will over time introduce=20
> the ability to=20
> switch Ethernet frames under GMPLS control based on several=20
> different label=20
> concepts:
> - 802.1Qay
> - destination MAC only
> - destination MAC and VLAN tag
> It is likely that a GMPLS-capable Ethernet switch will want=20
> to support more=20
> than one of these switching paradigms on any single=20
> interface. So we have to=20
> decide how, during signaling, we indicate which type of LSP=20
> is requested.
>=20
> There are plenty of ways that this could be done. Currently we use a=20
> combination of the parameters of the=20
> Generalized_Label_Request object and=20
> the Sender_TSpec object. The TSpec is used in the case of TDM=20
> (RFC 4606) and=20
> Ethernet to distinguish the Switching Granularity=20
> (draft-ietf-ccamp-ethernet-traffic-parameters).
>=20
> As I see it, the text at issue in=20
> draft-gmpls-ethernet-arch-00.txt causes a=20
> problem because it appears to say that *no* Ethernet Label=20
> Switched Path=20
> (Eth-LSP) can be set up using an L2SC Switching Type.
>    It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.
>=20
> However, the draft also says...
>    A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
>=20
> And this clearly says that L2SC *is* allowed.
>=20
> Can we fix this by agreeing some new wording?
>=20
> =3D=3D
> OLD
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS extensions,
>    e.g., label formats, switching types, and Traffic Engineering (TE)
>    routing extensions.  It is expected that all such=20
> extensions will be
>    consistent with this document. It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.  A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
> NEW
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS protocol
>    extensions and procedures. It is expected that all such extensions
>    will be consistent with this document.
>=20
>    It is expected that key a requirement will be to describe label
>    formats and encodings. It may also be necessary to provide a
>    mechanism to identify the required Ethernet service type=20
> in signaling
>    and a way to advertise the capabilities of Ethernet switches in the
>    routing protocols. These mechanisms must make it possible to
>    distinguish between requests for different paradigms including new,
>    future, and existing paradigms.
>=20
>    The Switching Type and Interface Switching Capability Descriptor
>    share a common set of values and are defined in [RFC3945],=20
> [RFC3471],
>    and [RFC4202] as indicators of the type of switching that should
>    ([RFC3471]) and can ([RFC4202]) be performed on a=20
> particular link for
>    an LSP. The L2SC switching type is available for use by
>    implementations performing layer 2 switching including ATM and
>    Ethernet. To support the continued use of that switching type by
>    existing implementations as well as to distinguish between each new
>    Ethernet switching paradigm, a new switching type is expected to be
>    needed for each new Ethernet switching paradigm that is supported.

i can live with this at the condition that a statement is added about
either we do ack assessment on further implications or do not imply any
change on other GMPLS building blocks (note: there is a main difference
between change and extensions).

thanks,
-d.=20

> =3D=3D
>=20
> Thanks,
> Adrian=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 30 Jan 2008 18:14:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 18:13:34 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

I personally think you are making a mountain out of a molehill here
Dimitri.  And I thought I had explained why there are differences in the
treatment of layer networks depending on their mode...I clearly did a
bad job.  Sure GMPLS is a generic OOB CP suite of protocols, but the
details of the parameters used used to describe the layer network being
considered will depend on:
-	for the co-cs mode whether we are dealing with resources which
are either regular time-slices, freq or space
-	for the co-ps mode there is only irregular time-slices.

And the labelling of such resource partitions is different in each case
too...so just like it is impossible to have a common (ie single instance
of) CP running 'IP to Optics' (or any functional component for that
matter) it is impossible to have an identical set of parameters
describing each mode....this is just the physics and the way it is.  The
co-ps mode has the richest scope for 'variation' in the DP labelling of
traffic units (this is more than simply a destination proxy label
BTW....this was a point I saw Adrian alluding to)....and one can even
violate the rules of connections here and really screw-up any notion of
deterministic resource management anyway.

regards, Neil=20

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:[email-masked]]=20
> Sent: 30 January 2008 17:23
> To: Howard Green; Loa Andersson
> Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;=20
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
>=20
> =20
>=20
> > -----Original Message-----
> > From: Howard Green [mailto:[email-masked]]
> > Sent: Wednesday, January 30, 2008 12:09 PM
> > To: PAPADIMITRIOU Dimitri; Loa Andersson
> > Cc: [email-masked]; [email-masked];=20
> > [email-masked]; [email-masked]; [email-masked];=20
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > Hi
> > Dimitri seems to me to be making a very abstract and=20
> legalistic point.
>=20
> receive my total disagreement. an individual submission that=20
> asks to change an existing RFC requires discussion and=20
> particular attention (in part., when it is the protocol arch.=20
> document) - if this not possible then probably you have to=20
> write also a doc. asking for changing the IETF proces - and=20
> then you come back with your individual submission.
>  =20
> > The reason why this work is important is that the IEEE has
> > been evolving
> > Ethernet to give it carrier class features, in respect of=20
> scalability,
> > OAM, and (with 802.1Qay) the possibility to use an external control
> > plane.=20
>=20
> no one i think question this. and i don't think the poll is=20
> on this specific point. CCAMP or even IETF at large is not an=20
> authority to decide upon IEEE technos.
>=20
> > Some of these features will very likely require or enable=20
> added value=20
> > from extensions to the functionality of GMPLS - for example, as has=20
> > already  been suggested, the addition of functionality for creating=20
> > the OAM associations.
>=20
> indeed, and your colleague has already received a list of=20
> comments to be addressed before seeing any way forward w/ the=20
> proposed approach.=20
>=20
> > Therefore this will likely not be the same as the
> > possible use suggested in RFC3945, which may (at least
> > in theory) have been implemented somewhere.=20
>=20
> the exact problem, i mentionned a couple of times. your own=20
> comment shows that one may use GMPLS differently but may i=20
> ask WHY ? and what's the implications ?
>=20
> > Therefore the suggestion in the draft seems to make sense.
>=20
> why ?
>=20
> > I can't really see what important principle is being
> > defended by the insistence upon L2SC, which, as Don Fedyk=20
> stated, was=20
> > always somewhat underspecified.
>=20
> THE reason is that an interface SC or a related functionality=20
> has never resulted in a specific change in the base protocol=20
> building blocks. GMPLS is a generalized approach not a=20
> differentiated approach per interface.
>=20
> actually your last statement is not correct (L2SC is well=20
> specified in RFC 3945) AND by the way yours does not at all=20
> better specify it.
>=20
> > This is not something to be debated in the abstract. The=20
> work in ccamp=20
> > should allow sensible extension of functionality where it=20
> adds value,=20
> > and this needs to be discussed on a case by case basis.=20
> Therefore we=20
> > should make it a working group document and get on with it.
>=20
> -d.
> > regards Howard Green
> >=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On=20
> > Behalf Of PAPADIMITRIOU Dimitri
> > Sent: 30 January 2008 10:15
> > To: Loa Andersson
> > Cc: [email-masked]; [email-masked];=20
> > [email-masked]; [email-masked]; [email-masked];=20
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > loa,
> >=20
> >=20
> > i think the main point as ccamp is whether or not we poll=20
> for a change=20
> > or a continuation inline with RFC3945 -- when the present=20
> doc. states:
> >=20
> >   "It is expected that there will be no
> >    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
> >    interface will be represented, using the L2SC switching
> >    type/capability.  A new switching type/capability is required to
> >    avoid any potential current usage of the L2SC switching
> >    type/capability in support of Ethernet.
> >=20
> > [...]
> >=20
> >   "The L2SC Interface Switching Capabilities MUST
> >    NOT be used to represent interfaces capable of supporting
> > Eth-LSPs."
> >=20
> > it raises three issues:
> >=20
> > a) what was the previous L2SC def. per RFC 3945 meant for if
> > not for use
> > also in GMPLS Ethernet context ?
> >=20
> > b) why a "new one" ?
> >=20
> > this is not explained.
> >=20
> > c) what is the "new one" implying in terms of GMPLS ?
> >=20
> > for inst. in the intro "The intent of this document is to reuse and=20
> > align with as much of the GMPLS protocols as possible." leaves open=20
> > the issue of what as much as possible means.
> >=20
> > and on the other "Additions are made only to accommodate=20
> features of=20
> > Ethernet that are not already supported by GMPLS." so, how shall i=20
> > interpreet the first sentence now ? inline with point a) and b) ?
> >=20
> >=20
> > the doc. in WG I-D status or not is not going to provide an=20
> answer to=20
> > these questions. sentences and statements in the doc.=20
> contradict each=20
> > other.
> >=20
> > thanks,
> > -d.
> >=20
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Loa Andersson [mailto:[email-masked]]
> > > Sent: Tuesday, January 29, 2008 2:04 PM
> > > To: PAPADIMITRIOU Dimitri
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked];=20
> > > [email-masked]
> > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > Dimitri,
> > >=20
> > > it is possible that you have a point that needs to be
> > discussed, but
> > > is this really something that should stop us from adopting
> > the doc as
> > > a working group document.
> > >=20
> > > /Loa
> > >=20
> > > PAPADIMITRIOU Dimitri wrote:
> > > > neil,
> > > >=20
> > > >> -----Original Message-----
> > > >> From: [email-masked] [mailto:[email-masked]]
> > > >> Sent: Friday, January 25, 2008 2:27 PM
> > > >> To: PAPADIMITRIOU Dimitri; [email-masked];
> > > >> [email-masked]
> > > >> Cc: [email-masked]; [email-masked]; [email-masked]
> > > >> Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > >>
> > > >> Dimitri....see if this helps...in-line
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: [email-masked]=20
> [mailto:[email-masked]]=20
> > > >>> On Behalf Of
> > > PAPADIMITRIOU Dimitri
> > > >>> Sent: 25 January 2008 11:36
> > > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> > > >>> Subject: RE: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > >>>
> > > >>>
> > > >>> ben
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Ben Niven-Jenkins=20
> [mailto:[email-masked]]
> > > >>>> Sent: Thursday, January 24, 2008 3:40 PM
> > > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> > > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> > > >>>> Subject: Re: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > >>>>
> > > >>>> Dimitri,
> > > >>>>
> > > >>>> I find your mail somewhat puzzling.
> > > >>>>
> > > >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> > > >>> in stone and
> > > >>>> nothing should modify/enhance the behaviour as specified
> > > >> in RFC3945
> > > >>>> which implies that when RFC3945 was produced the crystal
> > > ball was
> > > >>>> working extremely well and all possible future
> > > applications of the
> > > >>>> technology had
> > > >>>> been correctly envisaged.  I don't believe that was the case.
> > > >>> this is not what i say. i am concerned in stating
> > beforehand RFC
> > > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.
> > > >>> does not deliver any tangible explanation.
> > > >> NH=3D> Is your problem that you cannot differentiate=20
> between the 3
> > > >> network modes (of co-cs, co-ps and cl-ps)?
> > > >=20
> > > > my concern wrt specific point you bring is that the today
> > > definition in
> > > > RFC 3945 for L2SC, and in the present case GMPLS for
> > Ethernet (with
> > > > local labels or domain-wide labels or any other equivalent
> > > to "co-ps")
> > > > does not result into a different definition than what's in.
> > > on the other
> > > > side, i do not see how would apply GMPLS for
> > connectionless/bridged
> > > > Ethernet.
> > > >=20
> > > > note also that GMPLS induces label from the interface and link
> > > > characteristic (i.e. there is no "label type" in the
> > > label/label request
> > > > object.
> > > >=20
> > > >> If so then looking at the work on
> > > >> unified modelling in SG15/Q12 may help you.  But to give a more
> > > >> specific example here:  We can take an Ethernet=20
> traffic unit and=20
> > > >> create either a cl-ps and co-ps layer network based on=20
> this...in=20
> > > >> fact one
> > > can image 3
> > > >> different layer network cases here:
> > > >> -	traditional Etherent which does not have a=20
> > directed routing
> > > >> function, ie uses MAC learning, broadcast unknown,
> > STP...this is a
> > > >> cl-ps layer network
> > > >> -	Ethernet with an IGP providing a directed routing
> > > >> function....this is also a cl-ps layer network, but it is
> > > different to
> > > >> the one above
> > > >> -	Ethernet with a directed routing component=20
> > (centralised or
> > > >> distributed, ie IGP) and a signalling component that can create
> > > >> connections....this would be a co-ps layer network.
> > > >>
> > > >> These are all based on a similar traffic unit, however
> > they form 3
> > > >> quite different layer networks (and in functional architecture
> > > >> terms we would say 'the Characteristic Information is=20
> > different in
> > > >> the 3 cases').
> > > >>
> > > >> Now GMPLS is applying a reusable set of CP components
> > > (which is a very
> > > >> good thing, as Ben points out below) for any co-cs or
> > > co-ps mode layer
> > > >> network.  So we are setting up *connections* in either a space,
> > > >> freq or time dimension of resource, and it is these 3 resource
> > > dimensions that
> > > >> create the differences in parameters...however, the notion of a
> > > >> connection is common across all these resource dimensions.
> > >  GMPLS does
> > > >> not apply to the cl-ps mode, as it plainly does not have
> > > connections.
> > > >=20
> > > > well indeed, and this is the reason why i do not see any
> > reason to
> > > > open the space for a different set of mechanisms that
> > would result
> > > > from this new interface switching definition.
> > > >=20
> > > > thanks,
> > > > -d.
> > > > =20
> > > >> That is at least how I look at this issue.
> > > >>
> > > >> regards, Neil
> > > >>>>> the question triggered by this poll is the following: if
> > > >>> GMPLS for
> > > >>>>> Ethernet is not inline with the existing stacks what is
> > > >>> the value of
> > > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> > > >>> without its
> > > >>>>> substance ? and in practice, the issue is, if it is not
> > > >>>> GMPLS per RFC
> > > >>>>> 3945, what's the value compared to any other native control
> > > >>>> stack that
> > > >>>>> would be developed at IEEE for inst. for these techno's.
> > > >>>> If we ignore the peer model (which is unworkable in
> > reality IMO),
> >=20
> > > >>>> the value is obvious - significant reuse of existing code,
> > > >>>> techniques, knowledge, skills, etc.
> > > >>>>
> > > >>>> So, we should develop the control plane from scratch
> > > >>> because Ethernet
> > > >>>> requires a few modifications/enhancements (which I=20
> believe are
> > > >>>> backwards
> > > >>>> compatible) to RFC3945 - that IMO is ridiculous.
> > > >>> so you seem to agree with me. departing from RFC 3945
> > makes little
> >=20
> > > >>> sense. it would have been interesting to see the doc
> > delivering a
> > > >>> FIT of the GMPLS protocol arch. blocks and, in
> > particular, label
> > > >>> allocation and distribution for Ethernet.
> > > >>>
> > > >>> thanks,
> > > >>> -dimitri.
> > > >>>> Ben
> > > >>>>
> > > >>>>
> > > >>>
> > > >=20
> > > >=20
> > > >=20
> > >=20
> > >=20
> > > --
> > > Loa Andersson
> > >=20
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                             [email-masked]
> > >=20
> >=20
> >=20
>=20

Delivery-date: Wed, 30 Jan 2008 18:03:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Mach Chen" <[email-masked]>
Subject: Getting off the fence about draft-chen-ccamp-isis-interas-te-extension
Date: Wed, 30 Jan 2008 18:00:54 -0000

Hi all,

We have an imbalance.

We accepted draft-ietf-ccamp-ospf-interas-te-extension long ago.

The ISIS I-D got stuck making some changes for the ISIS WG and then
because of the discussion around BGP-TE. the two items have been resolved:
- The I-D was revised and updated to cover the ISIS issues
- The BGP-TE I-D has been taken to the Softwires WG

Mach, can you please resubmit the current version of the draft as 
draft-ietf-ccamp-isis-interas-te-extension-00.txt

Many thanks,
Adrian 

Delivery-date: Wed, 30 Jan 2008 17:24:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 18:23:00 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Howard Green" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Howard Green [mailto:[email-masked]]=20
> Sent: Wednesday, January 30, 2008 12:09 PM
> To: PAPADIMITRIOU Dimitri; Loa Andersson
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Hi
> Dimitri seems to me to be making a very abstract and legalistic point.

receive my total disagreement. an individual submission that asks to
change an existing RFC requires discussion and particular attention (in
part., when it is the protocol arch. document) - if this not possible
then probably you have to write also a doc. asking for changing the IETF
proces - and then you come back with your individual submission.
 =20
> The reason why this work is important is that the IEEE has=20
> been evolving
> Ethernet to give it carrier class features, in respect of scalability,
> OAM, and (with 802.1Qay) the possibility to use an external control
> plane.=20

no one i think question this. and i don't think the poll is on this
specific point. CCAMP or even IETF at large is not an authority to
decide upon IEEE technos.

> Some of these features will very likely require or enable added
> value from extensions to the functionality of GMPLS - for example, as
> has already  been suggested, the addition of functionality=20
> for creating the OAM associations.=20

indeed, and your colleague has already received a list of comments to be
addressed before seeing any way forward w/ the proposed approach.=20

> Therefore this will likely not be the same as the
> possible use suggested in RFC3945, which may (at least=20
> in theory) have been implemented somewhere.=20

the exact problem, i mentionned a couple of times. your own comment
shows that one may use GMPLS differently but may i ask WHY ? and what's
the implications ?

> Therefore the suggestion in the draft seems to make sense.=20

why ?

> I can't really see what important principle is being
> defended by the insistence upon L2SC, which, as Don Fedyk stated, was
> always somewhat underspecified.

THE reason is that an interface SC or a related functionality has never
resulted in a specific change in the base protocol building blocks.
GMPLS is a generalized approach not a differentiated approach per
interface.

actually your last statement is not correct (L2SC is well specified in
RFC 3945) AND by the way yours does not at all better specify it.

> This is not something to be debated in the abstract. The work in ccamp
> should allow sensible extension of functionality where it adds value,
> and this needs to be discussed on a case by case basis. Therefore we
> should make it a working group document and get on with it.

-d.
> regards Howard Green
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of PAPADIMITRIOU Dimitri
> Sent: 30 January 2008 10:15
> To: Loa Andersson
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> loa,
>=20
>=20
> i think the main point as ccamp is whether or not we poll for a change
> or a continuation inline with RFC3945 -- when the present=20
> doc. states:=20
>=20
>   "It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.  A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
>=20
> [...]
>=20
>   "The L2SC Interface Switching Capabilities MUST
>    NOT be used to represent interfaces capable of supporting=20
> Eth-LSPs."
>=20
> it raises three issues:
>=20
> a) what was the previous L2SC def. per RFC 3945 meant for if=20
> not for use
> also in GMPLS Ethernet context ?
>=20
> b) why a "new one" ?=20
>=20
> this is not explained.
>=20
> c) what is the "new one" implying in terms of GMPLS ?
>=20
> for inst. in the intro "The intent of this document is to reuse and
> align with as much of the GMPLS protocols as possible."=20
> leaves open the
> issue of what as much as possible means.
>=20
> and on the other "Additions are made only to accommodate features of
> Ethernet that are not already supported by GMPLS." so, how shall i
> interpreet the first sentence now ? inline with point a) and b) ?
>=20
>=20
> the doc. in WG I-D status or not is not going to provide an answer to
> these questions. sentences and statements in the doc. contradict each
> other.
>=20
> thanks,
> -d.
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Loa Andersson [mailto:[email-masked]]
> > Sent: Tuesday, January 29, 2008 2:04 PM
> > To: PAPADIMITRIOU Dimitri
> > Cc: [email-masked]; [email-masked];=20
> > [email-masked]; [email-masked]; [email-masked];=20
> > [email-masked]
> > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > Dimitri,
> >=20
> > it is possible that you have a point that needs to be=20
> discussed, but=20
> > is this really something that should stop us from adopting=20
> the doc as=20
> > a working group document.
> >=20
> > /Loa
> >=20
> > PAPADIMITRIOU Dimitri wrote:
> > > neil,
> > >=20
> > >> -----Original Message-----
> > >> From: [email-masked] [mailto:[email-masked]]
> > >> Sent: Friday, January 25, 2008 2:27 PM
> > >> To: PAPADIMITRIOU Dimitri; [email-masked];=20
> > >> [email-masked]
> > >> Cc: [email-masked]; [email-masked]; [email-masked]
> > >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >>
> > >> Dimitri....see if this helps...in-line
> > >>
> > >>> -----Original Message-----
> > >>> From: [email-masked]
> > >>> [mailto:[email-masked]] On Behalf Of
> > PAPADIMITRIOU Dimitri
> > >>> Sent: 25 January 2008 11:36
> > >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > >>> Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > >>>
> > >>>
> > >>> ben
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Ben Niven-Jenkins [mailto:[email-masked]]
> > >>>> Sent: Thursday, January 24, 2008 3:40 PM
> > >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> > >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > >>>> Subject: Re: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > >>>>
> > >>>> Dimitri,
> > >>>>
> > >>>> I find your mail somewhat puzzling.
> > >>>>
> > >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> > >>> in stone and
> > >>>> nothing should modify/enhance the behaviour as specified
> > >> in RFC3945
> > >>>> which implies that when RFC3945 was produced the crystal
> > ball was
> > >>>> working extremely well and all possible future
> > applications of the
> > >>>> technology had
> > >>>> been correctly envisaged.  I don't believe that was the case.
> > >>> this is not what i say. i am concerned in stating=20
> beforehand RFC=20
> > >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20
> > >>> does not deliver any tangible explanation.
> > >> NH=3D> Is your problem that you cannot differentiate between the =
3=20
> > >> network modes (of co-cs, co-ps and cl-ps)?
> > >=20
> > > my concern wrt specific point you bring is that the today
> > definition in
> > > RFC 3945 for L2SC, and in the present case GMPLS for=20
> Ethernet (with=20
> > > local labels or domain-wide labels or any other equivalent
> > to "co-ps")
> > > does not result into a different definition than what's in.=20
> > on the other
> > > side, i do not see how would apply GMPLS for=20
> connectionless/bridged=20
> > > Ethernet.
> > >=20
> > > note also that GMPLS induces label from the interface and link=20
> > > characteristic (i.e. there is no "label type" in the
> > label/label request
> > > object.
> > >=20
> > >> If so then looking at the work on
> > >> unified modelling in SG15/Q12 may help you.  But to give a more=20
> > >> specific example here:  We can take an Ethernet traffic unit and=20
> > >> create either a cl-ps and co-ps layer network based on this...in=20
> > >> fact one
> > can image 3
> > >> different layer network cases here:
> > >> -	traditional Etherent which does not have a=20
> directed routing
> > >> function, ie uses MAC learning, broadcast unknown,=20
> STP...this is a=20
> > >> cl-ps layer network
> > >> -	Ethernet with an IGP providing a directed routing
> > >> function....this is also a cl-ps layer network, but it is
> > different to
> > >> the one above
> > >> -	Ethernet with a directed routing component=20
> (centralised or
> > >> distributed, ie IGP) and a signalling component that can create=20
> > >> connections....this would be a co-ps layer network.
> > >>
> > >> These are all based on a similar traffic unit, however=20
> they form 3=20
> > >> quite different layer networks (and in functional architecture=20
> > >> terms we would say 'the Characteristic Information is=20
> different in=20
> > >> the 3 cases').
> > >>
> > >> Now GMPLS is applying a reusable set of CP components
> > (which is a very
> > >> good thing, as Ben points out below) for any co-cs or
> > co-ps mode layer
> > >> network.  So we are setting up *connections* in either a space,=20
> > >> freq or time dimension of resource, and it is these 3 resource
> > dimensions that
> > >> create the differences in parameters...however, the notion of a=20
> > >> connection is common across all these resource dimensions.
> >  GMPLS does
> > >> not apply to the cl-ps mode, as it plainly does not have
> > connections.
> > >=20
> > > well indeed, and this is the reason why i do not see any=20
> reason to=20
> > > open the space for a different set of mechanisms that=20
> would result=20
> > > from this new interface switching definition.
> > >=20
> > > thanks,
> > > -d.
> > > =20
> > >> That is at least how I look at this issue.
> > >>
> > >> regards, Neil
> > >>>>> the question triggered by this poll is the following: if
> > >>> GMPLS for
> > >>>>> Ethernet is not inline with the existing stacks what is
> > >>> the value of
> > >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> > >>> without its
> > >>>>> substance ? and in practice, the issue is, if it is not
> > >>>> GMPLS per RFC
> > >>>>> 3945, what's the value compared to any other native control
> > >>>> stack that
> > >>>>> would be developed at IEEE for inst. for these techno's.
> > >>>> If we ignore the peer model (which is unworkable in=20
> reality IMO),
>=20
> > >>>> the value is obvious - significant reuse of existing code,=20
> > >>>> techniques, knowledge, skills, etc.
> > >>>>
> > >>>> So, we should develop the control plane from scratch
> > >>> because Ethernet
> > >>>> requires a few modifications/enhancements (which I believe are=20
> > >>>> backwards
> > >>>> compatible) to RFC3945 - that IMO is ridiculous.
> > >>> so you seem to agree with me. departing from RFC 3945=20
> makes little
>=20
> > >>> sense. it would have been interesting to see the doc=20
> delivering a=20
> > >>> FIT of the GMPLS protocol arch. blocks and, in=20
> particular, label=20
> > >>> allocation and distribution for Ethernet.
> > >>>
> > >>> thanks,
> > >>> -dimitri.
> > >>>> Ben
> > >>>>
> > >>>>
> > >>>
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> > --
> > Loa Andersson
> >=20
> > Principal Networking Architect
> > Acreo AB                           phone:  +46 8 632 77 14
> > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > Kista, Sweden                      email:  [email-masked]
> >                                             [email-masked]
> >=20
>=20
>=20

Delivery-date: Wed, 30 Jan 2008 16:40:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 11:39:27 -0500
From: "Don Fedyk" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>, <[email-masked]>

Hi Adrian

This sounds good to me and certainly it was not our intent to confuse
these points.  If the new text can us forward that would be great.=20

Thanks,
Don =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 30, 2008 10:28 AM
> To: [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> All,
>=20
> We appear to be seeing good support for this document, and=20
> that suggests=20
> that we should take it forward, but I would like to at least=20
> make an attempt=20
> to close down the point raised by Dimitri. As Howard points=20
> out, this is in=20
> danger of becoming a legalistic discussion, but I've never=20
> been one to=20
> refuse the opportunity to back to first principles...
>=20
> In RFC 3945 we have...
>=20
>    A link may support a set of encoding formats, where support means
>    that a link is able to carry and switch a signal of one or more of
>    these encoding formats.  The Switching Type indicates then the type
>    of switching that should be performed on a particular link for that
>    LSP.  This information is needed for links that advertise more than
>    one type of switching capability.
>=20
>    Nodes must verify that the type indicated in the Switching Type is
>    supported on the corresponding incoming interface; otherwise, the
>    node must generate a notification message with a "Routing
>    problem/Switching Type" indication.
>=20
> Now, the question is whether we are introducing one (or more)=20
> new Switching=20
> Type and whether we need to be able to distinguish between=20
> them. Suppose=20
> (for the sake of argument) that we will over time introduce=20
> the ability to=20
> switch Ethernet frames under GMPLS control based on several=20
> different label=20
> concepts:
> - 802.1Qay
> - destination MAC only
> - destination MAC and VLAN tag
> It is likely that a GMPLS-capable Ethernet switch will want=20
> to support more=20
> than one of these switching paradigms on any single=20
> interface. So we have to=20
> decide how, during signaling, we indicate which type of LSP=20
> is requested.
>=20
> There are plenty of ways that this could be done. Currently we use a=20
> combination of the parameters of the=20
> Generalized_Label_Request object and=20
> the Sender_TSpec object. The TSpec is used in the case of TDM=20
> (RFC 4606) and=20
> Ethernet to distinguish the Switching Granularity=20
> (draft-ietf-ccamp-ethernet-traffic-parameters).
>=20
> As I see it, the text at issue in=20
> draft-gmpls-ethernet-arch-00.txt causes a=20
> problem because it appears to say that *no* Ethernet Label=20
> Switched Path=20
> (Eth-LSP) can be set up using an L2SC Switching Type.
>    It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.
>=20
> However, the draft also says...
>    A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
>=20
> And this clearly says that L2SC *is* allowed.
>=20
> Can we fix this by agreeing some new wording?
>=20
> =3D=3D
> OLD
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS extensions,
>    e.g., label formats, switching types, and Traffic Engineering (TE)
>    routing extensions.  It is expected that all such=20
> extensions will be
>    consistent with this document. It is expected that there will be no
>    case where an Eth-LSP will be signaled, or an Eth-LSP supporting
>    interface will be represented, using the L2SC switching
>    type/capability.  A new switching type/capability is required to
>    avoid any potential current usage of the L2SC switching
>    type/capability in support of Ethernet.
> NEW
>    This document does not define any specific format for an Eth-LSP
>    label. Rather, it is expected that service specific documents will
>    define any signaling and routing extensions needed to support that
>    specific Ethernet service.  Depending on the requirements of a
>    service, it may be necessary to define multiple GMPLS protocol
>    extensions and procedures. It is expected that all such extensions
>    will be consistent with this document.
>=20
>    It is expected that key a requirement will be to describe label
>    formats and encodings. It may also be necessary to provide a
>    mechanism to identify the required Ethernet service type=20
> in signaling
>    and a way to advertise the capabilities of Ethernet switches in the
>    routing protocols. These mechanisms must make it possible to
>    distinguish between requests for different paradigms including new,
>    future, and existing paradigms.
>=20
>    The Switching Type and Interface Switching Capability Descriptor
>    share a common set of values and are defined in [RFC3945],=20
> [RFC3471],
>    and [RFC4202] as indicators of the type of switching that should
>    ([RFC3471]) and can ([RFC4202]) be performed on a=20
> particular link for
>    an LSP. The L2SC switching type is available for use by
>    implementations performing layer 2 switching including ATM and
>    Ethernet. To support the continued use of that switching type by
>    existing implementations as well as to distinguish between each new
>    Ethernet switching paradigm, a new switching type is expected to be
>    needed for each new Ethernet switching paradigm that is supported.
> =3D=3D
>=20
> Thanks,
> Adrian=20
>=20
>=20
>=20
>=20

Delivery-date: Wed, 30 Jan 2008 15:30:16 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 15:27:30 -0000

All,

We appear to be seeing good support for this document, and that suggests 
that we should take it forward, but I would like to at least make an attempt 
to close down the point raised by Dimitri. As Howard points out, this is in 
danger of becoming a legalistic discussion, but I've never been one to 
refuse the opportunity to back to first principles...

In RFC 3945 we have...

   A link may support a set of encoding formats, where support means
   that a link is able to carry and switch a signal of one or more of
   these encoding formats.  The Switching Type indicates then the type
   of switching that should be performed on a particular link for that
   LSP.  This information is needed for links that advertise more than
   one type of switching capability.

   Nodes must verify that the type indicated in the Switching Type is
   supported on the corresponding incoming interface; otherwise, the
   node must generate a notification message with a "Routing
   problem/Switching Type" indication.

Now, the question is whether we are introducing one (or more) new Switching 
Type and whether we need to be able to distinguish between them. Suppose 
(for the sake of argument) that we will over time introduce the ability to 
switch Ethernet frames under GMPLS control based on several different label 
concepts:
- 802.1Qay
- destination MAC only
- destination MAC and VLAN tag
It is likely that a GMPLS-capable Ethernet switch will want to support more 
than one of these switching paradigms on any single interface. So we have to 
decide how, during signaling, we indicate which type of LSP is requested.

There are plenty of ways that this could be done. Currently we use a 
combination of the parameters of the Generalized_Label_Request object and 
the Sender_TSpec object. The TSpec is used in the case of TDM (RFC 4606) and 
Ethernet to distinguish the Switching Granularity 
(draft-ietf-ccamp-ethernet-traffic-parameters).

As I see it, the text at issue in draft-gmpls-ethernet-arch-00.txt causes a 
problem because it appears to say that *no* Ethernet Label Switched Path 
(Eth-LSP) can be set up using an L2SC Switching Type.
   It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.

However, the draft also says...
   A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.

And this clearly says that L2SC *is* allowed.

Can we fix this by agreeing some new wording?

==
OLD
   This document does not define any specific format for an Eth-LSP
   label. Rather, it is expected that service specific documents will
   define any signaling and routing extensions needed to support that
   specific Ethernet service.  Depending on the requirements of a
   service, it may be necessary to define multiple GMPLS extensions,
   e.g., label formats, switching types, and Traffic Engineering (TE)
   routing extensions.  It is expected that all such extensions will be
   consistent with this document. It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.  A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.
NEW
   This document does not define any specific format for an Eth-LSP
   label. Rather, it is expected that service specific documents will
   define any signaling and routing extensions needed to support that
   specific Ethernet service.  Depending on the requirements of a
   service, it may be necessary to define multiple GMPLS protocol
   extensions and procedures. It is expected that all such extensions
   will be consistent with this document.

   It is expected that key a requirement will be to describe label
   formats and encodings. It may also be necessary to provide a
   mechanism to identify the required Ethernet service type in signaling
   and a way to advertise the capabilities of Ethernet switches in the
   routing protocols. These mechanisms must make it possible to
   distinguish between requests for different paradigms including new,
   future, and existing paradigms.

   The Switching Type and Interface Switching Capability Descriptor
   share a common set of values and are defined in [RFC3945], [RFC3471],
   and [RFC4202] as indicators of the type of switching that should
   ([RFC3471]) and can ([RFC4202]) be performed on a particular link for
   an LSP. The L2SC switching type is available for use by
   implementations performing layer 2 switching including ATM and
   Ethernet. To support the continued use of that switching type by
   existing implementations as well as to distinguish between each new
   Ethernet switching paradigm, a new switching type is expected to be
   needed for each new Ethernet switching paradigm that is supported.
==

Thanks,
Adrian 

Delivery-date: Wed, 30 Jan 2008 11:10:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 12:08:30 +0100
From: "Howard Green" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi
Dimitri seems to me to be making a very abstract and legalistic point.
=20
The reason why this work is important is that the IEEE has been evolving
Ethernet to give it carrier class features, in respect of scalability,
OAM, and (with 802.1Qay) the possibility to use an external control
plane. Some of these features will very likely require or enable added
value from extensions to the functionality of GMPLS - for example, as
has already  been suggested, the addition of functionality for creating
the OAM associations. Therefore this will likely not be the same as the
possible use suggested in RFC3945, which may (at least in theory) have
been implemented somewhere. Therefore the suggestion in the draft seems
to make sense. I can't really see what important principle is being
defended by the insistence upon L2SC, which, as Don Fedyk stated, was
always somewhat underspecified.

This is not something to be debated in the abstract. The work in ccamp
should allow sensible extension of functionality where it adds value,
and this needs to be discussed on a case by case basis. Therefore we
should make it a working group document and get on with it.

regards Howard Green

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of PAPADIMITRIOU Dimitri
Sent: 30 January 2008 10:15
To: Loa Andersson
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

loa,

i think the main point as ccamp is whether or not we poll for a change
or a continuation inline with RFC3945 -- when the present doc. states:=20

  "It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.  A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.

[...]

  "The L2SC Interface Switching Capabilities MUST
   NOT be used to represent interfaces capable of supporting Eth-LSPs."

it raises three issues:

a) what was the previous L2SC def. per RFC 3945 meant for if not for use
also in GMPLS Ethernet context ?

b) why a "new one" ?=20

this is not explained.

c) what is the "new one" implying in terms of GMPLS ?

for inst. in the intro "The intent of this document is to reuse and
align with as much of the GMPLS protocols as possible." leaves open the
issue of what as much as possible means.

and on the other "Additions are made only to accommodate features of
Ethernet that are not already supported by GMPLS." so, how shall i
interpreet the first sentence now ? inline with point a) and b) ?

the doc. in WG I-D status or not is not going to provide an answer to
these questions. sentences and statements in the doc. contradict each
other.

thanks,
-d.

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2008 2:04 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Dimitri,
>=20
> it is possible that you have a point that needs to be discussed, but=20
> is this really something that should stop us from adopting the doc as=20
> a working group document.
>=20
> /Loa
>=20
> PAPADIMITRIOU Dimitri wrote:
> > neil,
> >=20
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]
> >> Sent: Friday, January 25, 2008 2:27 PM
> >> To: PAPADIMITRIOU Dimitri; [email-masked];=20
> >> [email-masked]
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>
> >> Dimitri....see if this helps...in-line
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of
> PAPADIMITRIOU Dimitri
> >>> Sent: 25 January 2008 11:36
> >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>>
> >>>
> >>> ben
> >>>
> >>>> -----Original Message-----
> >>>> From: Ben Niven-Jenkins [mailto:[email-masked]]
> >>>> Sent: Thursday, January 24, 2008 3:40 PM
> >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>>>
> >>>> Dimitri,
> >>>>
> >>>> I find your mail somewhat puzzling.
> >>>>
> >>>> You appear to be saying that GMPLS as per RFC 3945 is set
> >>> in stone and
> >>>> nothing should modify/enhance the behaviour as specified
> >> in RFC3945
> >>>> which implies that when RFC3945 was produced the crystal
> ball was
> >>>> working extremely well and all possible future
> applications of the
> >>>> technology had
> >>>> been correctly envisaged.  I don't believe that was the case.
> >>> this is not what i say. i am concerned in stating beforehand RFC=20
> >>> 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the doc.=20
> >>> does not deliver any tangible explanation.
> >> NH=3D> Is your problem that you cannot differentiate between the 3=20
> >> network modes (of co-cs, co-ps and cl-ps)?
> >=20
> > my concern wrt specific point you bring is that the today
> definition in
> > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with=20
> > local labels or domain-wide labels or any other equivalent
> to "co-ps")
> > does not result into a different definition than what's in.=20
> on the other
> > side, i do not see how would apply GMPLS for connectionless/bridged=20
> > Ethernet.
> >=20
> > note also that GMPLS induces label from the interface and link=20
> > characteristic (i.e. there is no "label type" in the
> label/label request
> > object.
> >=20
> >> If so then looking at the work on
> >> unified modelling in SG15/Q12 may help you.  But to give a more=20
> >> specific example here:  We can take an Ethernet traffic unit and=20
> >> create either a cl-ps and co-ps layer network based on this...in=20
> >> fact one
> can image 3
> >> different layer network cases here:
> >> -	traditional Etherent which does not have a directed routing
> >> function, ie uses MAC learning, broadcast unknown, STP...this is a=20
> >> cl-ps layer network
> >> -	Ethernet with an IGP providing a directed routing
> >> function....this is also a cl-ps layer network, but it is
> different to
> >> the one above
> >> -	Ethernet with a directed routing component (centralised or
> >> distributed, ie IGP) and a signalling component that can create=20
> >> connections....this would be a co-ps layer network.
> >>
> >> These are all based on a similar traffic unit, however they form 3=20
> >> quite different layer networks (and in functional architecture=20
> >> terms we would say 'the Characteristic Information is different in=20
> >> the 3 cases').
> >>
> >> Now GMPLS is applying a reusable set of CP components
> (which is a very
> >> good thing, as Ben points out below) for any co-cs or
> co-ps mode layer
> >> network.  So we are setting up *connections* in either a space,=20
> >> freq or time dimension of resource, and it is these 3 resource
> dimensions that
> >> create the differences in parameters...however, the notion of a=20
> >> connection is common across all these resource dimensions.
>  GMPLS does
> >> not apply to the cl-ps mode, as it plainly does not have
> connections.
> >=20
> > well indeed, and this is the reason why i do not see any reason to=20
> > open the space for a different set of mechanisms that would result=20
> > from this new interface switching definition.
> >=20
> > thanks,
> > -d.
> > =20
> >> That is at least how I look at this issue.
> >>
> >> regards, Neil
> >>>>> the question triggered by this poll is the following: if
> >>> GMPLS for
> >>>>> Ethernet is not inline with the existing stacks what is
> >>> the value of
> >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS
> >>> without its
> >>>>> substance ? and in practice, the issue is, if it is not
> >>>> GMPLS per RFC
> >>>>> 3945, what's the value compared to any other native control
> >>>> stack that
> >>>>> would be developed at IEEE for inst. for these techno's.
> >>>> If we ignore the peer model (which is unworkable in reality IMO),

> >>>> the value is obvious - significant reuse of existing code,=20
> >>>> techniques, knowledge, skills, etc.
> >>>>
> >>>> So, we should develop the control plane from scratch
> >>> because Ethernet
> >>>> requires a few modifications/enhancements (which I believe are=20
> >>>> backwards
> >>>> compatible) to RFC3945 - that IMO is ridiculous.
> >>> so you seem to agree with me. departing from RFC 3945 makes little

> >>> sense. it would have been interesting to see the doc delivering a=20
> >>> FIT of the GMPLS protocol arch. blocks and, in particular, label=20
> >>> allocation and distribution for Ethernet.
> >>>
> >>> thanks,
> >>> -dimitri.
> >>>> Ben
> >>>>
> >>>>
> >>>
> >=20
> >=20
> >=20
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Wed, 30 Jan 2008 09:15:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 30 Jan 2008 10:14:37 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

loa,

i think the main point as ccamp is whether or not we poll for a change
or a continuation inline with RFC3945 -- when the present doc. states:=20

  "It is expected that there will be no
   case where an Eth-LSP will be signaled, or an Eth-LSP supporting
   interface will be represented, using the L2SC switching
   type/capability.  A new switching type/capability is required to
   avoid any potential current usage of the L2SC switching
   type/capability in support of Ethernet.

[...]

  "The L2SC Interface Switching Capabilities MUST
   NOT be used to represent interfaces capable of supporting Eth-LSPs."

it raises three issues:

a) what was the previous L2SC def. per RFC 3945 meant for if not for use
also in GMPLS Ethernet context ?

b) why a "new one" ?=20

this is not explained.

c) what is the "new one" implying in terms of GMPLS ?

for inst. in the intro "The intent of this document is to reuse and
align with as much of the GMPLS protocols as possible." leaves open the
issue of what as much as possible means.

and on the other "Additions are made only to accommodate features of
Ethernet that are not already supported by GMPLS." so, how shall i
interpreet the first sentence now ? inline with point a) and b) ?

the doc. in WG I-D status or not is not going to provide an answer to
these questions. sentences and statements in the doc. contradict each
other.

thanks,
-d.

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]=20
> Sent: Tuesday, January 29, 2008 2:04 PM
> To: PAPADIMITRIOU Dimitri
> Cc: [email-masked]; [email-masked];=20
> [email-masked]; [email-masked]; [email-masked];=20
> [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Dimitri,
>=20
> it is possible that you have a point that needs to be discussed,
> but is this really something that should stop us from adopting the
> doc as a working group document.
>=20
> /Loa
>=20
> PAPADIMITRIOU Dimitri wrote:
> > neil,=20
> >=20
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]]=20
> >> Sent: Friday, January 25, 2008 2:27 PM
> >> To: PAPADIMITRIOU Dimitri; [email-masked];=20
> >> [email-masked]
> >> Cc: [email-masked]; [email-masked]; [email-masked]
> >> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>
> >> Dimitri....see if this helps...in-line
> >>
> >>> -----Original Message-----
> >>> From: [email-masked]=20
> >>> [mailto:[email-masked]] On Behalf Of=20
> PAPADIMITRIOU Dimitri
> >>> Sent: 25 January 2008 11:36
> >>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> >>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> >>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>>
> >>>
> >>> ben=20
> >>>
> >>>> -----Original Message-----
> >>>> From: Ben Niven-Jenkins [mailto:[email-masked]]
> >>>> Sent: Thursday, January 24, 2008 3:40 PM
> >>>> To: PAPADIMITRIOU Dimitri; Lou Berger
> >>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> >>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >>>>
> >>>> Dimitri,
> >>>>
> >>>> I find your mail somewhat puzzling.
> >>>>
> >>>> You appear to be saying that GMPLS as per RFC 3945 is set=20
> >>> in stone and=20
> >>>> nothing should modify/enhance the behaviour as specified=20
> >> in RFC3945=20
> >>>> which implies that when RFC3945 was produced the crystal=20
> ball was=20
> >>>> working extremely well and all possible future=20
> applications of the
> >>>> technology had
> >>>> been correctly envisaged.  I don't believe that was the case.
> >>> this is not what i say. i am concerned in stating beforehand=20
> >>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20
> >>> doc. does not deliver any tangible explanation.
> >> NH=3D> Is your problem that you cannot differentiate between=20
> >> the 3 network modes (of co-cs, co-ps and cl-ps)? =20
> >=20
> > my concern wrt specific point you bring is that the today=20
> definition in
> > RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with
> > local labels or domain-wide labels or any other equivalent=20
> to "co-ps")
> > does not result into a different definition than what's in.=20
> on the other
> > side, i do not see how would apply GMPLS for connectionless/bridged
> > Ethernet. =20
> >=20
> > note also that GMPLS induces label from the interface and link
> > characteristic (i.e. there is no "label type" in the=20
> label/label request
> > object.
> >=20
> >> If so then looking at the work on
> >> unified modelling in SG15/Q12 may help you.  But to give a=20
> >> more specific
> >> example here:  We can take an Ethernet traffic unit and=20
> >> create either a
> >> cl-ps and co-ps layer network based on this...in fact one=20
> can image 3
> >> different layer network cases here:
> >> -	traditional Etherent which does not have a directed routing
> >> function, ie uses MAC learning, broadcast unknown, STP...this=20
> >> is a cl-ps
> >> layer network
> >> -	Ethernet with an IGP providing a directed routing
> >> function....this is also a cl-ps layer network, but it is=20
> different to
> >> the one above
> >> -	Ethernet with a directed routing component (centralised or
> >> distributed, ie IGP) and a signalling component that can create
> >> connections....this would be a co-ps layer network.
> >>
> >> These are all based on a similar traffic unit, however they=20
> >> form 3 quite
> >> different layer networks (and in functional architecture=20
> >> terms we would
> >> say 'the Characteristic Information is different in the 3 cases').
> >>
> >> Now GMPLS is applying a reusable set of CP components=20
> (which is a very
> >> good thing, as Ben points out below) for any co-cs or=20
> co-ps mode layer
> >> network.  So we are setting up *connections* in either a=20
> >> space, freq or
> >> time dimension of resource, and it is these 3 resource=20
> dimensions that
> >> create the differences in parameters...however, the notion of a
> >> connection is common across all these resource dimensions.=20
>  GMPLS does
> >> not apply to the cl-ps mode, as it plainly does not have=20
> connections.
> >=20
> > well indeed, and this is the reason why i do not see any reason to
> > open the space for a different set of mechanisms that would result
> > from this new interface switching definition.
> >=20
> > thanks,
> > -d.
> > =20
> >> That is at least how I look at this issue.
> >>
> >> regards, Neil
> >>>>> the question triggered by this poll is the following: if=20
> >>> GMPLS for=20
> >>>>> Ethernet is not inline with the existing stacks what is=20
> >>> the value of=20
> >>>>> GMPLS re-use ? what's the value to borrow the term GMPLS=20
> >>> without its=20
> >>>>> substance ? and in practice, the issue is, if it is not
> >>>> GMPLS per RFC
> >>>>> 3945, what's the value compared to any other native control
> >>>> stack that
> >>>>> would be developed at IEEE for inst. for these techno's.
> >>>> If we ignore the peer model (which is unworkable in reality
> >>>> IMO), the value
> >>>> is obvious - significant reuse of existing code, techniques,=20
> >>>> knowledge,
> >>>> skills, etc.
> >>>>
> >>>> So, we should develop the control plane from scratch=20
> >>> because Ethernet=20
> >>>> requires a few modifications/enhancements (which I believe are=20
> >>>> backwards
> >>>> compatible) to RFC3945 - that IMO is ridiculous.
> >>> so you seem to agree with me. departing from RFC 3945 makes=20
> >>> little sense. it would have been interesting to see the doc=20
> >>> delivering a FIT of the GMPLS protocol arch. blocks and, in=20
> >>> particular, label allocation and distribution for Ethernet.
> >>>
> >>> thanks,
> >>> -dimitri.
> >>>> Ben
> >>>>
> >>>>
> >>>
> >=20
> >=20
> >=20
>=20
>=20
> --=20
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  [email-masked]
>                                             [email-masked]
>=20

Delivery-date: Wed, 30 Jan 2008 09:01:06 +0000
Date: Wed, 30 Jan 2008 09:58:47 +0100
From: "Roland Elverljung" <[email-masked]>
To: <[email-masked]>
Cc: "DEBORAH A ATTLABS BRUNGARD" <[email-masked]>
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

In favor.

Regards
Roland Elverljung

>>> On 2008-01-22 at 20:27, in message
<[email-masked]>,
<[email-masked]> wrote:
> CCAMP,
>  
> The DT proposed in their meeting presentation for their architecture
and
> framework document to be accepted as a WG draft:
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt

>  
> We received a couple of comments in the meeting, we would appreciate
> additional feedback on the list. Please express your support (or
> otherwise) for this I-D to become a WG draft.
>  
> Thanks,
> Deborah

Delivery-date: Tue, 29 Jan 2008 20:12:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, "Scott Bradner" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Re: Draft liaison response to ITU on GMPLS Calls
Date: Tue, 29 Jan 2008 20:10:53 -0000

Duh-oh!

Before Saturday February 2nd.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; <[email-masked]>; "Scott Bradner" 
<[email-masked]>; "Brungard, Deborah A, ALABS" <[email-masked]>
Sent: Tuesday, January 29, 2008 7:43 PM
Subject: Draft liaison response to ITU on GMPLS Calls

> Hi,
>
> We need to respond to a liaison from ITU-T Study Group 15 Question 14.
> https://datatracker.ietf.org/liaison/369/
>
> Please comment before Saturday February 1st so I can send this in time.
>
> Thanks,
> Adrian
>
> ====
> To: ITU-T Q14/15
> Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, 
> CCAMP Mailing List
> Subject: Respnse to Your Liaison on GMPLS Calls
> In Response
>
> Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart 
> interim meeting in September 2007.
>
> In your liaison, you noted that the GMPLS call is assumed to be as general 
> as possible, and you asked what other call applications there may be in 
> addition to ASON and the CCAMP VCAT draft. At this moment, there are four 
> applications on which the CCAMP working group is working where GMPLS calls 
> are applied. The first two are ASON and VCAT as you note. The third is 
> related to ASON and is the multi-layer network. The fourth provides 
> support for the MEF UNI in coordination with the OIF. Other topics in the 
> future might include OAM coordination, billing, and client-facing port
> capability negotiation.
>
> Your observations about how TNA information is not used in the propagation 
> or delivery of the [call] message, but may be used [by call controllers] 
> to identify the destination UNI and hence [the destination] Network Call 
> Controller agrees with our understanding and intentions. In practice, a 
> large range of information may be used by call controllers to route 
> calls - that is, to select a series of call controllers between call 
> source and call destination - although we would not wish to preclude 
> source-routing of calls. It is our intention that the generic call message 
> should be capable of being extended to carry any information required by 
> any application of the call message.
>
> In this light you ask for guidance on how to carry ASON call information 
> across a GMPLS network so that it can be reconstructed at ASON call 
> boundaries, and say that you support the resumption of work on a CCAMP I-D 
> on ASON applicability to address the above and would welcome the 
> opportunity to contribute through liaisons. We welcome your support and 
> look forward to working with you in this context. As above, we note that 
> the GMPLS call message (the Notify message) is not limited to the exchange 
> of information between call end points, but can also exchange information 
> between
> transit call controllers by forming call segments as described in section 
> 7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS 
> call message falls within the CCAMP charter and we hope that interested 
> parties will bring ideas forward through the normal process which is, of 
> course, contribution-driven. We would welcome input from all sources 
> either through the CCAMP mailing list or through liaisons.
>
> Best regards,
> Adrian Farrel and Deborah Brungard
> CCAMP working group co-chairs
>
>
> 

Delivery-date: Tue, 29 Jan 2008 19:46:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, "Scott Bradner" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: Draft liaison response to ITU on GMPLS Calls
Date: Tue, 29 Jan 2008 19:43:45 -0000

Hi,

We need to respond to a liaison from ITU-T Study Group 15 Question 14.
https://datatracker.ietf.org/liaison/369/

Please comment before Saturday February 1st so I can send this in time.

Thanks,
Adrian

====
To: ITU-T Q14/15
Cc: Kam Lam, Steve Trowbridge, Ross Callon, Dave Ward, Scott Bradner, CCAMP 
Mailing List
Subject: Respnse to Your Liaison on GMPLS Calls
In Response

Thank you for your liaison to CCAMP on GMPLS Calls from your Stuttgart 
interim meeting in September 2007.

In your liaison, you noted that the GMPLS call is assumed to be as general 
as possible, and you asked what other call applications there may be in 
addition to ASON and the CCAMP VCAT draft. At this moment, there are four 
applications on which the CCAMP working group is working where GMPLS calls 
are applied. The first two are ASON and VCAT as you note. The third is 
related to ASON and is the multi-layer network. The fourth provides support 
for the MEF UNI in coordination with the OIF. Other topics in the future 
might include OAM coordination, billing, and client-facing port
capability negotiation.

Your observations about how TNA information is not used in the propagation 
or delivery of the [call] message, but may be used [by call controllers] to 
identify the destination UNI and hence [the destination] Network Call 
Controller agrees with our understanding and intentions. In practice, a 
large range of information may be used by call controllers to route calls - 
that is, to select a series of call controllers between call source and call 
destination - although we would not wish to preclude source-routing of 
calls. It is our intention that the generic call message should be capable 
of being extended to carry any information required by any application of 
the call message.

In this light you ask for guidance on how to carry ASON call information 
across a GMPLS network so that it can be reconstructed at ASON call 
boundaries, and say that you support the resumption of work on a CCAMP I-D 
on ASON applicability to address the above and would welcome the opportunity 
to contribute through liaisons. We welcome your support and look forward to 
working with you in this context. As above, we note that the GMPLS call 
message (the Notify message) is not limited to the exchange of information 
between call end points, but can also exchange information between
transit call controllers by forming call segments as described in section 
7.3.1 of RFC 4974. Work on carrying ASON call information within a GMPLS 
call message falls within the CCAMP charter and we hope that interested 
parties will bring ideas forward through the normal process which is, of 
course, contribution-driven. We would welcome input from all sources either 
through the CCAMP mailing list or through liaisons.

Best regards,
Adrian Farrel and Deborah Brungard
CCAMP working group co-chairs 

Delivery-date: Tue, 29 Jan 2008 13:07:24 +0000
Date: Tue, 29 Jan 2008 14:04:24 +0100
From: Loa Andersson <[email-masked]>
Organization: Acreo AB
To: PAPADIMITRIOU Dimitri <[email-masked]>
CC: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked],  [email-masked]
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

Dimitri,

it is possible that you have a point that needs to be discussed,
but is this really something that should stop us from adopting the
doc as a working group document.

/Loa

PAPADIMITRIOU Dimitri wrote:
> neil, 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> Sent: Friday, January 25, 2008 2:27 PM
>> To: PAPADIMITRIOU Dimitri; [email-masked]; 
>> [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>>
>> Dimitri....see if this helps...in-line
>>
>>> -----Original Message-----
>>> From: [email-masked] 
>>> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
>>> Sent: 25 January 2008 11:36
>>> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
>>> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>>>
>>>
>>> ben 
>>>
>>>> -----Original Message-----
>>>> From: Ben Niven-Jenkins [mailto:[email-masked]]
>>>> Sent: Thursday, January 24, 2008 3:40 PM
>>>> To: PAPADIMITRIOU Dimitri; Lou Berger
>>>> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
>>>> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>>>>
>>>> Dimitri,
>>>>
>>>> I find your mail somewhat puzzling.
>>>>
>>>> You appear to be saying that GMPLS as per RFC 3945 is set 
>>> in stone and 
>>>> nothing should modify/enhance the behaviour as specified 
>> in RFC3945 
>>>> which implies that when RFC3945 was produced the crystal ball was 
>>>> working extremely well and all possible future applications of the
>>>> technology had
>>>> been correctly envisaged.  I don't believe that was the case.
>>> this is not what i say. i am concerned in stating beforehand 
>>> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the 
>>> doc. does not deliver any tangible explanation.
>> NH=> Is your problem that you cannot differentiate between 
>> the 3 network modes (of co-cs, co-ps and cl-ps)?  
> 
> my concern wrt specific point you bring is that the today definition in
> RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with
> local labels or domain-wide labels or any other equivalent to "co-ps")
> does not result into a different definition than what's in. on the other
> side, i do not see how would apply GMPLS for connectionless/bridged
> Ethernet.  
> 
> note also that GMPLS induces label from the interface and link
> characteristic (i.e. there is no "label type" in the label/label request
> object.
> 
>> If so then looking at the work on
>> unified modelling in SG15/Q12 may help you.  But to give a 
>> more specific
>> example here:  We can take an Ethernet traffic unit and 
>> create either a
>> cl-ps and co-ps layer network based on this...in fact one can image 3
>> different layer network cases here:
>> -	traditional Etherent which does not have a directed routing
>> function, ie uses MAC learning, broadcast unknown, STP...this 
>> is a cl-ps
>> layer network
>> -	Ethernet with an IGP providing a directed routing
>> function....this is also a cl-ps layer network, but it is different to
>> the one above
>> -	Ethernet with a directed routing component (centralised or
>> distributed, ie IGP) and a signalling component that can create
>> connections....this would be a co-ps layer network.
>>
>> These are all based on a similar traffic unit, however they 
>> form 3 quite
>> different layer networks (and in functional architecture 
>> terms we would
>> say 'the Characteristic Information is different in the 3 cases').
>>
>> Now GMPLS is applying a reusable set of CP components (which is a very
>> good thing, as Ben points out below) for any co-cs or co-ps mode layer
>> network.  So we are setting up *connections* in either a 
>> space, freq or
>> time dimension of resource, and it is these 3 resource dimensions that
>> create the differences in parameters...however, the notion of a
>> connection is common across all these resource dimensions.  GMPLS does
>> not apply to the cl-ps mode, as it plainly does not have connections.
> 
> well indeed, and this is the reason why i do not see any reason to
> open the space for a different set of mechanisms that would result
> from this new interface switching definition.
> 
> thanks,
> -d.
>  
>> That is at least how I look at this issue.
>>
>> regards, Neil
>>>>> the question triggered by this poll is the following: if 
>>> GMPLS for 
>>>>> Ethernet is not inline with the existing stacks what is 
>>> the value of 
>>>>> GMPLS re-use ? what's the value to borrow the term GMPLS 
>>> without its 
>>>>> substance ? and in practice, the issue is, if it is not
>>>> GMPLS per RFC
>>>>> 3945, what's the value compared to any other native control
>>>> stack that
>>>>> would be developed at IEEE for inst. for these techno's.
>>>> If we ignore the peer model (which is unworkable in reality
>>>> IMO), the value
>>>> is obvious - significant reuse of existing code, techniques, 
>>>> knowledge,
>>>> skills, etc.
>>>>
>>>> So, we should develop the control plane from scratch 
>>> because Ethernet 
>>>> requires a few modifications/enhancements (which I believe are 
>>>> backwards
>>>> compatible) to RFC3945 - that IMO is ridiculous.
>>> so you seem to agree with me. departing from RFC 3945 makes 
>>> little sense. it would have been interesting to see the doc 
>>> delivering a FIT of the GMPLS protocol arch. blocks and, in 
>>> particular, label allocation and distribution for Ethernet.
>>>
>>> thanks,
>>> -dimitri.
>>>> Ben
>>>>
>>>>
>>>
> 
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]

Delivery-date: Sat, 26 Jan 2008 08:53:13 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Sat, 26 Jan 2008 08:45:44 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Thanks Dimitri...I think I am understanding your concern/point a little
better now......please see further comments below (I've snipped the mail
to the salient bits):

> > DP=3D> this is not what i say. i am concerned in stating beforehand
> > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20
> > > doc. does not deliver any tangible explanation.
> >=20
> > NH=3D> Is your problem that you cannot differentiate between
> > the 3 network modes (of co-cs, co-ps and cl-ps)? =20
>=20
> my concern wrt specific point you bring is that the today=20
> definition in RFC 3945 for L2SC,
NH=3D> I really don't think you should get too hung-up on what folks =
have
called things here, ie L2SC.  Stick with the physics.  Much of the
misunderstandings I've encountered over many years stem from the OSI Ref
Model, and the wrong impression it gives that there is only one/single
'L3 network'....it's a myth.  ALL networks (any mode) are 'L3' in the
OSI sense.  Folks also tend to make the wrong association IP=3DL3 and
since IP is cl-ps then cl-ps=3DL3.....then they come to Ethernet and
because this is often used as a server to IP they call it 'L2' (OSI
sense).  But since native Ethernet is cl-ps then surely this must also
be L3?  Of course it is L3...all networks are!

The only thing that truly matters is whether the resource you are
partitioning and labelling is time, freq or space in nature....and it's
then up to us as engineers how well we go about functionally
specifying/equipping the layer networks we create in each of the 3
modes.  And most critically here one can ONLY get deterministic resource
assignment across a network if one creates a connection object.  I could
carry on here and go into great detail of exactly how all this works and
why we have the 3 network modes, but I'll refer you to the work on
unified modelling under Q12 of SG15. =20

Bottom-line:  Look to the real world of networking and ask yourself why
it is we see the 3 network modes....it really is not chance, but simply
comes down to the physics of partitioning/labelling a finite resource
(time/freq/space) domain....don't get hung-up on names for things
without such a scientific basis.

> GMPLS for Ethernet (with local labels or domain-wide labels=20
> or any other equivalent to "co-ps") does not result into a=20
> different definition than what's in. on the other side, i do=20
> not see how would apply GMPLS for connectionless/bridged Ethernet.
NH=3D> I agree with you.  GMPLS is a suite of CP functional components =
for
use in co mode layer networks.

But my position is one based on an understanding of the physics at play
here.  This is why I tried to point out in my prior mail the importance
of understanding that we can take an Ethernet traffic unit (packet) and
apply either a cl-ps or co-ps mode behaviour to it (as a network).  This
is our choice.  This does however require that specific functional
fields of the traffic unit are present....in essence one can take
short-cuts with labelling (ie remove information) in the co modes (eg
omit SA, use link-local DA proxy labels that get swapped per hop)
because we have a connection as a network object, but one can't take
these short-cuts in the cl-ps mode because we don't have a connection.
I'll assume this is obvious to everyone.....but it does require (from
information considerations) that folks properly understand what a
connection is (and also what it is not).

But be very clear on this point:  If we use a common traffic unit to
create a cl-ps mode layer network and a co-ps mode layer network then
these are 2 quite distinct layer networks, ie they do not operate in the
same layer network space.....put more simply, we have to be careful not
to mix-up their traffic units.  The key points here are all to do with
what we call 'characteristic information' in func arch terminology, and
specifically how one assigns/manages resource.  This is perhaps less
clear to see in the co-ps mode than the co-cs mode when compared to the
cl-ps mode.  That is:  In the co-cs mode labelling and resource
assignment are fixed/deterministic actions, but in the co-ps mode they
are decoupled actions....and whilst this flexibility has some
advantages, it also carries a responsibility that lies with those
designing co-ps mode layer networks not to screw things up, eg one can
create merging constructs which result in complex resource and
fault/perf management problems for network operators...actually the
resource problem is intractable, and the only practical solution is to
throw BW at the problem.

regards, Neil

Delivery-date: Fri, 25 Jan 2008 19:51:28 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Fri, 25 Jan 2008 20:49:41 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

neil,=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> Sent: Friday, January 25, 2008 2:27 PM
> To: PAPADIMITRIOU Dimitri; [email-masked];=20
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Dimitri....see if this helps...in-line
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> > Sent: 25 January 2008 11:36
> > To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> >=20
> > ben=20
> >=20
> > > -----Original Message-----
> > > From: Ben Niven-Jenkins [mailto:[email-masked]]
> > > Sent: Thursday, January 24, 2008 3:40 PM
> > > To: PAPADIMITRIOU Dimitri; Lou Berger
> > > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > Dimitri,
> > >=20
> > > I find your mail somewhat puzzling.
> > >=20
> > > You appear to be saying that GMPLS as per RFC 3945 is set=20
> > in stone and=20
> > > nothing should modify/enhance the behaviour as specified=20
> in RFC3945=20
> > > which implies that when RFC3945 was produced the crystal ball was=20
> > > working extremely well and all possible future applications of the
> > > technology had
> > > been correctly envisaged.  I don't believe that was the case.
> >=20
> > this is not what i say. i am concerned in stating beforehand=20
> > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20
> > doc. does not deliver any tangible explanation.
>=20
> NH=3D> Is your problem that you cannot differentiate between=20
> the 3 network modes (of co-cs, co-ps and cl-ps)? =20

my concern wrt specific point you bring is that the today definition in
RFC 3945 for L2SC, and in the present case GMPLS for Ethernet (with
local labels or domain-wide labels or any other equivalent to "co-ps")
does not result into a different definition than what's in. on the other
side, i do not see how would apply GMPLS for connectionless/bridged
Ethernet. =20

note also that GMPLS induces label from the interface and link
characteristic (i.e. there is no "label type" in the label/label request
object.

> If so then looking at the work on
> unified modelling in SG15/Q12 may help you.  But to give a=20
> more specific
> example here:  We can take an Ethernet traffic unit and=20
> create either a
> cl-ps and co-ps layer network based on this...in fact one can image 3
> different layer network cases here:
> -	traditional Etherent which does not have a directed routing
> function, ie uses MAC learning, broadcast unknown, STP...this=20
> is a cl-ps
> layer network
> -	Ethernet with an IGP providing a directed routing
> function....this is also a cl-ps layer network, but it is different to
> the one above
> -	Ethernet with a directed routing component (centralised or
> distributed, ie IGP) and a signalling component that can create
> connections....this would be a co-ps layer network.
>=20
> These are all based on a similar traffic unit, however they=20
> form 3 quite
> different layer networks (and in functional architecture=20
> terms we would
> say 'the Characteristic Information is different in the 3 cases').
>=20
> Now GMPLS is applying a reusable set of CP components (which is a very
> good thing, as Ben points out below) for any co-cs or co-ps mode layer
> network.  So we are setting up *connections* in either a=20
> space, freq or
> time dimension of resource, and it is these 3 resource dimensions that
> create the differences in parameters...however, the notion of a
> connection is common across all these resource dimensions.  GMPLS does
> not apply to the cl-ps mode, as it plainly does not have connections.

well indeed, and this is the reason why i do not see any reason to
open the space for a different set of mechanisms that would result
from this new interface switching definition.

thanks,
-d.
=20
> That is at least how I look at this issue.
>=20
> regards, Neil
> >=20
> > > > the question triggered by this poll is the following: if=20
> > GMPLS for=20
> > > > Ethernet is not inline with the existing stacks what is=20
> > the value of=20
> > > > GMPLS re-use ? what's the value to borrow the term GMPLS=20
> > without its=20
> > > > substance ? and in practice, the issue is, if it is not
> > > GMPLS per RFC
> > > > 3945, what's the value compared to any other native control
> > > stack that
> > > > would be developed at IEEE for inst. for these techno's.
> > >=20
> > > If we ignore the peer model (which is unworkable in reality
> > > IMO), the value
> > > is obvious - significant reuse of existing code, techniques,=20
> > > knowledge,
> > > skills, etc.
> > >=20
> > > So, we should develop the control plane from scratch=20
> > because Ethernet=20
> > > requires a few modifications/enhancements (which I believe are=20
> > > backwards
> > > compatible) to RFC3945 - that IMO is ridiculous.
> >=20
> > so you seem to agree with me. departing from RFC 3945 makes=20
> > little sense. it would have been interesting to see the doc=20
> > delivering a FIT of the GMPLS protocol arch. blocks and, in=20
> > particular, label allocation and distribution for Ethernet.
> >=20
> > thanks,
> > -dimitri.
> > > Ben
> > >=20
> > >=20
> >=20
> >=20
>=20

Delivery-date: Fri, 25 Jan 2008 18:28:48 +0000
Content-class: urn:content-classes:message
Subject: Question on TLV Length Calculation
Date: Fri, 25 Jan 2008 13:26:58 -0500
From: "Ong, Lyndon" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85F7F.DF993ECD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Folks,
=20
Simple question on length calculation for RSVP-TE TLVs:  I've noticed
that=20
draft-ietf-ccamp-ethernet-traffic-parameters-03.txt has adopted a method
of
calculating TLV length from RFC 4420, where the length includes only the
value portion of the TLV, and does not include the header (type and
length
bytes) or any padding bytes.
=20
This is a bit different from how length is computed for objects and
sub-objects,
where length includes header as well.  Having not followed the
discussion=20
on RFC 4420 closely, can someone clarify:
=20
-- is this method of length calculation to be followed on all new TLVs
defined
for RSVP-TE?
=20
-- if not, is there some basis for deciding what calculation to follow
when=20
defining a new TLV?
=20
Thanks,
=20
Lyndon

------_=_NextPart_001_01C85F7F.DF993ECD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>Hi=20
Folks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>Simple =
question on=20
length calculation for RSVP-TE TLVs:&nbsp; I've noticed that=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008>draft-ietf-ccamp-ethernet-traffic-parameters-0=
3.txt has=20
adopted a method of</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D245191518-25012008>calculating TLV=20
length from RFC 4420, where the length includes only =
the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>value =
portion of the=20
TLV, and does not include the header (type and =
length</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>bytes) =
or any=20
padding bytes.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>This =
is a bit=20
different from how length is computed for objects and=20
sub-objects,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>where =
length=20
includes header as well.&nbsp; Having not followed the discussion=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>on RFC =
4420 closely,=20
can someone clarify:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>-- is =
this method of=20
length calculation to be followed on all new TLVs =
defined</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>for=20
RSVP-TE?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D245191518-25012008>-- if =
not, is there=20
some basis for deciding what calculation to follow when =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D245191518-25012008>defining a new=20
TLV?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D245191518-25012008>Lyndon</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C85F7F.DF993ECD--

Delivery-date: Fri, 25 Jan 2008 13:55:27 +0000
Date: Fri, 25 Jan 2008 13:54:23 +0000
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
From: Ben Niven-Jenkins <[email-masked]>
To: PAPADIMITRIOU Dimitri <[email-masked]>, Lou Berger <[email-masked]>
CC: Don Fedyk <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

On 25/1/08 11:36, "PAPADIMITRIOU Dimitri"
<[email-masked]> wrote:
> this is not what i say. i am concerned in stating beforehand
> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the
> doc. does not deliver any tangible explanation.

OK, now I understand your concerns.  So, I think we're (you, me & the docs
authors) are actually in agreement in our thinking, just maybe that the
original wording in the doc was not the best.  I'm sure the authors can do
some wordsmithing once it is a WG doc.

> so you seem to agree with me. departing from RFC 3945 makes
> little sense. it would have been interesting to see the doc
> delivering a FIT of the GMPLS protocol arch. blocks and, in
> particular, label allocation and distribution for Ethernet.

Departing from RFC3945 for the sake of it makes little sense.  If there is a
justifiable reason to depart then that is fine IMO.

Ben

Delivery-date: Fri, 25 Jan 2008 13:29:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Fri, 25 Jan 2008 13:26:40 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Dimitri....see if this helps...in-line

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: 25 January 2008 11:36
> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
>=20
> ben=20
>=20
> > -----Original Message-----
> > From: Ben Niven-Jenkins [mailto:[email-masked]]
> > Sent: Thursday, January 24, 2008 3:40 PM
> > To: PAPADIMITRIOU Dimitri; Lou Berger
> > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > Dimitri,
> >=20
> > I find your mail somewhat puzzling.
> >=20
> > You appear to be saying that GMPLS as per RFC 3945 is set=20
> in stone and=20
> > nothing should modify/enhance the behaviour as specified in RFC3945=20
> > which implies that when RFC3945 was produced the crystal ball was=20
> > working extremely well and all possible future applications of the
> > technology had
> > been correctly envisaged.  I don't believe that was the case.
>=20
> this is not what i say. i am concerned in stating beforehand=20
> RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the=20
> doc. does not deliver any tangible explanation.

NH=3D> Is your problem that you cannot differentiate between the 3 =
network
modes (of co-cs, co-ps and cl-ps)?  If so then looking at the work on
unified modelling in SG15/Q12 may help you.  But to give a more specific
example here:  We can take an Ethernet traffic unit and create either a
cl-ps and co-ps layer network based on this...in fact one can image 3
different layer network cases here:
-	traditional Etherent which does not have a directed routing
function, ie uses MAC learning, broadcast unknown, STP...this is a cl-ps
layer network
-	Ethernet with an IGP providing a directed routing
function....this is also a cl-ps layer network, but it is different to
the one above
-	Ethernet with a directed routing component (centralised or
distributed, ie IGP) and a signalling component that can create
connections....this would be a co-ps layer network.

These are all based on a similar traffic unit, however they form 3 quite
different layer networks (and in functional architecture terms we would
say 'the Characteristic Information is different in the 3 cases').

Now GMPLS is applying a reusable set of CP components (which is a very
good thing, as Ben points out below) for any co-cs or co-ps mode layer
network.  So we are setting up *connections* in either a space, freq or
time dimension of resource, and it is these 3 resource dimensions that
create the differences in parameters...however, the notion of a
connection is common across all these resource dimensions.  GMPLS does
not apply to the cl-ps mode, as it plainly does not have connections.

That is at least how I look at this issue.

regards, Neil
>=20
> > > the question triggered by this poll is the following: if=20
> GMPLS for=20
> > > Ethernet is not inline with the existing stacks what is=20
> the value of=20
> > > GMPLS re-use ? what's the value to borrow the term GMPLS=20
> without its=20
> > > substance ? and in practice, the issue is, if it is not
> > GMPLS per RFC
> > > 3945, what's the value compared to any other native control
> > stack that
> > > would be developed at IEEE for inst. for these techno's.
> >=20
> > If we ignore the peer model (which is unworkable in reality
> > IMO), the value
> > is obvious - significant reuse of existing code, techniques,=20
> > knowledge,
> > skills, etc.
> >=20
> > So, we should develop the control plane from scratch=20
> because Ethernet=20
> > requires a few modifications/enhancements (which I believe are=20
> > backwards
> > compatible) to RFC3945 - that IMO is ridiculous.
>=20
> so you seem to agree with me. departing from RFC 3945 makes=20
> little sense. it would have been interesting to see the doc=20
> delivering a FIT of the GMPLS protocol arch. blocks and, in=20
> particular, label allocation and distribution for Ethernet.
>=20
> thanks,
> -dimitri.
> > Ben
> >=20
> >=20
>=20
>=20

Delivery-date: Fri, 25 Jan 2008 11:38:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Fri, 25 Jan 2008 12:36:23 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

ben=20

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]]=20
> Sent: Thursday, January 24, 2008 3:40 PM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Dimitri,
>=20
> I find your mail somewhat puzzling.
>=20
> You appear to be saying that GMPLS as per RFC 3945 is set in stone and
> nothing should modify/enhance the behaviour as specified in=20
> RFC3945 which
> implies that when RFC3945 was produced the crystal ball was working
> extremely well and all possible future applications of the=20
> technology had
> been correctly envisaged.  I don't believe that was the case.

this is not what i say. i am concerned in stating beforehand
RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the
doc. does not deliver any tangible explanation.

> > the question triggered by this poll is the following: if GMPLS for
> > Ethernet is not inline with the existing stacks what is the value of
> > GMPLS re-use ? what's the value to borrow the term GMPLS without its
> > substance ? and in practice, the issue is, if it is not=20
> GMPLS per RFC
> > 3945, what's the value compared to any other native control=20
> stack that
> > would be developed at IEEE for inst. for these techno's.
>=20
> If we ignore the peer model (which is unworkable in reality=20
> IMO), the value
> is obvious - significant reuse of existing code, techniques,=20
> knowledge,
> skills, etc.
>=20
> So, we should develop the control plane from scratch because Ethernet
> requires a few modifications/enhancements (which I believe=20
> are backwards
> compatible) to RFC3945 - that IMO is ridiculous.

so you seem to agree with me. departing from RFC 3945 makes
little sense. it would have been interesting to see the doc
delivering a FIT of the GMPLS protocol arch. blocks and, in
particular, label allocation and distribution for Ethernet.

thanks,
-dimitri.
> Ben
>=20
>=20

Delivery-date: Fri, 25 Jan 2008 09:48:42 +0000
Date: Thu, 24 Jan 2008 14:40:00 +0000
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
From: Ben Niven-Jenkins <[email-masked]>
To: PAPADIMITRIOU Dimitri <[email-masked]>, Lou Berger <[email-masked]>
CC: Don Fedyk <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Dimitri,

I find your mail somewhat puzzling.

You appear to be saying that GMPLS as per RFC 3945 is set in stone and
nothing should modify/enhance the behaviour as specified in RFC3945 which
implies that when RFC3945 was produced the crystal ball was working
extremely well and all possible future applications of the technology had
been correctly envisaged.  I don't believe that was the case.

> the question triggered by this poll is the following: if GMPLS for
> Ethernet is not inline with the existing stacks what is the value of
> GMPLS re-use ? what's the value to borrow the term GMPLS without its
> substance ? and in practice, the issue is, if it is not GMPLS per RFC
> 3945, what's the value compared to any other native control stack that
> would be developed at IEEE for inst. for these techno's.

If we ignore the peer model (which is unworkable in reality IMO), the value
is obvious - significant reuse of existing code, techniques, knowledge,
skills, etc.

So, we should develop the control plane from scratch because Ethernet
requires a few modifications/enhancements (which I believe are backwards
compatible) to RFC3945 - that IMO is ridiculous.

Ben

Delivery-date: Fri, 25 Jan 2008 09:06:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Fri, 25 Jan 2008 10:03:29 +0100
From: "Diego Caviglia" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85F31.21C359D3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I support this as WG even if I'd like to have the Dimitri questions =
addressed, may in next WG version of the doc.

=20

LBR

Diego

=20

________________________________

From: [email-masked] [mailto:[email-masked]] On =
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: marted=EC 22 gennaio 2008 20.28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

=20

CCAMP,

=20

The DT proposed in their meeting presentation for their architecture and =
framework document to be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt

=20

We received a couple of comments in the meeting, we would appreciate =
additional feedback on the list. Please express your support (or =
otherwise) for this I-D to become a WG draft.

=20

Thanks,

Deborah

------_=_NextPart_001_01C85F31.21C359D3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[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]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I support this as WG even if =
I&#8217;d
like to have the Dimitri questions addressed, may in next WG version of =
the
doc.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>LBR<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><br>
Diego<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
[email-masked]
[mailto:[email-masked]] <b><span style=3D'font-weight:bold'>On =
Behalf
Of </span></b>BRUNGARD, DEBORAH A, ATTLABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> marted=EC 22 =
gennaio 2008
20.28<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed WG =
Draft -
draft-gmpls-ethernet-arch-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The DT proposed in their meeting =
presentation&nbsp;for their
architecture and framework document&nbsp;to be&nbsp;accepted as =
a&nbsp;WG
draft:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We received a couple of comments&nbsp;in the meeting, =
we
would appreciate additional feedback&nbsp;on the list. Please express =
your
support (or otherwise) for this I-D to become a WG =
draft.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Deborah</span></font><o:p></o:p></p>

</div>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C85F31.21C359D3--

Delivery-date: Thu, 24 Jan 2008 23:32:31 +0000
Content-class: urn:content-classes:message
Subject: LSPID for Segment Recovery
Date: Thu, 24 Jan 2008 17:27:16 -0600
From: "Bardalai, Snigdho" <[email-masked]>
To: "Ccamp (E-mail)" <[email-masked]>
Cc: "Adrian Farrel (E-mail)" <[email-masked]>, "Lou Berger (E-mail)" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85EE0.A815503E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have a doubt on the relationship between LSPID and association ID for =
tunnels with segment recovery. Would appreciate it if someone could =
clarify.

RFC4872 suggests using the working LSP's LSPID as the association ID in =
the ASSOCIATION object for the recovery LSP and the reverse for the =
working LSP and RFC4873 requires the use of this definition as per the =
following extract:

2.  Segment Recovery

   snip ...... snip

   When [RFC4090] isn't being used, the association between segment
   recovery LSPs with other LSPs is indicated using the ASSOCIATION
   object defined in [RFC4872]

   snip......

I would expect this definition includes the way the association ID value =
should be assigned, is my understanding correct?=20

I can understand how the ASSOCIATION object for the recovery LSP can =
have its association ID set to the working LSP LSPID but it may not be =
possible for the reverse since there could be multiple recovery LSP =
segments.=20

I would like to understand what should the working LSP association ID be =
in case of segment recovery, should it be set to its own LSPID?

Also, my understanding is that the association ID needs to be unique in =
the context of the association source, if that is the case does it mean =
if LSPID is used as the association ID then the LSPID should also be =
unique in the context of the association source rather than the context =
of a tunnel.

Thanks,
Snigdho

------_=_NextPart_001_01C85EE0.A815503E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>LSPID for Segment Recovery</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a doubt on the relationship =
between LSPID and association ID for tunnels with segment recovery. =
Would appreciate it if someone could clarify.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">RFC4872 suggests using the working =
LSP's LSPID as the association ID in the ASSOCIATION object for the =
recovery LSP and the reverse for the working LSP and RFC4873 requires =
the use of this definition as per the following extract:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2.&nbsp; Segment Recovery</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; snip ...... snip</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; When [RFC4090] isn't being =
used, the association between segment</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; recovery LSPs with other =
LSPs is indicated using the ASSOCIATION</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; object defined in =
[RFC4872]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; snip......</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would expect this definition includes =
the way the association ID value should be assigned, is my understanding =
correct? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I can understand how the ASSOCIATION =
object for the recovery LSP can have its association ID set to the =
working LSP LSPID but it may not be possible for the reverse since there =
could be multiple recovery LSP segments. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to understand what should =
the working LSP association ID be in case of segment recovery, should it =
be set to its own LSPID?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, my understanding is that the =
association ID needs to be unique in the context of the association =
source, if that is the case does it mean if LSPID is used as the =
association ID then the LSPID should also be unique in the context of =
the association source rather than the context of a tunnel.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Snigdho</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C85EE0.A815503E--

Delivery-date: Thu, 24 Jan 2008 17:51:29 +0000
Date: Thu, 24 Jan 2008 09:49:39 -0800
From: Greg Bernstein <[email-masked]>
To: ccamp <[email-masked]>
CC: Adrian Farrel <[email-masked]>
Subject: Calls, Connections and VCAT...

Hello all, and Adrian and "GMPLS call" authors in particular.
I've been reviewing the requirements for VCAT/LCAS and potential 
additions, the definition of "call" from G.8081 (2004) and trying to 
reconcile these in an efficient manner so we can move forward with the 
GMPLS/VCAT draft.

Definitions from G.8081:
3.2.6 call: An association between endpoints that supports an instance 
of a service.
3.2.7 call control: Call control is a signalling association between one 
or more user applications
and the network to control the set-up, release, modification and 
maintenance of sets of connections.

Additional information from G.8080 (2006) section 5.1: "Additionally, 
call control is provided at
interlayer NCC boundaries."

 From these definitions it seems that the use of "call control" to 
coordinate an inverse multiplexing technology is actually recommended 
(since this is the domain boundary between to layers).

However in trying to use RFC4974 along with the additional requirements 
that have come up (and seem desired), I seem to have a problem when I 
want to utilize an existing connection with a new call. In RFC4974.

Section 5.2.2. It says: "The Connections (LSPs) associated with a Call 
need to carry a reference to the Call - the short Call ID.  A new field 
is added to the signaling protocol to identify an individual LSP with 
the Call to which it belongs." 

This is where the complications come in, since we cannot change 
"session"  information on an LSP and hence can't change the Call ID.  
But do we always need the call ID with the LSP?  In section 4.2 of 
RFC4974 the hierarchy of of calls, connections, tunnels and LSP is given 
and it seems that (Session, Tunnel ID,  LSP ID) can be used to uniquely 
identify the LSP too.

The feedback I received concerning VCAT signaling approaches included:
(a) support for Notify based mechanism
(b) strong opposition to the current multiple VCGs per call work around 
for "resource sharing"
(c) mild interest, but no proposals in something else entirely.

Hence at this stage and based on my reading of G.8080, G.8081, I'd like 
to try to fix the "call" approach. Other solution proposals are welcome, 
but I will not be actively pursuing them.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 24 Jan 2008 16:03:40 +0000
Date: Thu, 24 Jan 2008 11:00:34 -0500
To: [email-masked]
From: Lou Berger <[email-masked]>
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>

All,

I think this level of theoretical/hypothetical discussion can 
continue ad infinitum.  I propose we leave the text as is, and 
revisit the decision (and text) in the context of the anticipated 
mechanism specific documents if and when someone propose to use L2SC.

WG-chairs,
         Does this make sense?  Is it acceptable?

Thanks,
Lou

At 09:51 PM 1/23/2008, Don Fedyk wrote:
>Hi Dimitri
>
>The document clearly states:
>
>"The intent of this document is to reuse and align with as much of the
>    GMPLS protocols as possible.  For example reusing the IP control
>    plane addressing allows the existing signaling, routing, LMP and path
>    computation to be used as specified. Additions are made only to
>    accommodate features of Ethernet that are not already supported by
>    GMPLS.  The GMPLS protocols support a set of tools for hierarchical
>    LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms
>    support a variety of networks from peer to peer to UNIs and NNIs."
>
>So your question comes down to why we make the statement on L2SC?  Like
>Lou said when we discussed this we thought that L2SC came with baggage
>and was not precise. The switching capabilities would be specified in
>documents that address the particular Ethernet data plane.  It is true
>that if there was a valid Ethernet data plane that could use L2SC
>unambiguously it should fit under the architecture.  At any rate getting
>this right is something that can be accomplished when this is a WG
>draft.
>
>Regards,
>Don
>
>
>
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri
> > [mailto:[email-masked]]
> > Sent: Wednesday, January 23, 2008 7:05 PM
> > To: Lou Berger
> > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > the question triggered by this poll is the following: if GMPLS for
> > Ethernet is not inline with the existing stacks what is the value of
> > GMPLS re-use ? what's the value to borrow the term GMPLS without its
> > substance ? and in practice, the issue is, if it is not GMPLS per RFC
> > 3945, what's the value compared to any other native control stack that
> > would be developed at IEEE for inst. for these techno's.
> >
> > you quote:
> >
> > > L2SC was always underspecified (e.g., covers both ATM and Ether),
> >
> > additional specification does not result in departing from the initial
> > definition but refinement of the initial definition (definition of a
> > sub-set not a side definition).
> >
> > probably the document is not mature enough to respond to the
> > tie-breaker: what about the FIT of GMPLS for Ethernet but not
> > within the
> > L2SC space (as defined today) ? but in the meantime preclude
> > any allowed
> > use of GMPLS per IETF RFCs to Ethernet if they do not comply
> > with a new
> > WG i-d would create a precedent in the history of this WG with really
> > disastrous impact (including on other application of GMPLS)
> >
> > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
> > assess consequences before going one way or another and under which
> > conditions.
> >
> > -d.
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > Sent: Wednesday, January 23, 2008 1:09 AM
> > > To: PAPADIMITRIOU Dimitri
> > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > > We've always had different switching type/capability in
> > > GMPLS.  Nothing new here.
> > >
> > > L2SC was always underspecified (e.g., covers both ATM and
> > Ether), is
> > > currently used by some for different purposes, and doesn't allow
> > > unique identification of switching capabilities of an interface.  I
> > > *really* don't see the unique identification of an interface's
> > > Ethernet switching function as any different from what is done for
> > > today for the other types or as any big deal or change in GMPLS
> > > direction or architecture.
> > >
> > > but, that's just my perspective.
> > >
> > > Lou
> > >
> > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > >thus the question is whether or not to ask for a change
> > CCAMP "common
> > > >control" in DCAMP "differentiated control" per technology ?
> > > >
> > > >we never have had a techno inducing a base building block
> > > change (GMPLS
> > > >being a generalisation of MPLS-TE). i'm afraid that
> > generalized LSP,
> > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC
> > > 3945) would
> > > >simply be unapplicable as known today and thus the corr.
> > > base protocol
> > > >specs unapplicable. at the end the term "GMPLS" would be
> > > emptied of any
> > > >real substance.
> > > >
> > > >it's a choice but let's ask the questions from the right
> > perspective.
> > > >
> > > >-d.
> > > >
> > > > > -----Original Message-----
> > > > > From: Lou Berger [mailto:[email-masked]]
> > > > > Sent: Tuesday, January 22, 2008 11:28 PM
> > > > > To: PAPADIMITRIOU Dimitri
> > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > [email-masked]
> > > > > Subject: RE: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > I have no objection to adding "Updates: 3945" to the
> > > document header
> > > > > and matching 3945's category.
> > > > >
> > > > > Lou
> > > > >
> > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > > > >Lou
> > > > > >
> > > > > >what i am concerned with: is that the doc extends
> > > > > applicability of GMPLS
> > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945
> > > ? does that
> > > > > >make sense ?
> > > > > >
> > > > > >what's needed instead of hiding behind terms is to state
> > > GMPLS for Y,
> > > > > >where Y includes the set of Ethernet-based techno's under
> > > > > development at
> > > > > >places as indicated in the doc itself. instead of
> > > inducing by a title
> > > > > >such as "GMPLS for Ethernet" that this doc supersedes any
> > > > > previous work
> > > > > >in that
> > > > > >space.
> > > > > >
> > > > > >-d.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > > > > To: Don Fedyk
> > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > > > [email-masked]
> > > > > > > Subject: RE: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > > >
> > > > > > > Don,
> > > > > > >          I agree 100%.  Furthermore there is no
> > > statement in the
> > > > > > > draft that 3945 doesn't apply, in fact it explicitly
> > > says just the
> > > > > > > opposite.  The reason for the statement in question is
> > > > > simply as you
> > > > > > > say, and to ensure full ETH-LSP definition and interoperable
> > > > > > > operation a new switching type/capability is required.
> > > > > > >
> > > > > > > It's really not such a bid deal or major change.
> > > > > > >
> > > > > > > Lou
> > > > > > >
> > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > > > > >Hi Dimitri
> > > > > > > >
> > > > > > > >The text you quote was put in the architecture/
> > > framework, not to
> > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > > > > > L2SC, which
> > > > > > > >has been there for many years and may be in use.
> > > > > > > >
> > > > > > > >Perhaps the working needs to be adjusted but I don't think
> > > > > > > it is a major
> > > > > > > >issue.
> > > > > > > >
> > > > > > > >Regards,
> > > > > > > >Don
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [email-masked]
> > > > > > > > > [mailto:[email-masked]] On Behalf Of
> > > > > > > PAPADIMITRIOU Dimitri
> > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > > > > Subject: RE: Proposed WG Draft -
> > > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > All,
> > > > > > > > >
> > > > > > > > > > We received a couple of comments in the
> > > meeting, we would
> > > > > > > > > > appreciate additional feedback on the list.
> > > > > > > > >
> > > > > > > > > The document states:
> > > > > > > > >
> > > > > > > > > "The L2SC Interface Switching Capabilities MUST
> > > NOT be used
> > > > > > > > > to represent
> > > > > > > > > interfaces capable of supporting Eth-LSPs.
> > > Interface Switching
> > > > > > > > > Capability specific TE information may be defined as
> > > > > > > needed to support
> > > > > > > > > the requirements of a specific Ethernet Switching
> > > > > Service Type."
> > > > > > > > >
> > > > > > > > > [...]
> > > > > > > > >
> > > > > > > > > "It is expected that there will be no case where an
> > > > > > > Eth-LSP will be
> > > > > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > > > > represented, using
> > > > > > > > > the L2SC switching type/capability. A new switching
> > > > > > > type/capability is
> > > > > > > > > required to avoid any potential current usage
> > of the L2SC
> > > > > > > switching
> > > > > > > > > type/capability in support of Ethernet."
> > > > > > > > >
> > > > > > > > > This is explicit statement that GMPLS per RFC
> > 3945 is not
> > > > > > > applicable.
> > > > > > > > > So, it is much more than just an additional
> > codepoint, as
> > > > > > > the control
> > > > > > > > > plane behaviour is to be defined for this
> > > codepoint. So, it
> > > > > > > > > is the open
> > > > > > > > > door for a new control plane behaviour.
> > > > > > > > >
> > > > > > > > > so, let's have a more basic questioning before jumping
> > > > > > > into the single
> > > > > > > > > alternative resulting from this doc.:
> > > > > > > > >
> > > > > > > > > - either it is GMPLS for Ethernet architecture and then
> > > > > > > what exist in
> > > > > > > > > current RFCs should be applicable (because i do not see
> > > > > > > any rationale
> > > > > > > > > for L2SC def. departure for Ethernet frame processing);
> > > > > > > > >
> > > > > > > > > - or not it is X for Y architecture, where X is an IP
> > > > > > > control protocol
> > > > > > > > > based some potentially on some existing GMPLS blocks
> > > > > and Y is not
> > > > > > > > > compatible with the existing definition of Eth frame
> > > > > processing.
> > > > > > > > >
> > > > > > > > > In the latter case, i do not know how this WG can deal
> > > > > > > with such case
> > > > > > > > > (from the control plane perspective).
> > > > > > > > >
> > > > > > > > > -d.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: [email-masked]
> > > > > > > > > > [mailto:[email-masked]] On Behalf
> > Of BRUNGARD,
> > > > > > > > > > DEBORAH A, ATTLABS
> > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > > > > To: [email-masked]
> > > > > > > > > > Subject: Proposed WG Draft -
> > > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > > >
> > > > > > > > > > CCAMP,
> > > > > > > > > >
> > > > > > > > > > The DT proposed in their meeting presentation
> > for their
> > > > > > > > > > architecture and framework document to be
> > accepted as a
> > > > > > > WG draft:
> > > > > > > > > >
> > > > > > >
> > > > >
> > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > > > > >
> > > > > > > > > > We received a couple of comments in the
> > > meeting, we would
> > > > > > > > > > appreciate additional feedback on the list.
> > > Please express
> > > > > > > > > > your support (or otherwise) for this I-D to become
> > > > > a WG draft.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Deborah
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> >

Delivery-date: Thu, 24 Jan 2008 08:25:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Thu, 24 Jan 2008 09:23:21 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Hi Don

so, what's wrong with the definition of L2SC then ? from 3945:

   2. Layer-2 Switch Capable (L2SC) interfaces:

      Interfaces that recognize frame/cell boundaries and can switch
      data based on the content of the frame/cell header.  Examples
      include interfaces on Ethernet bridges that switch data based on
      the content of the MAC header and interfaces on ATM-LSRs that
      forward data based on the ATM VPI/VCI.=20

as such the statement "A new switching type/capability is required to
avoid any potential current usage of the L2SC switching type/capability=20
in support of Ethernet." is made but never explained why in the doc -

now coming down to the first sentence you indicated from your doc.

"The intent of this document is to reuse and align with as much of the
GMPLS protocols as possible.... Additions are made only to accommodate=20
features of Ethernet that are not already supported by GMPLS."

It should have been something like: "This doc. details the GMPLS
protocol suite architecture for Ethernet. Extensions are made only=20
to accommodate features of Ethernet that are not already supported=20
by GMPLS RFCs and inline with its architecture defined in RFC 3945."

otherwise the result would be progressively that all GMPLS RFCs are
cracked down to accommodate Ethernet.

thanks,
-d.

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]=20
> Sent: Thursday, January 24, 2008 3:51 AM
> To: PAPADIMITRIOU Dimitri; Lou Berger
> Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Hi Dimitri
>=20
> The document clearly states:
>=20
> "The intent of this document is to reuse and align with as much of the
>    GMPLS protocols as possible.  For example reusing the IP control
>    plane addressing allows the existing signaling, routing,=20
> LMP and path
>    computation to be used as specified. Additions are made only to
>    accommodate features of Ethernet that are not already supported by
>    GMPLS.  The GMPLS protocols support a set of tools for hierarchical
>    LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms
>    support a variety of networks from peer to peer to UNIs and NNIs."
>=20
> So your question comes down to why we make the statement on=20
> L2SC?  Like
> Lou said when we discussed this we thought that L2SC came with baggage
> and was not precise. The switching capabilities would be specified in
> documents that address the particular Ethernet data plane.  It is true
> that if there was a valid Ethernet data plane that could use L2SC
> unambiguously it should fit under the architecture.  At any=20
> rate getting
> this right is something that can be accomplished when this is a WG
> draft.=20
>=20
> Regards,
> Don=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri=20
> > [mailto:[email-masked]]=20
> > Sent: Wednesday, January 23, 2008 7:05 PM
> > To: Lou Berger
> > Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > the question triggered by this poll is the following: if GMPLS for
> > Ethernet is not inline with the existing stacks what is the value of
> > GMPLS re-use ? what's the value to borrow the term GMPLS without its
> > substance ? and in practice, the issue is, if it is not=20
> GMPLS per RFC
> > 3945, what's the value compared to any other native control=20
> stack that
> > would be developed at IEEE for inst. for these techno's.
> >=20
> > you quote:
> >=20
> > > L2SC was always underspecified (e.g., covers both ATM and Ether),
> >=20
> > additional specification does not result in departing from=20
> the initial
> > definition but refinement of the initial definition (definition of a
> > sub-set not a side definition).
> >=20
> > probably the document is not mature enough to respond to the
> > tie-breaker: what about the FIT of GMPLS for Ethernet but not=20
> > within the
> > L2SC space (as defined today) ? but in the meantime preclude=20
> > any allowed
> > use of GMPLS per IETF RFCs to Ethernet if they do not comply=20
> > with a new
> > WG i-d would create a precedent in the history of this WG=20
> with really
> > disastrous impact (including on other application of GMPLS)
> >=20
> > we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
> > assess consequences before going one way or another and under which
> > conditions.
> >=20
> > -d.
> >=20
> > > -----Original Message-----
> > > From: [email-masked]=20
> > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > Sent: Wednesday, January 23, 2008 1:09 AM
> > > To: PAPADIMITRIOU Dimitri
> > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > We've always had different switching type/capability in=20
> > > GMPLS.  Nothing new here.
> > >=20
> > > L2SC was always underspecified (e.g., covers both ATM and=20
> > Ether), is=20
> > > currently used by some for different purposes, and doesn't allow=20
> > > unique identification of switching capabilities of an=20
> interface.  I=20
> > > *really* don't see the unique identification of an interface's=20
> > > Ethernet switching function as any different from what is=20
> done for=20
> > > today for the other types or as any big deal or change in GMPLS=20
> > > direction or architecture.
> > >=20
> > > but, that's just my perspective.
> > >=20
> > > Lou
> > >=20
> > > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > >thus the question is whether or not to ask for a change=20
> > CCAMP "common
> > > >control" in DCAMP "differentiated control" per technology ?
> > > >
> > > >we never have had a techno inducing a base building block=20
> > > change (GMPLS
> > > >being a generalisation of MPLS-TE). i'm afraid that=20
> > generalized LSP,
> > > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20
> > > 3945) would
> > > >simply be unapplicable as known today and thus the corr.=20
> > > base protocol
> > > >specs unapplicable. at the end the term "GMPLS" would be=20
> > > emptied of any
> > > >real substance.
> > > >
> > > >it's a choice but let's ask the questions from the right=20
> > perspective.
> > > >
> > > >-d.
> > > >
> > > > > -----Original Message-----
> > > > > From: Lou Berger [mailto:[email-masked]]
> > > > > Sent: Tuesday, January 22, 2008 11:28 PM
> > > > > To: PAPADIMITRIOU Dimitri
> > > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > [email-masked]
> > > > > Subject: RE: Proposed WG Draft -=20
> > draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > I have no objection to adding "Updates: 3945" to the=20
> > > document header
> > > > > and matching 3945's category.
> > > > >
> > > > > Lou
> > > > >
> > > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > > > >Lou
> > > > > >
> > > > > >what i am concerned with: is that the doc extends
> > > > > applicability of GMPLS
> > > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20
> > > ? does that
> > > > > >make sense ?
> > > > > >
> > > > > >what's needed instead of hiding behind terms is to state=20
> > > GMPLS for Y,
> > > > > >where Y includes the set of Ethernet-based techno's under
> > > > > development at
> > > > > >places as indicated in the doc itself. instead of=20
> > > inducing by a title
> > > > > >such as "GMPLS for Ethernet" that this doc supersedes any
> > > > > previous work
> > > > > >in that
> > > > > >space.
> > > > > >
> > > > > >-d.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > > > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > > > > To: Don Fedyk
> > > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > > > [email-masked]
> > > > > > > Subject: RE: Proposed WG Draft -=20
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > > >
> > > > > > > Don,
> > > > > > >          I agree 100%.  Furthermore there is no=20
> > > statement in the
> > > > > > > draft that 3945 doesn't apply, in fact it explicitly=20
> > > says just the
> > > > > > > opposite.  The reason for the statement in question is
> > > > > simply as you
> > > > > > > say, and to ensure full ETH-LSP definition and=20
> interoperable
> > > > > > > operation a new switching type/capability is required.
> > > > > > >
> > > > > > > It's really not such a bid deal or major change.
> > > > > > >
> > > > > > > Lou
> > > > > > >
> > > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > > > > >Hi Dimitri
> > > > > > > >
> > > > > > > >The text you quote was put in the architecture/=20
> > > framework, not to
> > > > > > > >exclude L2 Switch Capable (L2SC) but to prevent=20
> redefining
> > > > > > > L2SC, which
> > > > > > > >has been there for many years and may be in use.
> > > > > > > >
> > > > > > > >Perhaps the working needs to be adjusted but I=20
> don't think
> > > > > > > it is a major
> > > > > > > >issue.
> > > > > > > >
> > > > > > > >Regards,
> > > > > > > >Don
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [email-masked]
> > > > > > > > > [mailto:[email-masked]] On Behalf Of
> > > > > > > PAPADIMITRIOU Dimitri
> > > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > > > > Subject: RE: Proposed WG Draft -
> > > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > All,
> > > > > > > > >
> > > > > > > > > > We received a couple of comments in the=20
> > > meeting, we would
> > > > > > > > > > appreciate additional feedback on the list.
> > > > > > > > >
> > > > > > > > > The document states:
> > > > > > > > >
> > > > > > > > > "The L2SC Interface Switching Capabilities MUST=20
> > > NOT be used
> > > > > > > > > to represent
> > > > > > > > > interfaces capable of supporting Eth-LSPs.=20
> > > Interface Switching
> > > > > > > > > Capability specific TE information may be defined as
> > > > > > > needed to support
> > > > > > > > > the requirements of a specific Ethernet Switching
> > > > > Service Type."
> > > > > > > > >
> > > > > > > > > [...]
> > > > > > > > >
> > > > > > > > > "It is expected that there will be no case where an
> > > > > > > Eth-LSP will be
> > > > > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > > > > represented, using
> > > > > > > > > the L2SC switching type/capability. A new switching
> > > > > > > type/capability is
> > > > > > > > > required to avoid any potential current usage=20
> > of the L2SC
> > > > > > > switching
> > > > > > > > > type/capability in support of Ethernet."
> > > > > > > > >
> > > > > > > > > This is explicit statement that GMPLS per RFC=20
> > 3945 is not
> > > > > > > applicable.
> > > > > > > > > So, it is much more than just an additional=20
> > codepoint, as
> > > > > > > the control
> > > > > > > > > plane behaviour is to be defined for this=20
> > > codepoint. So, it
> > > > > > > > > is the open
> > > > > > > > > door for a new control plane behaviour.
> > > > > > > > >
> > > > > > > > > so, let's have a more basic questioning before jumping
> > > > > > > into the single
> > > > > > > > > alternative resulting from this doc.:
> > > > > > > > >
> > > > > > > > > - either it is GMPLS for Ethernet=20
> architecture and then
> > > > > > > what exist in
> > > > > > > > > current RFCs should be applicable (because i=20
> do not see
> > > > > > > any rationale
> > > > > > > > > for L2SC def. departure for Ethernet frame=20
> processing);
> > > > > > > > >
> > > > > > > > > - or not it is X for Y architecture, where X is an IP
> > > > > > > control protocol
> > > > > > > > > based some potentially on some existing GMPLS blocks
> > > > > and Y is not
> > > > > > > > > compatible with the existing definition of Eth frame
> > > > > processing.
> > > > > > > > >
> > > > > > > > > In the latter case, i do not know how this WG can deal
> > > > > > > with such case
> > > > > > > > > (from the control plane perspective).
> > > > > > > > >
> > > > > > > > > -d.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: [email-masked]
> > > > > > > > > > [mailto:[email-masked]] On Behalf=20
> > Of BRUNGARD,
> > > > > > > > > > DEBORAH A, ATTLABS
> > > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > > > > To: [email-masked]
> > > > > > > > > > Subject: Proposed WG Draft -
> > > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > > >
> > > > > > > > > > CCAMP,
> > > > > > > > > >
> > > > > > > > > > The DT proposed in their meeting presentation=20
> > for their
> > > > > > > > > > architecture and framework document to be=20
> > accepted as a
> > > > > > > WG draft:
> > > > > > > > > >
> > > > > > >
> > > > >=20
> > >=20
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > > > > >
> > > > > > > > > > We received a couple of comments in the=20
> > > meeting, we would
> > > > > > > > > > appreciate additional feedback on the list.=20
> > > Please express
> > > > > > > > > > your support (or otherwise) for this I-D to become
> > > > > a WG draft.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Deborah
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >=20
> > >=20
> > >=20
> >=20
>=20

Delivery-date: Thu, 24 Jan 2008 02:53:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 23 Jan 2008 21:51:11 -0500
From: "Don Fedyk" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, "Lou Berger" <[email-masked]>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Hi Dimitri

The document clearly states:

"The intent of this document is to reuse and align with as much of the
   GMPLS protocols as possible.  For example reusing the IP control
   plane addressing allows the existing signaling, routing, LMP and path
   computation to be used as specified. Additions are made only to
   accommodate features of Ethernet that are not already supported by
   GMPLS.  The GMPLS protocols support a set of tools for hierarchical
   LSPs as well as contiguous LSPs. GMPLS specific protocol mechanisms
   support a variety of networks from peer to peer to UNIs and NNIs."

So your question comes down to why we make the statement on L2SC?  Like
Lou said when we discussed this we thought that L2SC came with baggage
and was not precise. The switching capabilities would be specified in
documents that address the particular Ethernet data plane.  It is true
that if there was a valid Ethernet data plane that could use L2SC
unambiguously it should fit under the architecture.  At any rate getting
this right is something that can be accomplished when this is a WG
draft.=20

Regards,
Don=20

> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:[email-masked]]=20
> Sent: Wednesday, January 23, 2008 7:05 PM
> To: Lou Berger
> Cc: Fedyk, Don (BL60:1A00); BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> the question triggered by this poll is the following: if GMPLS for
> Ethernet is not inline with the existing stacks what is the value of
> GMPLS re-use ? what's the value to borrow the term GMPLS without its
> substance ? and in practice, the issue is, if it is not GMPLS per RFC
> 3945, what's the value compared to any other native control stack that
> would be developed at IEEE for inst. for these techno's.
>=20
> you quote:
>=20
> > L2SC was always underspecified (e.g., covers both ATM and Ether),
>=20
> additional specification does not result in departing from the initial
> definition but refinement of the initial definition (definition of a
> sub-set not a side definition).
>=20
> probably the document is not mature enough to respond to the
> tie-breaker: what about the FIT of GMPLS for Ethernet but not=20
> within the
> L2SC space (as defined today) ? but in the meantime preclude=20
> any allowed
> use of GMPLS per IETF RFCs to Ethernet if they do not comply=20
> with a new
> WG i-d would create a precedent in the history of this WG with really
> disastrous impact (including on other application of GMPLS)
>=20
> we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
> assess consequences before going one way or another and under which
> conditions.
>=20
> -d.
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of Lou Berger
> > Sent: Wednesday, January 23, 2008 1:09 AM
> > To: PAPADIMITRIOU Dimitri
> > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > We've always had different switching type/capability in=20
> > GMPLS.  Nothing new here.
> >=20
> > L2SC was always underspecified (e.g., covers both ATM and=20
> Ether), is=20
> > currently used by some for different purposes, and doesn't allow=20
> > unique identification of switching capabilities of an interface.  I=20
> > *really* don't see the unique identification of an interface's=20
> > Ethernet switching function as any different from what is done for=20
> > today for the other types or as any big deal or change in GMPLS=20
> > direction or architecture.
> >=20
> > but, that's just my perspective.
> >=20
> > Lou
> >=20
> > At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > >thus the question is whether or not to ask for a change=20
> CCAMP "common
> > >control" in DCAMP "differentiated control" per technology ?
> > >
> > >we never have had a techno inducing a base building block=20
> > change (GMPLS
> > >being a generalisation of MPLS-TE). i'm afraid that=20
> generalized LSP,
> > >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20
> > 3945) would
> > >simply be unapplicable as known today and thus the corr.=20
> > base protocol
> > >specs unapplicable. at the end the term "GMPLS" would be=20
> > emptied of any
> > >real substance.
> > >
> > >it's a choice but let's ask the questions from the right=20
> perspective.
> > >
> > >-d.
> > >
> > > > -----Original Message-----
> > > > From: Lou Berger [mailto:[email-masked]]
> > > > Sent: Tuesday, January 22, 2008 11:28 PM
> > > > To: PAPADIMITRIOU Dimitri
> > > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > > [email-masked]
> > > > Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > I have no objection to adding "Updates: 3945" to the=20
> > document header
> > > > and matching 3945's category.
> > > >
> > > > Lou
> > > >
> > > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > > >Lou
> > > > >
> > > > >what i am concerned with: is that the doc extends
> > > > applicability of GMPLS
> > > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20
> > ? does that
> > > > >make sense ?
> > > > >
> > > > >what's needed instead of hiding behind terms is to state=20
> > GMPLS for Y,
> > > > >where Y includes the set of Ethernet-based techno's under
> > > > development at
> > > > >places as indicated in the doc itself. instead of=20
> > inducing by a title
> > > > >such as "GMPLS for Ethernet" that this doc supersedes any
> > > > previous work
> > > > >in that
> > > > >space.
> > > > >
> > > > >-d.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > > > To: Don Fedyk
> > > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > > [email-masked]
> > > > > > Subject: RE: Proposed WG Draft -=20
> > draft-gmpls-ethernet-arch-00.txt
> > > > > >
> > > > > > Don,
> > > > > >          I agree 100%.  Furthermore there is no=20
> > statement in the
> > > > > > draft that 3945 doesn't apply, in fact it explicitly=20
> > says just the
> > > > > > opposite.  The reason for the statement in question is
> > > > simply as you
> > > > > > say, and to ensure full ETH-LSP definition and interoperable
> > > > > > operation a new switching type/capability is required.
> > > > > >
> > > > > > It's really not such a bid deal or major change.
> > > > > >
> > > > > > Lou
> > > > > >
> > > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > > > >Hi Dimitri
> > > > > > >
> > > > > > >The text you quote was put in the architecture/=20
> > framework, not to
> > > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > > > > L2SC, which
> > > > > > >has been there for many years and may be in use.
> > > > > > >
> > > > > > >Perhaps the working needs to be adjusted but I don't think
> > > > > > it is a major
> > > > > > >issue.
> > > > > > >
> > > > > > >Regards,
> > > > > > >Don
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf Of
> > > > > > PAPADIMITRIOU Dimitri
> > > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > > > Subject: RE: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > >
> > > > > > > > All,
> > > > > > > >
> > > > > > > > > We received a couple of comments in the=20
> > meeting, we would
> > > > > > > > > appreciate additional feedback on the list.
> > > > > > > >
> > > > > > > > The document states:
> > > > > > > >
> > > > > > > > "The L2SC Interface Switching Capabilities MUST=20
> > NOT be used
> > > > > > > > to represent
> > > > > > > > interfaces capable of supporting Eth-LSPs.=20
> > Interface Switching
> > > > > > > > Capability specific TE information may be defined as
> > > > > > needed to support
> > > > > > > > the requirements of a specific Ethernet Switching
> > > > Service Type."
> > > > > > > >
> > > > > > > > [...]
> > > > > > > >
> > > > > > > > "It is expected that there will be no case where an
> > > > > > Eth-LSP will be
> > > > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > > > represented, using
> > > > > > > > the L2SC switching type/capability. A new switching
> > > > > > type/capability is
> > > > > > > > required to avoid any potential current usage=20
> of the L2SC
> > > > > > switching
> > > > > > > > type/capability in support of Ethernet."
> > > > > > > >
> > > > > > > > This is explicit statement that GMPLS per RFC=20
> 3945 is not
> > > > > > applicable.
> > > > > > > > So, it is much more than just an additional=20
> codepoint, as
> > > > > > the control
> > > > > > > > plane behaviour is to be defined for this=20
> > codepoint. So, it
> > > > > > > > is the open
> > > > > > > > door for a new control plane behaviour.
> > > > > > > >
> > > > > > > > so, let's have a more basic questioning before jumping
> > > > > > into the single
> > > > > > > > alternative resulting from this doc.:
> > > > > > > >
> > > > > > > > - either it is GMPLS for Ethernet architecture and then
> > > > > > what exist in
> > > > > > > > current RFCs should be applicable (because i do not see
> > > > > > any rationale
> > > > > > > > for L2SC def. departure for Ethernet frame processing);
> > > > > > > >
> > > > > > > > - or not it is X for Y architecture, where X is an IP
> > > > > > control protocol
> > > > > > > > based some potentially on some existing GMPLS blocks
> > > > and Y is not
> > > > > > > > compatible with the existing definition of Eth frame
> > > > processing.
> > > > > > > >
> > > > > > > > In the latter case, i do not know how this WG can deal
> > > > > > with such case
> > > > > > > > (from the control plane perspective).
> > > > > > > >
> > > > > > > > -d.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [email-masked]
> > > > > > > > > [mailto:[email-masked]] On Behalf=20
> Of BRUNGARD,
> > > > > > > > > DEBORAH A, ATTLABS
> > > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Subject: Proposed WG Draft -
> > > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > CCAMP,
> > > > > > > > >
> > > > > > > > > The DT proposed in their meeting presentation=20
> for their
> > > > > > > > > architecture and framework document to be=20
> accepted as a
> > > > > > WG draft:
> > > > > > > > >
> > > > > >
> > > >=20
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > > > >
> > > > > > > > > We received a couple of comments in the=20
> > meeting, we would
> > > > > > > > > appreciate additional feedback on the list.=20
> > Please express
> > > > > > > > > your support (or otherwise) for this I-D to become
> > > > a WG draft.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Deborah
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >=20
> >=20
> >=20
>=20

Delivery-date: Thu, 24 Jan 2008 00:06:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Thu, 24 Jan 2008 01:04:33 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

the question triggered by this poll is the following: if GMPLS for
Ethernet is not inline with the existing stacks what is the value of
GMPLS re-use ? what's the value to borrow the term GMPLS without its
substance ? and in practice, the issue is, if it is not GMPLS per RFC
3945, what's the value compared to any other native control stack that
would be developed at IEEE for inst. for these techno's.

you quote:

> L2SC was always underspecified (e.g., covers both ATM and Ether),

additional specification does not result in departing from the initial
definition but refinement of the initial definition (definition of a
sub-set not a side definition).

probably the document is not mature enough to respond to the
tie-breaker: what about the FIT of GMPLS for Ethernet but not within the
L2SC space (as defined today) ? but in the meantime preclude any allowed
use of GMPLS per IETF RFCs to Ethernet if they do not comply with a new
WG i-d would create a precedent in the history of this WG with really
disastrous impact (including on other application of GMPLS)

we're at a turning point (equivalent to RSVP vs RSVP-TE). we need to
assess consequences before going one way or another and under which
conditions.

-d.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Wednesday, January 23, 2008 1:09 AM
> To: PAPADIMITRIOU Dimitri
> Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> We've always had different switching type/capability in=20
> GMPLS.  Nothing new here.
>=20
> L2SC was always underspecified (e.g., covers both ATM and Ether), is=20
> currently used by some for different purposes, and doesn't allow=20
> unique identification of switching capabilities of an interface.  I=20
> *really* don't see the unique identification of an interface's=20
> Ethernet switching function as any different from what is done for=20
> today for the other types or as any big deal or change in GMPLS=20
> direction or architecture.
>=20
> but, that's just my perspective.
>=20
> Lou
>=20
> At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> >thus the question is whether or not to ask for a change CCAMP "common
> >control" in DCAMP "differentiated control" per technology ?
> >
> >we never have had a techno inducing a base building block=20
> change (GMPLS
> >being a generalisation of MPLS-TE). i'm afraid that generalized LSP,
> >generalized LSR, generalized label, etc. per GMPLS arch (RFC=20
> 3945) would
> >simply be unapplicable as known today and thus the corr.=20
> base protocol
> >specs unapplicable. at the end the term "GMPLS" would be=20
> emptied of any
> >real substance.
> >
> >it's a choice but let's ask the questions from the right perspective.
> >
> >-d.
> >
> > > -----Original Message-----
> > > From: Lou Berger [mailto:[email-masked]]
> > > Sent: Tuesday, January 22, 2008 11:28 PM
> > > To: PAPADIMITRIOU Dimitri
> > > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > > I have no objection to adding "Updates: 3945" to the=20
> document header
> > > and matching 3945's category.
> > >
> > > Lou
> > >
> > > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > > >Lou
> > > >
> > > >what i am concerned with: is that the doc extends
> > > applicability of GMPLS
> > > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945=20
> ? does that
> > > >make sense ?
> > > >
> > > >what's needed instead of hiding behind terms is to state=20
> GMPLS for Y,
> > > >where Y includes the set of Ethernet-based techno's under
> > > development at
> > > >places as indicated in the doc itself. instead of=20
> inducing by a title
> > > >such as "GMPLS for Ethernet" that this doc supersedes any
> > > previous work
> > > >in that
> > > >space.
> > > >
> > > >-d.
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > > To: Don Fedyk
> > > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > > [email-masked]
> > > > > Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > Don,
> > > > >          I agree 100%.  Furthermore there is no=20
> statement in the
> > > > > draft that 3945 doesn't apply, in fact it explicitly=20
> says just the
> > > > > opposite.  The reason for the statement in question is
> > > simply as you
> > > > > say, and to ensure full ETH-LSP definition and interoperable
> > > > > operation a new switching type/capability is required.
> > > > >
> > > > > It's really not such a bid deal or major change.
> > > > >
> > > > > Lou
> > > > >
> > > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > > >Hi Dimitri
> > > > > >
> > > > > >The text you quote was put in the architecture/=20
> framework, not to
> > > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > > > L2SC, which
> > > > > >has been there for many years and may be in use.
> > > > > >
> > > > > >Perhaps the working needs to be adjusted but I don't think
> > > > > it is a major
> > > > > >issue.
> > > > > >
> > > > > >Regards,
> > > > > >Don
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]] On Behalf Of
> > > > > PAPADIMITRIOU Dimitri
> > > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > > Subject: RE: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > > >
> > > > > > > All,
> > > > > > >
> > > > > > > > We received a couple of comments in the=20
> meeting, we would
> > > > > > > > appreciate additional feedback on the list.
> > > > > > >
> > > > > > > The document states:
> > > > > > >
> > > > > > > "The L2SC Interface Switching Capabilities MUST=20
> NOT be used
> > > > > > > to represent
> > > > > > > interfaces capable of supporting Eth-LSPs.=20
> Interface Switching
> > > > > > > Capability specific TE information may be defined as
> > > > > needed to support
> > > > > > > the requirements of a specific Ethernet Switching
> > > Service Type."
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > "It is expected that there will be no case where an
> > > > > Eth-LSP will be
> > > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > > represented, using
> > > > > > > the L2SC switching type/capability. A new switching
> > > > > type/capability is
> > > > > > > required to avoid any potential current usage of the L2SC
> > > > > switching
> > > > > > > type/capability in support of Ethernet."
> > > > > > >
> > > > > > > This is explicit statement that GMPLS per RFC 3945 is not
> > > > > applicable.
> > > > > > > So, it is much more than just an additional codepoint, as
> > > > > the control
> > > > > > > plane behaviour is to be defined for this=20
> codepoint. So, it
> > > > > > > is the open
> > > > > > > door for a new control plane behaviour.
> > > > > > >
> > > > > > > so, let's have a more basic questioning before jumping
> > > > > into the single
> > > > > > > alternative resulting from this doc.:
> > > > > > >
> > > > > > > - either it is GMPLS for Ethernet architecture and then
> > > > > what exist in
> > > > > > > current RFCs should be applicable (because i do not see
> > > > > any rationale
> > > > > > > for L2SC def. departure for Ethernet frame processing);
> > > > > > >
> > > > > > > - or not it is X for Y architecture, where X is an IP
> > > > > control protocol
> > > > > > > based some potentially on some existing GMPLS blocks
> > > and Y is not
> > > > > > > compatible with the existing definition of Eth frame
> > > processing.
> > > > > > >
> > > > > > > In the latter case, i do not know how this WG can deal
> > > > > with such case
> > > > > > > (from the control plane perspective).
> > > > > > >
> > > > > > > -d.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > > > > > > DEBORAH A, ATTLABS
> > > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > > To: [email-masked]
> > > > > > > > Subject: Proposed WG Draft -
> > > draft-gmpls-ethernet-arch-00.txt
> > > > > > > >
> > > > > > > > CCAMP,
> > > > > > > >
> > > > > > > > The DT proposed in their meeting presentation for their
> > > > > > > > architecture and framework document to be accepted as a
> > > > > WG draft:
> > > > > > > >
> > > > >
> > >=20
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > > >
> > > > > > > > We received a couple of comments in the=20
> meeting, we would
> > > > > > > > appreciate additional feedback on the list.=20
> Please express
> > > > > > > > your support (or otherwise) for this I-D to become
> > > a WG draft.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Deborah
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
>=20
>=20
>=20

Delivery-date: Wed, 23 Jan 2008 22:34:04 +0000
Date: Wed, 23 Jan 2008 17:31:10 -0500
From: "Andrew G. Malis" <[email-masked]>
To: [email-masked]
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>

Also in favor.

Cheers,
Andy

> BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>
> The DT proposed in their meeting presentation for their architecture and
> framework document to be accepted as a WG draft:
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
>
> We received a couple of comments in the meeting, we would appreciate
> additional feedback on the list. Please express your support (or otherwise)
> for this I-D to become a WG draft.
>
> Thanks,
> Deborah

Delivery-date: Wed, 23 Jan 2008 15:13:50 +0000
Date: Wed, 23 Jan 2008 07:12:56 -0800
From: Greg Bernstein <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
CC: [email-masked]
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

This is a multi-part message in MIME format.
--------------020605090909000502090101
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In favor.
Regards

Greg B.

BRUNGARD, DEBORAH A, ATTLABS wrote:
> CCAMP,
>  
> The DT proposed in their meeting presentation for their architecture 
> and framework document to be accepted as a WG draft:
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
>  
> We received a couple of comments in the meeting, we would appreciate 
> additional feedback on the list. Please express your support (or 
> otherwise) for this I-D to become a WG draft.
>  
> Thanks,
> Deborah

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------020605090909000502090101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
In favor.<br>
Regards<br>
<br>
Greg B.<br>
<br>
BRUNGARD, DEBORAH A, ATTLABS wrote:
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3243" name="GENERATOR">
  <div><font face="Arial" size="2"><span class="783210619-22012008">CCAMP,</span></font></div>
  <div><font face="Arial" size="2"><span class="783210619-22012008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="783210619-22012008">The
DT proposed in their meeting presentation&nbsp;for their architecture and
framework document&nbsp;to be&nbsp;accepted as a&nbsp;WG draft:</span></font></div>
  <div><font face="Arial" size="2"><span class="783210619-22012008"><a
 moz-do-not-send="true"
 href="http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt</a></span></font></div>
  <div><font face="Arial" size="2"><span class="783210619-22012008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="783210619-22012008">We
received a couple of comments&nbsp;in the meeting, we would appreciate
additional feedback&nbsp;on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.</span></font></div>
  <div><font face="Arial" size="2"><span class="783210619-22012008"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="783210619-22012008">Thanks,</span></font></div>
  <div><font face="Arial" size="2"><span class="783210619-22012008">Deborah</span></font></div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------020605090909000502090101--

Delivery-date: Wed, 23 Jan 2008 14:49:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 23 Jan 2008 09:47:48 -0500
From: "Hamid Ould-Brahim" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85DCE.E3F56E52
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In favor.
=20
Hamid.

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: Tuesday, January 22, 2008 2:28 PM
	To: [email-masked]
	Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
=09
=09
	CCAMP,
	=20
	The DT proposed in their meeting presentation for their
architecture and framework document to be accepted as a WG draft:
=09
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
	=20
	We received a couple of comments in the meeting, we would
appreciate additional feedback on the list. Please express your support
(or otherwise) for this I-D to become a WG draft.
	=20
	Thanks,
	Deborah

------_=_NextPart_001_01C85DCE.E3F56E52
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D031414714-23012008><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2>In favor.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D031414714-23012008><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D031414714-23012008><FONT =
face=3D"Courier New"=20
color=3D#0000ff size=3D2>Hamid.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, =
DEBORAH A,=20
  ATTLABS<BR><B>Sent:</B> Tuesday, January 22, 2008 2:28 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Proposed WG Draft -=20
  draft-gmpls-ethernet-arch-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The =
DT proposed in=20
  their meeting presentation&nbsp;for their architecture and framework=20
  document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a=20
  couple of comments&nbsp;in the meeting, we would appreciate additional =

  feedback&nbsp;on the list. Please express your support (or otherwise) =
for this=20
  I-D to become a WG draft.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY=
></HTML>

------_=_NextPart_001_01C85DCE.E3F56E52--

Delivery-date: Wed, 23 Jan 2008 13:31:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 23 Jan 2008 07:30:08 -0600
From: "David Sinicrope" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85DC4.129C2CE7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Support for WG draft.

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,
=20
The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
=20
We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.
=20
Thanks,
Deborah

------_=_NextPart_001_01C85DC4.129C2CE7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1605" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D564472913-23012008><FONT face=3DArial color=3D#0000ff =

size=3D2>Support for WG draft.</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
ATTLABS<BR><B>Sent:</B> Tuesday, January 22, 2008 2:28 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> Proposed WG Draft -=20
draft-gmpls-ethernet-arch-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The DT =
proposed in=20
their meeting presentation&nbsp;for their architecture and framework=20
document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a couple=20
of comments&nbsp;in the meeting, we would appreciate additional =
feedback&nbsp;on=20
the list. Please express your support (or otherwise) for this I-D to =
become a WG=20
draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C85DC4.129C2CE7--

Delivery-date: Wed, 23 Jan 2008 12:38:27 +0000
Date: Wed, 23 Jan 2008 13:36:05 +0100
From: "Anders Gavler" <[email-masked]>
To: "DEBORAH A ATTLABS BRUNGARD" <[email-masked]>, <[email-masked]>
Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=__Part290FF4A5.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

In favor of this!

Anders Gavler
Acreo AB
Electrum 236
SE - 164 40 Kista
Phone: +46 8 632 77 29
Homepage: http://www.acreo.se

>>> "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> 2008-01-22 20:27
>>>
CCAMP,
 
The DT proposed in their meeting presentation for their architecture
and
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt 
 
We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.
 
Thanks,
Deborah

--=__Part290FF4A5.1__=
Content-Type: text/plain; name="Anders Gavler1.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Anders Gavler1.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Anders Gavler
TEL;WORK:08-6327729
EMAIL;WORK;PREF;NGW:[email-masked]
N:Gavler;Anders
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Anders Gavler
TEL;WORK:08-6327729
EMAIL;WORK;PREF;NGW:[email-masked]
N:Gavler;Anders
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Anders Gavler
TEL;WORK:08-6327729
EMAIL;WORK;PREF;NGW:[email-masked]
N:Gavler;Anders
END:VCARD

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Anders Gavler
TEL;WORK:08-6327729
EMAIL;WORK;PREF;NGW:[email-masked]
N:Gavler;Anders
END:VCARD

--=__Part290FF4A5.1__=--

Delivery-date: Wed, 23 Jan 2008 09:55:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Wed, 23 Jan 2008 10:52:50 +0100
From: "Attila Takacs" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85DA5.B712FDC4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In favor.
Attila

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: Tuesday, January 22, 2008 8:28 PM
	To: [email-masked]
	Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
=09
=09
	CCAMP,
	=20
	The DT proposed in their meeting presentation for their
architecture and framework document to be accepted as a WG draft:
=09
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
	=20
	We received a couple of comments in the meeting, we would
appreciate additional feedback on the list. Please express your support
(or otherwise) for this I-D to become a WG draft.
	=20
	Thanks,
	Deborah

------_=_NextPart_001_01C85DA5.B712FDC4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D133595109-23012008><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
favor.</FONT></SPAN></DIV>
<DIV><SPAN class=3D133595109-23012008><FONT face=3DArial color=3D#0000ff =

size=3D2>Attila</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, =
DEBORAH A,=20
  ATTLABS<BR><B>Sent:</B> Tuesday, January 22, 2008 8:28 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Proposed WG Draft -=20
  draft-gmpls-ethernet-arch-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The =
DT proposed in=20
  their meeting presentation&nbsp;for their architecture and framework=20
  document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a=20
  couple of comments&nbsp;in the meeting, we would appreciate additional =

  feedback&nbsp;on the list. Please express your support (or otherwise) =
for this=20
  I-D to become a WG draft.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY=
></HTML>

------_=_NextPart_001_01C85DA5.B712FDC4--

Delivery-date: Wed, 23 Jan 2008 00:10:16 +0000
Date: Tue, 22 Jan 2008 19:08:41 -0500
To: "PAPADIMITRIOU Dimitri" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: "Lou Berger" <[email-masked]>,"Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,<[email-masked]>

We've always had different switching type/capability in 
GMPLS.  Nothing new here.

L2SC was always underspecified (e.g., covers both ATM and Ether), is 
currently used by some for different purposes, and doesn't allow 
unique identification of switching capabilities of an interface.  I 
*really* don't see the unique identification of an interface's 
Ethernet switching function as any different from what is done for 
today for the other types or as any big deal or change in GMPLS 
direction or architecture.

but, that's just my perspective.

Lou

At 05:44 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
>thus the question is whether or not to ask for a change CCAMP "common
>control" in DCAMP "differentiated control" per technology ?
>
>we never have had a techno inducing a base building block change (GMPLS
>being a generalisation of MPLS-TE). i'm afraid that generalized LSP,
>generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would
>simply be unapplicable as known today and thus the corr. base protocol
>specs unapplicable. at the end the term "GMPLS" would be emptied of any
>real substance.
>
>it's a choice but let's ask the questions from the right perspective.
>
>-d.
>
> > -----Original Message-----
> > From: Lou Berger [mailto:[email-masked]]
> > Sent: Tuesday, January 22, 2008 11:28 PM
> > To: PAPADIMITRIOU Dimitri
> > Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > I have no objection to adding "Updates: 3945" to the document header
> > and matching 3945's category.
> >
> > Lou
> >
> > At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> > >Lou
> > >
> > >what i am concerned with: is that the doc extends
> > applicability of GMPLS
> > >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that
> > >make sense ?
> > >
> > >what's needed instead of hiding behind terms is to state GMPLS for Y,
> > >where Y includes the set of Ethernet-based techno's under
> > development at
> > >places as indicated in the doc itself. instead of inducing by a title
> > >such as "GMPLS for Ethernet" that this doc supersedes any
> > previous work
> > >in that
> > >space.
> > >
> > >-d.
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > > To: Don Fedyk
> > > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > > [email-masked]
> > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > Don,
> > > >          I agree 100%.  Furthermore there is no statement in the
> > > > draft that 3945 doesn't apply, in fact it explicitly says just the
> > > > opposite.  The reason for the statement in question is
> > simply as you
> > > > say, and to ensure full ETH-LSP definition and interoperable
> > > > operation a new switching type/capability is required.
> > > >
> > > > It's really not such a bid deal or major change.
> > > >
> > > > Lou
> > > >
> > > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > > >Hi Dimitri
> > > > >
> > > > >The text you quote was put in the architecture/ framework, not to
> > > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > > L2SC, which
> > > > >has been there for many years and may be in use.
> > > > >
> > > > >Perhaps the working needs to be adjusted but I don't think
> > > > it is a major
> > > > >issue.
> > > > >
> > > > >Regards,
> > > > >Don
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]] On Behalf Of
> > > > PAPADIMITRIOU Dimitri
> > > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > > Subject: RE: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > > >
> > > > > > All,
> > > > > >
> > > > > > > We received a couple of comments in the meeting, we would
> > > > > > > appreciate additional feedback on the list.
> > > > > >
> > > > > > The document states:
> > > > > >
> > > > > > "The L2SC Interface Switching Capabilities MUST NOT be used
> > > > > > to represent
> > > > > > interfaces capable of supporting Eth-LSPs. Interface Switching
> > > > > > Capability specific TE information may be defined as
> > > > needed to support
> > > > > > the requirements of a specific Ethernet Switching
> > Service Type."
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > "It is expected that there will be no case where an
> > > > Eth-LSP will be
> > > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > > represented, using
> > > > > > the L2SC switching type/capability. A new switching
> > > > type/capability is
> > > > > > required to avoid any potential current usage of the L2SC
> > > > switching
> > > > > > type/capability in support of Ethernet."
> > > > > >
> > > > > > This is explicit statement that GMPLS per RFC 3945 is not
> > > > applicable.
> > > > > > So, it is much more than just an additional codepoint, as
> > > > the control
> > > > > > plane behaviour is to be defined for this codepoint. So, it
> > > > > > is the open
> > > > > > door for a new control plane behaviour.
> > > > > >
> > > > > > so, let's have a more basic questioning before jumping
> > > > into the single
> > > > > > alternative resulting from this doc.:
> > > > > >
> > > > > > - either it is GMPLS for Ethernet architecture and then
> > > > what exist in
> > > > > > current RFCs should be applicable (because i do not see
> > > > any rationale
> > > > > > for L2SC def. departure for Ethernet frame processing);
> > > > > >
> > > > > > - or not it is X for Y architecture, where X is an IP
> > > > control protocol
> > > > > > based some potentially on some existing GMPLS blocks
> > and Y is not
> > > > > > compatible with the existing definition of Eth frame
> > processing.
> > > > > >
> > > > > > In the latter case, i do not know how this WG can deal
> > > > with such case
> > > > > > (from the control plane perspective).
> > > > > >
> > > > > > -d.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > > > > > DEBORAH A, ATTLABS
> > > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > > To: [email-masked]
> > > > > > > Subject: Proposed WG Draft -
> > draft-gmpls-ethernet-arch-00.txt
> > > > > > >
> > > > > > > CCAMP,
> > > > > > >
> > > > > > > The DT proposed in their meeting presentation for their
> > > > > > > architecture and framework document to be accepted as a
> > > > WG draft:
> > > > > > >
> > > >
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > > >
> > > > > > > We received a couple of comments in the meeting, we would
> > > > > > > appreciate additional feedback on the list. Please express
> > > > > > > your support (or otherwise) for this I-D to become
> > a WG draft.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Deborah
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >

Delivery-date: Tue, 22 Jan 2008 22:46:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 23:44:49 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

thus the question is whether or not to ask for a change CCAMP "common
control" in DCAMP "differentiated control" per technology ?=20

we never have had a techno inducing a base building block change (GMPLS
being a generalisation of MPLS-TE). i'm afraid that generalized LSP,
generalized LSR, generalized label, etc. per GMPLS arch (RFC 3945) would
simply be unapplicable as known today and thus the corr. base protocol
specs unapplicable. at the end the term "GMPLS" would be emptied of any
real substance.

it's a choice but let's ask the questions from the right perspective.

-d.=20

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]=20
> Sent: Tuesday, January 22, 2008 11:28 PM
> To: PAPADIMITRIOU Dimitri
> Cc: Lou Berger; Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> I have no objection to adding "Updates: 3945" to the document header=20
> and matching 3945's category.
>=20
> Lou
>=20
> At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
> >Lou
> >
> >what i am concerned with: is that the doc extends=20
> applicability of GMPLS
> >to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that
> >make sense ?
> >
> >what's needed instead of hiding behind terms is to state GMPLS for Y,
> >where Y includes the set of Ethernet-based techno's under=20
> development at
> >places as indicated in the doc itself. instead of inducing by a title
> >such as "GMPLS for Ethernet" that this doc supersedes any=20
> previous work
> >in that
> >space.
> >
> >-d.
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Lou Berger
> > > Sent: Tuesday, January 22, 2008 10:50 PM
> > > To: Don Fedyk
> > > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > > [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > > Don,
> > >          I agree 100%.  Furthermore there is no statement in the
> > > draft that 3945 doesn't apply, in fact it explicitly says just the
> > > opposite.  The reason for the statement in question is=20
> simply as you
> > > say, and to ensure full ETH-LSP definition and interoperable
> > > operation a new switching type/capability is required.
> > >
> > > It's really not such a bid deal or major change.
> > >
> > > Lou
> > >
> > > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > > >Hi Dimitri
> > > >
> > > >The text you quote was put in the architecture/ framework, not to
> > > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > > L2SC, which
> > > >has been there for many years and may be in use.
> > > >
> > > >Perhaps the working needs to be adjusted but I don't think
> > > it is a major
> > > >issue.
> > > >
> > > >Regards,
> > > >Don
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of
> > > PAPADIMITRIOU Dimitri
> > > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > > Subject: RE: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > All,
> > > > >
> > > > > > We received a couple of comments in the meeting, we would
> > > > > > appreciate additional feedback on the list.
> > > > >
> > > > > The document states:
> > > > >
> > > > > "The L2SC Interface Switching Capabilities MUST NOT be used
> > > > > to represent
> > > > > interfaces capable of supporting Eth-LSPs. Interface Switching
> > > > > Capability specific TE information may be defined as
> > > needed to support
> > > > > the requirements of a specific Ethernet Switching=20
> Service Type."
> > > > >
> > > > > [...]
> > > > >
> > > > > "It is expected that there will be no case where an
> > > Eth-LSP will be
> > > > > signaled, or an Eth-LSP supporting interface will be
> > > > > represented, using
> > > > > the L2SC switching type/capability. A new switching
> > > type/capability is
> > > > > required to avoid any potential current usage of the L2SC
> > > switching
> > > > > type/capability in support of Ethernet."
> > > > >
> > > > > This is explicit statement that GMPLS per RFC 3945 is not
> > > applicable.
> > > > > So, it is much more than just an additional codepoint, as
> > > the control
> > > > > plane behaviour is to be defined for this codepoint. So, it
> > > > > is the open
> > > > > door for a new control plane behaviour.
> > > > >
> > > > > so, let's have a more basic questioning before jumping
> > > into the single
> > > > > alternative resulting from this doc.:
> > > > >
> > > > > - either it is GMPLS for Ethernet architecture and then
> > > what exist in
> > > > > current RFCs should be applicable (because i do not see
> > > any rationale
> > > > > for L2SC def. departure for Ethernet frame processing);
> > > > >
> > > > > - or not it is X for Y architecture, where X is an IP
> > > control protocol
> > > > > based some potentially on some existing GMPLS blocks=20
> and Y is not
> > > > > compatible with the existing definition of Eth frame=20
> processing.
> > > > >
> > > > > In the latter case, i do not know how this WG can deal
> > > with such case
> > > > > (from the control plane perspective).
> > > > >
> > > > > -d.
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > > > > DEBORAH A, ATTLABS
> > > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > > To: [email-masked]
> > > > > > Subject: Proposed WG Draft -=20
> draft-gmpls-ethernet-arch-00.txt
> > > > > >
> > > > > > CCAMP,
> > > > > >
> > > > > > The DT proposed in their meeting presentation for their
> > > > > > architecture and framework document to be accepted as a
> > > WG draft:
> > > > > >
> > >=20
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > > >
> > > > > > We received a couple of comments in the meeting, we would
> > > > > > appreciate additional feedback on the list. Please express
> > > > > > your support (or otherwise) for this I-D to become=20
> a WG draft.
> > > > > >
> > > > > > Thanks,
> > > > > > Deborah
> > > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>=20
>=20

Delivery-date: Tue, 22 Jan 2008 22:28:38 +0000
Date: Tue, 22 Jan 2008 17:28:08 -0500
To: "PAPADIMITRIOU Dimitri" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: "Lou Berger" <[email-masked]>,"Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,<[email-masked]>

I have no objection to adding "Updates: 3945" to the document header 
and matching 3945's category.

Lou

At 05:11 PM 1/22/2008, PAPADIMITRIOU Dimitri wrote:
>Lou
>
>what i am concerned with: is that the doc extends applicability of GMPLS
>to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that
>make sense ?
>
>what's needed instead of hiding behind terms is to state GMPLS for Y,
>where Y includes the set of Ethernet-based techno's under development at
>places as indicated in the doc itself. instead of inducing by a title
>such as "GMPLS for Ethernet" that this doc supersedes any previous work
>in that
>space.
>
>-d.
>
>
>
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Lou Berger
> > Sent: Tuesday, January 22, 2008 10:50 PM
> > To: Don Fedyk
> > Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;
> > [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > Don,
> >          I agree 100%.  Furthermore there is no statement in the
> > draft that 3945 doesn't apply, in fact it explicitly says just the
> > opposite.  The reason for the statement in question is simply as you
> > say, and to ensure full ETH-LSP definition and interoperable
> > operation a new switching type/capability is required.
> >
> > It's really not such a bid deal or major change.
> >
> > Lou
> >
> > At 04:34 PM 1/22/2008, Don Fedyk wrote:
> > >Hi Dimitri
> > >
> > >The text you quote was put in the architecture/ framework, not to
> > >exclude L2 Switch Capable (L2SC) but to prevent redefining
> > L2SC, which
> > >has been there for many years and may be in use.
> > >
> > >Perhaps the working needs to be adjusted but I don't think
> > it is a major
> > >issue.
> > >
> > >Regards,
> > >Don
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of
> > PAPADIMITRIOU Dimitri
> > > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > All,
> > > >
> > > > > We received a couple of comments in the meeting, we would
> > > > > appreciate additional feedback on the list.
> > > >
> > > > The document states:
> > > >
> > > > "The L2SC Interface Switching Capabilities MUST NOT be used
> > > > to represent
> > > > interfaces capable of supporting Eth-LSPs. Interface Switching
> > > > Capability specific TE information may be defined as
> > needed to support
> > > > the requirements of a specific Ethernet Switching Service Type."
> > > >
> > > > [...]
> > > >
> > > > "It is expected that there will be no case where an
> > Eth-LSP will be
> > > > signaled, or an Eth-LSP supporting interface will be
> > > > represented, using
> > > > the L2SC switching type/capability. A new switching
> > type/capability is
> > > > required to avoid any potential current usage of the L2SC
> > switching
> > > > type/capability in support of Ethernet."
> > > >
> > > > This is explicit statement that GMPLS per RFC 3945 is not
> > applicable.
> > > > So, it is much more than just an additional codepoint, as
> > the control
> > > > plane behaviour is to be defined for this codepoint. So, it
> > > > is the open
> > > > door for a new control plane behaviour.
> > > >
> > > > so, let's have a more basic questioning before jumping
> > into the single
> > > > alternative resulting from this doc.:
> > > >
> > > > - either it is GMPLS for Ethernet architecture and then
> > what exist in
> > > > current RFCs should be applicable (because i do not see
> > any rationale
> > > > for L2SC def. departure for Ethernet frame processing);
> > > >
> > > > - or not it is X for Y architecture, where X is an IP
> > control protocol
> > > > based some potentially on some existing GMPLS blocks and Y is not
> > > > compatible with the existing definition of Eth frame processing.
> > > >
> > > > In the latter case, i do not know how this WG can deal
> > with such case
> > > > (from the control plane perspective).
> > > >
> > > > -d.
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked]
> > > > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > > > DEBORAH A, ATTLABS
> > > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > > To: [email-masked]
> > > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > CCAMP,
> > > > >
> > > > > The DT proposed in their meeting presentation for their
> > > > > architecture and framework document to be accepted as a
> > WG draft:
> > > > >
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > > >
> > > > > We received a couple of comments in the meeting, we would
> > > > > appreciate additional feedback on the list. Please express
> > > > > your support (or otherwise) for this I-D to become a WG draft.
> > > > >
> > > > > Thanks,
> > > > > Deborah
> > > > >
> > > >
> > > >
> >
> >
> >

Delivery-date: Tue, 22 Jan 2008 22:13:09 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 23:11:21 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Lou Berger" <[email-masked]>, "Don Fedyk" <[email-masked]>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Lou

what i am concerned with: is that the doc extends applicability of GMPLS
to Ethernet by excluding GMPLS for Ethernet per RFC 3945 ? does that
make sense ?

what's needed instead of hiding behind terms is to state GMPLS for Y,
where Y includes the set of Ethernet-based techno's under development at
places as indicated in the doc itself. instead of inducing by a title
such as "GMPLS for Ethernet" that this doc supersedes any previous work
in that
space.

-d.

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Tuesday, January 22, 2008 10:50 PM
> To: Don Fedyk
> Cc: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Don,
>          I agree 100%.  Furthermore there is no statement in the=20
> draft that 3945 doesn't apply, in fact it explicitly says just the=20
> opposite.  The reason for the statement in question is simply as you=20
> say, and to ensure full ETH-LSP definition and interoperable=20
> operation a new switching type/capability is required.
>=20
> It's really not such a bid deal or major change.
>=20
> Lou
>=20
> At 04:34 PM 1/22/2008, Don Fedyk wrote:
> >Hi Dimitri
> >
> >The text you quote was put in the architecture/ framework, not to
> >exclude L2 Switch Capable (L2SC) but to prevent redefining=20
> L2SC, which
> >has been there for many years and may be in use.
> >
> >Perhaps the working needs to be adjusted but I don't think=20
> it is a major
> >issue.
> >
> >Regards,
> >Don
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of=20
> PAPADIMITRIOU Dimitri
> > > Sent: Tuesday, January 22, 2008 4:16 PM
> > > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > > All,
> > >
> > > > We received a couple of comments in the meeting, we would
> > > > appreciate additional feedback on the list.
> > >
> > > The document states:
> > >
> > > "The L2SC Interface Switching Capabilities MUST NOT be used
> > > to represent
> > > interfaces capable of supporting Eth-LSPs. Interface Switching
> > > Capability specific TE information may be defined as=20
> needed to support
> > > the requirements of a specific Ethernet Switching Service Type."
> > >
> > > [...]
> > >
> > > "It is expected that there will be no case where an=20
> Eth-LSP will be
> > > signaled, or an Eth-LSP supporting interface will be
> > > represented, using
> > > the L2SC switching type/capability. A new switching=20
> type/capability is
> > > required to avoid any potential current usage of the L2SC=20
> switching
> > > type/capability in support of Ethernet."
> > >
> > > This is explicit statement that GMPLS per RFC 3945 is not=20
> applicable.
> > > So, it is much more than just an additional codepoint, as=20
> the control
> > > plane behaviour is to be defined for this codepoint. So, it
> > > is the open
> > > door for a new control plane behaviour.
> > >
> > > so, let's have a more basic questioning before jumping=20
> into the single
> > > alternative resulting from this doc.:
> > >
> > > - either it is GMPLS for Ethernet architecture and then=20
> what exist in
> > > current RFCs should be applicable (because i do not see=20
> any rationale
> > > for L2SC def. departure for Ethernet frame processing);
> > >
> > > - or not it is X for Y architecture, where X is an IP=20
> control protocol
> > > based some potentially on some existing GMPLS blocks and Y is not
> > > compatible with the existing definition of Eth frame processing.
> > >
> > > In the latter case, i do not know how this WG can deal=20
> with such case
> > > (from the control plane perspective).
> > >
> > > -d.
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > > DEBORAH A, ATTLABS
> > > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > > To: [email-masked]
> > > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > CCAMP,
> > > >
> > > > The DT proposed in their meeting presentation for their
> > > > architecture and framework document to be accepted as a=20
> WG draft:
> > > >=20
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > >
> > > > We received a couple of comments in the meeting, we would
> > > > appreciate additional feedback on the list. Please express
> > > > your support (or otherwise) for this I-D to become a WG draft.
> > > >
> > > > Thanks,
> > > > Deborah
> > > >
> > >
> > >
>=20
>=20
>=20

Delivery-date: Tue, 22 Jan 2008 21:53:42 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 22:52:55 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "Don Fedyk" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Don,

then two things are missing that this new xSC is not resulting in a
control plane departing from RFC 3945 and this xSC is not part
overlapping with L2SC.=20

you are thus in the alternative: GMPLS for Y architecture, where Y is
not compatible with the existing definition of Eth frame processing per
L2SC ? is that correct.

thanks,
-d.

=20

> -----Original Message-----
> From: Don Fedyk [mailto:[email-masked]]=20
> Sent: Tuesday, January 22, 2008 10:35 PM
> To: PAPADIMITRIOU Dimitri; BRUNGARD, DEBORAH A, ATTLABS;=20
> [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> Hi Dimitri
>=20
> The text you quote was put in the architecture/ framework, not to
> exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
> has been there for many years and may be in use.=20
>=20
> Perhaps the working needs to be adjusted but I don't think it=20
> is a major
> issue.
>=20
> Regards,
> Don=20
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Tuesday, January 22, 2008 4:16 PM
> > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > All,
> >=20
> > > We received a couple of comments in the meeting, we would=20
> > > appreciate additional feedback on the list.
> >=20
> > The document states:
> >=20
> > "The L2SC Interface Switching Capabilities MUST NOT be used=20
> > to represent
> > interfaces capable of supporting Eth-LSPs. Interface Switching
> > Capability specific TE information may be defined as needed=20
> to support
> > the requirements of a specific Ethernet Switching Service Type."
> >=20
> > [...]
> >=20
> > "It is expected that there will be no case where an Eth-LSP will be
> > signaled, or an Eth-LSP supporting interface will be=20
> > represented, using
> > the L2SC switching type/capability. A new switching=20
> type/capability is
> > required to avoid any potential current usage of the L2SC switching
> > type/capability in support of Ethernet."
> >=20
> > This is explicit statement that GMPLS per RFC 3945 is not=20
> applicable.
> > So, it is much more than just an additional codepoint, as=20
> the control
> > plane behaviour is to be defined for this codepoint. So, it=20
> > is the open
> > door for a new control plane behaviour.=20
> >=20
> > so, let's have a more basic questioning before jumping into=20
> the single
> > alternative resulting from this doc.:
> >=20
> > - either it is GMPLS for Ethernet architecture and then=20
> what exist in
> > current RFCs should be applicable (because i do not see any=20
> rationale
> > for L2SC def. departure for Ethernet frame processing);
> >=20
> > - or not it is X for Y architecture, where X is an IP=20
> control protocol
> > based some potentially on some existing GMPLS blocks and Y is not
> > compatible with the existing definition of Eth frame processing.
> >=20
> > In the latter case, i do not know how this WG can deal with=20
> such case
> > (from the control plane perspective).
> >=20
> > -d.
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: [email-masked]=20
> > > [mailto:[email-masked]] On Behalf Of BRUNGARD,=20
> > > DEBORAH A, ATTLABS
> > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > To: [email-masked]
> > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >=20
> > > CCAMP,
> > > =20
> > > The DT proposed in their meeting presentation for their=20
> > > architecture and framework document to be accepted as a WG draft:
> > >=20
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > > =20
> > > We received a couple of comments in the meeting, we would=20
> > > appreciate additional feedback on the list. Please express=20
> > > your support (or otherwise) for this I-D to become a WG draft.
> > > =20
> > > Thanks,
> > > Deborah
> > >=20
> >=20
> >=20
>=20

Delivery-date: Tue, 22 Jan 2008 21:51:07 +0000
Date: Tue, 22 Jan 2008 16:50:25 -0500
To: "Don Fedyk" <[email-masked]>
From: Lou Berger <[email-masked]>
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Cc: "PAPADIMITRIOU Dimitri" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>,<[email-masked]>

Don,
         I agree 100%.  Furthermore there is no statement in the 
draft that 3945 doesn't apply, in fact it explicitly says just the 
opposite.  The reason for the statement in question is simply as you 
say, and to ensure full ETH-LSP definition and interoperable 
operation a new switching type/capability is required.

It's really not such a bid deal or major change.

Lou

At 04:34 PM 1/22/2008, Don Fedyk wrote:
>Hi Dimitri
>
>The text you quote was put in the architecture/ framework, not to
>exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
>has been there for many years and may be in use.
>
>Perhaps the working needs to be adjusted but I don't think it is a major
>issue.
>
>Regards,
>Don
>
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> > Sent: Tuesday, January 22, 2008 4:16 PM
> > To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> > Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >
> > All,
> >
> > > We received a couple of comments in the meeting, we would
> > > appreciate additional feedback on the list.
> >
> > The document states:
> >
> > "The L2SC Interface Switching Capabilities MUST NOT be used
> > to represent
> > interfaces capable of supporting Eth-LSPs. Interface Switching
> > Capability specific TE information may be defined as needed to support
> > the requirements of a specific Ethernet Switching Service Type."
> >
> > [...]
> >
> > "It is expected that there will be no case where an Eth-LSP will be
> > signaled, or an Eth-LSP supporting interface will be
> > represented, using
> > the L2SC switching type/capability. A new switching type/capability is
> > required to avoid any potential current usage of the L2SC switching
> > type/capability in support of Ethernet."
> >
> > This is explicit statement that GMPLS per RFC 3945 is not applicable.
> > So, it is much more than just an additional codepoint, as the control
> > plane behaviour is to be defined for this codepoint. So, it
> > is the open
> > door for a new control plane behaviour.
> >
> > so, let's have a more basic questioning before jumping into the single
> > alternative resulting from this doc.:
> >
> > - either it is GMPLS for Ethernet architecture and then what exist in
> > current RFCs should be applicable (because i do not see any rationale
> > for L2SC def. departure for Ethernet frame processing);
> >
> > - or not it is X for Y architecture, where X is an IP control protocol
> > based some potentially on some existing GMPLS blocks and Y is not
> > compatible with the existing definition of Eth frame processing.
> >
> > In the latter case, i do not know how this WG can deal with such case
> > (from the control plane perspective).
> >
> > -d.
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of BRUNGARD,
> > > DEBORAH A, ATTLABS
> > > Sent: Tuesday, January 22, 2008 8:28 PM
> > > To: [email-masked]
> > > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > >
> > > CCAMP,
> > >
> > > The DT proposed in their meeting presentation for their
> > > architecture and framework document to be accepted as a WG draft:
> > > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > >
> > > We received a couple of comments in the meeting, we would
> > > appreciate additional feedback on the list. Please express
> > > your support (or otherwise) for this I-D to become a WG draft.
> > >
> > > Thanks,
> > > Deborah
> > >
> >
> >

Delivery-date: Tue, 22 Jan 2008 21:35:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 16:34:58 -0500
From: "Don Fedyk" <[email-masked]>
To: "PAPADIMITRIOU Dimitri" <[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

Hi Dimitri

The text you quote was put in the architecture/ framework, not to
exclude L2 Switch Capable (L2SC) but to prevent redefining L2SC, which
has been there for many years and may be in use.=20

Perhaps the working needs to be adjusted but I don't think it is a major
issue.

Regards,
Don=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: Tuesday, January 22, 2008 4:16 PM
> To: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> All,
>=20
> > We received a couple of comments in the meeting, we would=20
> > appreciate additional feedback on the list.
>=20
> The document states:
>=20
> "The L2SC Interface Switching Capabilities MUST NOT be used=20
> to represent
> interfaces capable of supporting Eth-LSPs. Interface Switching
> Capability specific TE information may be defined as needed to support
> the requirements of a specific Ethernet Switching Service Type."
>=20
> [...]
>=20
> "It is expected that there will be no case where an Eth-LSP will be
> signaled, or an Eth-LSP supporting interface will be=20
> represented, using
> the L2SC switching type/capability. A new switching type/capability is
> required to avoid any potential current usage of the L2SC switching
> type/capability in support of Ethernet."
>=20
> This is explicit statement that GMPLS per RFC 3945 is not applicable.
> So, it is much more than just an additional codepoint, as the control
> plane behaviour is to be defined for this codepoint. So, it=20
> is the open
> door for a new control plane behaviour.=20
>=20
> so, let's have a more basic questioning before jumping into the single
> alternative resulting from this doc.:
>=20
> - either it is GMPLS for Ethernet architecture and then what exist in
> current RFCs should be applicable (because i do not see any rationale
> for L2SC def. departure for Ethernet frame processing);
>=20
> - or not it is X for Y architecture, where X is an IP control protocol
> based some potentially on some existing GMPLS blocks and Y is not
> compatible with the existing definition of Eth frame processing.
>=20
> In the latter case, i do not know how this WG can deal with such case
> (from the control plane perspective).
>=20
> -d.
>=20
>=20
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of BRUNGARD,=20
> > DEBORAH A, ATTLABS
> > Sent: Tuesday, January 22, 2008 8:28 PM
> > To: [email-masked]
> > Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> >=20
> > CCAMP,
> > =20
> > The DT proposed in their meeting presentation for their=20
> > architecture and framework document to be accepted as a WG draft:
> > http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> > =20
> > We received a couple of comments in the meeting, we would=20
> > appreciate additional feedback on the list. Please express=20
> > your support (or otherwise) for this I-D to become a WG draft.
> > =20
> > Thanks,
> > Deborah
> >=20
>=20
>=20

Delivery-date: Tue, 22 Jan 2008 21:16:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 22:16:00 +0100
From: "PAPADIMITRIOU Dimitri" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

All,

> We received a couple of comments in the meeting, we would=20
> appreciate additional feedback on the list.

The document states:

"The L2SC Interface Switching Capabilities MUST NOT be used to represent
interfaces capable of supporting Eth-LSPs. Interface Switching
Capability specific TE information may be defined as needed to support
the requirements of a specific Ethernet Switching Service Type."

[...]

"It is expected that there will be no case where an Eth-LSP will be
signaled, or an Eth-LSP supporting interface will be represented, using
the L2SC switching type/capability. A new switching type/capability is
required to avoid any potential current usage of the L2SC switching
type/capability in support of Ethernet."

This is explicit statement that GMPLS per RFC 3945 is not applicable.
So, it is much more than just an additional codepoint, as the control
plane behaviour is to be defined for this codepoint. So, it is the open
door for a new control plane behaviour.=20

so, let's have a more basic questioning before jumping into the single
alternative resulting from this doc.:

- either it is GMPLS for Ethernet architecture and then what exist in
current RFCs should be applicable (because i do not see any rationale
for L2SC def. departure for Ethernet frame processing);

- or not it is X for Y architecture, where X is an IP control protocol
based some potentially on some existing GMPLS blocks and Y is not
compatible with the existing definition of Eth frame processing.

In the latter case, i do not know how this WG can deal with such case
(from the control plane perspective).

-d.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of BRUNGARD,=20
> DEBORAH A, ATTLABS
> Sent: Tuesday, January 22, 2008 8:28 PM
> To: [email-masked]
> Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>=20
> CCAMP,
> =20
> The DT proposed in their meeting presentation for their=20
> architecture and framework document to be accepted as a WG draft:
> http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
> =20
> We received a couple of comments in the meeting, we would=20
> appreciate additional feedback on the list. Please express=20
> your support (or otherwise) for this I-D to become a WG draft.
> =20
> Thanks,
> Deborah
>=20

Delivery-date: Tue, 22 Jan 2008 21:13:35 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 16:13:00 -0500
From: "Don Fedyk" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D3B.919D98EF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In Favor,
=20
Thanks,
Don=20

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: Tuesday, January 22, 2008 2:28 PM
	To: [email-masked]
	Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
=09
=09
	CCAMP,
	=20
	The DT proposed in their meeting presentation for their
architecture and framework document to be accepted as a WG draft:
=09
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
	=20
	We received a couple of comments in the meeting, we would
appreciate additional feedback on the list. Please express your support
(or otherwise) for this I-D to become a WG draft.
	=20
	Thanks,
	Deborah

------_=_NextPart_001_01C85D3B.919D98EF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D784440721-22012008>In Favor,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D784440721-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D784440721-22012008>Thanks,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D784440721-22012008>Don </SPAN></FONT></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>BRUNGARD, =
DEBORAH A,=20
  ATTLABS<BR><B>Sent:</B> Tuesday, January 22, 2008 2:28 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Proposed WG Draft -=20
  draft-gmpls-ethernet-arch-00.txt<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The =
DT proposed in=20
  their meeting presentation&nbsp;for their architecture and framework=20
  document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a=20
  couple of comments&nbsp;in the meeting, we would appreciate additional =

  feedback&nbsp;on the list. Please express your support (or otherwise) =
for this=20
  I-D to become a WG draft.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY=
></HTML>

------_=_NextPart_001_01C85D3B.919D98EF--

Delivery-date: Tue, 22 Jan 2008 21:05:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 16:04:19 -0500
From: "Shah, Himanshu" <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D3A.5AE561BA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

support for WG draft..
=20
/himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On =
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 2:28 PM
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

CCAMP,
=20
The DT proposed in their meeting presentation for their architecture and =
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
=20
We received a couple of comments in the meeting, we would appreciate =
additional feedback on the list. Please express your support (or =
otherwise) for this I-D to become a WG draft.
=20
Thanks,
Deborah

------_=_NextPart_001_01C85D3A.5AE561BA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<META content=3D"MSHTML 6.00.2800.1605" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D622450321-22012008><FONT face=3DGaramond =
color=3D#0000ff>support=20
for WG draft..</FONT></SPAN></DIV>
<DIV><SPAN class=3D622450321-22012008><FONT face=3DGaramond=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D622450321-22012008><FONT face=3DGaramond=20
color=3D#0000ff>/himanshu</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>BRUNGARD, DEBORAH =
A,=20
  ATTLABS<BR><B>Sent:</B> Tuesday, January 22, 2008 2:28 =
PM<BR><B>To:</B>=20
  [email-masked]<BR><B>Subject:</B> Proposed WG Draft -=20
  draft-gmpls-ethernet-arch-00.txt<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The =
DT proposed in=20
  their meeting presentation&nbsp;for their architecture and framework=20
  document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a=20
  couple of comments&nbsp;in the meeting, we would appreciate additional =

  feedback&nbsp;on the list. Please express your support (or otherwise) =
for this=20
  I-D to become a WG draft.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2><SPAN=20
  =
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BLOCKQUOTE></BODY=
></HTML>

------_=_NextPart_001_01C85D3A.5AE561BA--

Delivery-date: Tue, 22 Jan 2008 20:29:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 22:28:36 +0200
From: "Nurit Sprecher" <[email-masked]>
To: "ext BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D35.6195E455
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,

I am in favor of this as well :-)

Best regards,

Nurit

=20

________________________________

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]=20
Sent: Tuesday, January 22, 2008 22:25
To: Nurit Sprecher
Cc: [email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

=20

Hi Nurit,

=20

We will poll one-by-one to ensure separation;-)

=20

Deborah

=20

________________________________

From: Nurit Sprecher [mailto:[email-masked]]=20
Sent: Tuesday, January 22, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

Hi,

=20

I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft.

=20

In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt
also proposed that their draft is accepted as a WG draft. Naturally, I
am in favor of this as well. Can we ask feedback for this draft as well?

=20

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 21:28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

=20

CCAMP,

=20

The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt

=20

We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.

=20

Thanks,

Deborah

------_=_NextPart_001_01C85D35.6195E455
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<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:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[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]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi =
Deborah,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I am in favor of =
this as
well </span></font><font size=3D2 color=3Dnavy face=3DWingdings><span
style=3D'font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></fon=
t><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p><=
/span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> ext
BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
22, 2008
22:25<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Nurit Sprecher<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed WG =
Draft -
draft-gmpls-ethernet-arch-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi =
Nurit,</span></font><o:p></o:p></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>We will poll =
one-by-one
to ensure separation;-)</span></font><o:p></o:p></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Deborah</span></f=
ont><o:p></o:p></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR style=3D'margin-bottom:12.0pt'><b><font =
size=3D2
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'> Nurit
Sprecher [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
22, 2008
3:10 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> BRUNGARD, DEBORAH A, =
ATTLABS<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Proposed WG =
Draft -
draft-gmpls-ethernet-arch-00.txt</span></font><o:p></o:p></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think that
draft-gmpls-ethernet-arch-00.txt should be a WG =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In addition, the =
authors
of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their =
draft is
accepted as a WG draft. Naturally, I am in favor of this as well. Can we =
ask
feedback for this draft as well?<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p><=
/span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabIndex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>ext BRUNGARD, DEBORAH =
A,
ATTLABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
22, 2008
21:28<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed WG =
Draft -
draft-gmpls-ethernet-arch-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The DT proposed in their meeting =
presentation&nbsp;for their
architecture and framework document&nbsp;to be&nbsp;accepted as =
a&nbsp;WG
draft:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We received a couple of comments&nbsp;in the meeting, =
we
would appreciate additional feedback&nbsp;on the list. Please express =
your
support (or otherwise) for this I-D to become a WG =
draft.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Deborah</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C85D35.6195E455--

Delivery-date: Tue, 22 Jan 2008 20:25:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 14:24:42 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: "Nurit Sprecher" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D34.D26ACD5F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Nurit,
=20
We will poll one-by-one to ensure separation;-)
=20
Deborah

________________________________

From: Nurit Sprecher [mailto:[email-masked]]=20
Sent: Tuesday, January 22, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

Hi,

=20

I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft.

=20

In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt
also proposed that their draft is accepted as a WG draft. Naturally, I
am in favor of this as well. Can we ask feedback for this draft as well?

=20

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 21:28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

=20

CCAMP,

=20

The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt

=20

We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.

=20

Thanks,

Deborah

------_=_NextPart_001_01C85D34.D26ACD5F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR><!--[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]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D458572120-22012008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Nurit,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D458572120-22012008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D458572120-22012008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We will poll one-by-one to ensure=20
separation;-)</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D458572120-22012008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D458572120-22012008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Deborah</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Nurit Sprecher=20
[mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, January 22, =
2008 3:10=20
PM<BR><B>To:</B> BRUNGARD, DEBORAH A, ATTLABS<BR><B>Cc:</B>=20
[email-masked]<BR><B>Subject:</B> RE: Proposed WG Draft -=20
draft-gmpls-ethernet-arch-00.txt<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1 dir=3Drtl>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Hi,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think that=20
draft-gmpls-ethernet-arch-00.txt should be a WG=20
draft.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">In addition, =
the=20
authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that =
their=20
draft is accepted as a WG draft. Naturally, I am in favor of this as =
well. Can=20
we ask feedback for this draft as well?<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Best=20
regards,<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Nurit<o:p></o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal dir=3Dltr style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
</SPAN></FONT></DIV>
<P class=3DMsoNormal dir=3Dltr><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
[email-masked] [mailto:[email-masked]] <B><SPAN=20
style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>ext BRUNGARD, =
DEBORAH A,=20
ATTLABS<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Tuesday, January=20
22, 2008 21:28<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B>=20
[email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B>=20
Proposed WG Draft -=20
draft-gmpls-ethernet-arch-00.txt</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">CCAMP,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">The DT proposed in their =
meeting=20
presentation&nbsp;for their architecture and framework document&nbsp;to=20
be&nbsp;accepted as a&nbsp;WG draft:</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">We received a couple of=20
comments&nbsp;in the meeting, we would appreciate additional =
feedback&nbsp;on=20
the list. Please express your support (or otherwise) for this I-D to =
become a WG=20
draft.</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">&nbsp;<o:p></o:p></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal dir=3Dltr><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Deborah</SPAN></FONT><o:p></o:p></P></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C85D34.D26ACD5F--

Delivery-date: Tue, 22 Jan 2008 20:10:36 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 22:09:37 +0200
From: "Nurit Sprecher" <[email-masked]>
To: "ext BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D32.BA8099CD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I think that draft-gmpls-ethernet-arch-00.txt should be a WG draft.

=20

In addition, the authors of draft-fedyk-gmpls-ethernet-pbb-te-02.txt
also proposed that their draft is accepted as a WG draft. Naturally, I
am in favor of this as well. Can we ask feedback for this draft as well?

=20

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, January 22, 2008 21:28
To: [email-masked]
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

=20

CCAMP,

=20

The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:

http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt

=20

We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.

=20

Thanks,

Deborah

------_=_NextPart_001_01C85D32.BA8099CD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<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:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[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]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue>

<div class=3DSection1 dir=3DRTL>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></s=
pan></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>I think that
draft-gmpls-ethernet-arch-00.txt should be a WG =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>In addition, the =
authors
of draft-fedyk-gmpls-ethernet-pbb-te-02.txt also proposed that their =
draft is
accepted as a WG draft. Naturally, I am in favor of this as well. Can we =
ask
feedback for this draft as well?<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Best =
regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Nurit<o:p></o:p><=
/span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter dir=3DLTR =
style=3D'text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal dir=3DLTR><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>ext BRUNGARD, DEBORAH =
A,
ATTLABS<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, January =
22, 2008
21:28<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Proposed WG =
Draft -
draft-gmpls-ethernet-arch-00.txt</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>CCAMP,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>The DT proposed in their meeting =
presentation&nbsp;for their
architecture and framework document&nbsp;to be&nbsp;accepted as =
a&nbsp;WG
draft:</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</a></span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We received a couple of comments&nbsp;in the meeting, =
we
would appreciate additional feedback&nbsp;on the list. Please express =
your
support (or otherwise) for this I-D to become a WG =
draft.</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal dir=3DLTR><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Deborah</span></font><o:p></o:p></p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C85D32.BA8099CD--

Delivery-date: Tue, 22 Jan 2008 19:30:36 +0000
Content-class: urn:content-classes:message
Subject: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Date: Tue, 22 Jan 2008 13:27:53 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85D2C.E28C7353
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

CCAMP,
=20
The DT proposed in their meeting presentation for their architecture and
framework document to be accepted as a WG draft:
http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt
=20
We received a couple of comments in the meeting, we would appreciate
additional feedback on the list. Please express your support (or
otherwise) for this I-D to become a WG draft.
=20
Thanks,
Deborah

------_=_NextPart_001_01C85D2C.E28C7353
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>The DT =
proposed in=20
their meeting presentation&nbsp;for their architecture and framework=20
document&nbsp;to be&nbsp;accepted as a&nbsp;WG =
draft:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.=
txt">http://www.ietf.org/internet-drafts/draft-gmpls-ethernet-arch-00.txt=
</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D783210619-22012008>We =
received a couple=20
of comments&nbsp;in the meeting, we would appreciate additional =
feedback&nbsp;on=20
the list. Please express your support (or otherwise) for this I-D to =
become a WG=20
draft.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D783210619-22012008>Deborah</SPAN></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C85D2C.E28C7353--

Delivery-date: Fri, 18 Jan 2008 21:39:49 +0000
Content-class: urn:content-classes:message
Subject: FW: Internet-Drafts Submission Cutoff Dates for the 71st IETF  Meeting in Philadelphia, PA, USA 
Date: Fri, 18 Jan 2008 15:37:04 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>

FYI - dates for submitting drafts.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Friday, January 18, 2008 12:00 AM
To: [email-masked]
Subject: Internet-Drafts Submission Cutoff Dates for the 71st IETF
Meeting in Philadelphia, PA, USA=20

There are two (2) Internet-Draft cutoff dates for the 71st=20
IETF Meeting in Philadelphia, PA, USA:

February 18th: Cutoff Date for Initial (i.e., version -00)=20
Internet-Draft Submissions=20

All initial Internet-Drafts (version -00) must be submitted by Monday,=20
February 18th at 9:00 AM ET (14:00 UTC/GMT).The only exception is for
version -00 WG drafts that replace existing non-WG drafts.  Such drafts
may be submitted until the cutoff date for version -01 and higher
drafts.
As always, all initial submissions with a filename beginning with=20
"draft-ietf" must be approved by the appropriate WG Chair before they=20
can be processed or announced.  The Secretariat would appreciate=20
receiving WG Chair approval by Monday, February 11th at 9:00 AM ET
(14:00 UTC/GMT).

February  (14:00 UTC/GMT): Cutoff Date for Revised (i.e., version -01
and higher)=20
Internet-Draft Submissions=20

All revised Internet-Drafts (version -01 and higher) must be submitted=20
by Monday, February 25th at 9:00 AM ET (14:00 UTC/GMT).

Initial and revised Internet-Drafts received after their respective=20
cutoff dates will not be made available in the Internet-Drafts=20
directory or announced until on or after Monday, March 10th at 9:00=20
AM ET (13:00 UTC/GMT), when Internet-Draft posting resumes.  Please do
not wait until=20
the last minute to submit.

The Secretariat encourages you to submit your Internet-Drafts via the=20
Internet-Draft Submission Tool (IDST)
https://datatracker.ietf.org/idst/upload.cgi.=20
If you are unable to do so, then you may still submit your Internet-
Drafts manually by sending them to [email-masked].  If you=20
are submitting a version -00 WG draft that replaces non-WG draft, then=20
you must submit it manually as the current IDST cannot handle=20
replacements.  Please be sure to state that one draft replaces another=20
in the cover note that accompanies your submission.  Also, please note=20
that the IDST will not accept drafts submitted after their respective=20
cutoff dates.

Thank you for your understanding and cooperation. If you have any=20
questions or concerns, then please send a message to=20
[email-masked].

The IETF Secretariat

FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 71st IETF Meeting can be found at
http://www.ietf.org/meetings/71-cutoff_dates.html.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

Delivery-date: Thu, 17 Jan 2008 22:03:10 +0000
Content-class: urn:content-classes:message
Subject: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS"
Date: Thu, 17 Jan 2008 16:00:20 -0600
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
To: <[email-masked]>
Cc: "Adrian Farrel" <[email-masked]>, "Ross Callon" <[email-masked]>, "David Ward" <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C85954.5B0F5017
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

CCAMP,

Here's a proposed response to ITU's Liaison:

https://datatracker.ietf.org/liaison/371/

Any comments?

Thanks,

Deborah and Adrian

=3D=3D=3D=3D

Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS

Purpose: For Action

Body:

The CCAMP Working Group thanks you for your liaison of September 2007
(Q12-14 Interim meeting - LS 005).

Here are our responses to the questions in your liaison:

Your Question 1: We provide here further clarification regarding our
previous comment re protocol extensibility to encompass technologies
other than SONET/SDH.  An example technology of interest to the
community was provided regarding the usage of virtually concatenated
ODUs for carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an
existing OTN infrastructure.  How this is accomplished is not defined at
this time and might not be using VCAT. A technology neutral approach
(i.e., one not dependent upon VCAT over SONET/SDH-unique parameters)
would avoid the need for developing a series of specialized solutions.

Our response: As we noted previously, it is certainly our intention that
functionality and any protocol extensions that we develop should be
easily extensible to support other than SONET/SDH technology, especially
technologies covered by GMPLS (e.g. OTN). This is the basis of GMPLS and
GMPLS call functionality development. If you have identified any
specific concerns with the current approach, we would appreciate your
input.

Your Question 2:  VCAT group signaling relates closely to multi-layer
call modeling, and it is our understanding that the draft is only
addressing the constituent server layer call.   We plan to perform
further work to clarify the interlayer call relationship in terms of the
ASON multilayer "call supporting call construct".

Our response: Noted. We look forward to further communication from you.

Your Question 3:   We agree that connections are not moved between
calls; the ASON "call supporting calls" construct is consistent with not
moving connections between calls.  Rec. G.7041 and G.7042 are only
concerned with membership of the VCAT group, and not with the use of a
member that has been removed (it is assumed to simply go back into the
pool of resources, where it can be drawn upon for other purposes).  Thus
G.7041 and G.7042 do not support the direct movement of a connection
from one VCAT group to another. Changing the association of a server
layer call/connection to a VCAT group does not necessarily result in
removal/deletion of that call/connection.

Our response: Noted.

Your Question 4:  We appreciate your clarification of the use of a
single call. However we suggest that you do not preclude extension to
use multiple calls. This is useful for example in diverse routing
applications.

Our response: As noted in our previous liaison, the call construct as
proposed in this draft is used to coordinate the (single type) server
layer connections for the VCAT functionality. This does not preclude use
of RFC 4974 in support of G.8080 call functionality. To ensure that we
understand correctly your request, can you provide additional
information regarding using multiple calls in support of diverse routing
applications?

Your Question 5:  We understand that this draft is only addressing the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

Our response: As noted above, this is not precluded. We look forward to
future communication from you as you progress this work.

Your Question 6:  We understand that GMPLS only supports the IP address
format, and that the actual addresses may be different in each layer.
We believe it would be useful to clarify the difference between
addresses used in regards to delivering messages to a control component,
and identifiers used for the forwarding plane resources themselves.

Our response: Please refer to RFC 4990. This draft does not modify
existing procedures. If you have any questions with regard to GMPLS
addressing, we welcome informal dialogue on the CCAMP exploder and, of
course, you may also ask via Liaison.

Your Question 7:  Thank you for the clarification which confirms that
the VCAT layer Call Controllers are assumed to be adjacent from a
control plane perspective.

Our response: Noted. To ensure that we understand your question on
"direct signalling connectivity" and "adjacent", to be precise, it is
assumed that the Call Controllers can exchange call control messages.
This does not require that they be adjacent.

Your Question 8:  Thank you for the clarification.

Our response: Noted.

Your Question 9:  Based upon your observation, we view that a protocol
independent definition of the call ID should be abstracted from
G.7713.2, where it is expressed in protocol specific terms; the most
appropriate Recommendation for this definition would be G.7713.

Our response: Thank you for the clarification.

Your Question 10:  Your interpretation of G.8080 is correct regarding
E-NNI reference points and adjacent call controllers.  There is no
reference to RSVP sessions in G.8080; it was used as an example of the
consequence of using different protocols in different domains.  It is
our understanding from the discussions that concatenated GMPLS RSVP-TE
connections (homogenous signaling protocol) that are part of the same
end-to-end network connection do not need to change the session object,
and policy could be applied at a transit (inter-domain) hop.  Please
confirm that our understanding is correct.

Our response: Your understanding is correct that even though one session
is used, policy may be applied by any processing node (manager) of the
call message, and RFC4974 supports multiple call managers along the path
between ingress and egress. Please refer to RFC 4974. Note, the RSVP
signaling protocol model allows for the application of local policy by
any processing node of the request (regardless if a connection or call).

The latest version of this work can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.
txt

We welcome any further comments.

Best regards,

Adrian Farrel and Deborah Brungard

IETF CCAMP working group co-chairs

Attachment(s): No document has been attached

=20

------_=_NextPart_001_01C85954.5B0F5017
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY><FONT face=3DArial>
<P><SPAN class=3D822315520-16012008><FONT=20
face=3D"Times New Roman">CCAMP,</FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT face=3D"Times New =
Roman">Here's a proposed=20
response to ITU's Liaison:</FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT face=3D"Times New Roman"><A=20
href=3D"https://datatracker.ietf.org/liaison/371/">https://datatracker.ie=
tf.org/liaison/371/</A></FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT face=3D"Times New Roman">Any=20
comments?</FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT=20
face=3D"Times New Roman">Thanks,</FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT face=3D"Times New =
Roman">Deborah and=20
Adrian</FONT></SPAN></P>
<P><SPAN class=3D822315520-16012008><FONT=20
face=3D"Times New Roman">=3D=3D=3D=3D</FONT></SPAN></P>
<P><FONT face=3D"Times New Roman">Title:&nbsp;<SPAN=20
class=3D822315520-16012008>Response to Liaison on GMPLS Signaling for=20
VCAT/LCAS</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman">Purpose: For&nbsp;<SPAN=20
class=3D822315520-16012008>Action</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman">Body:</FONT></P>
<P><SPAN class=3D822315520-16012008><FONT face=3D"Times New Roman">The =
CCAMP Working=20
Group thanks you for your liaison of September 2007 (Q12-14 Interim =
meeting - LS=20
005).</FONT></SPAN></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008>Here =
are our=20
responses to the questions in your liaison:</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =
lang=3DEN-GB=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
Question 1: </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">We=20
provide here further clarification regarding our previous comment re =
protocol=20
extensibility to encompass technologies other than SONET/SDH.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>An example technology of =
interest to the=20
community was provided regarding the usage of virtually concatenated =
ODUs for=20
carriage of IEEE 802.3 HSSG proposed 100 Gbit/s over an existing OTN=20
infrastructure.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>How this =
is=20
accomplished is not defined at this time and might not be using VCAT. A=20
technology neutral approach (i.e., one not dependent upon VCAT over=20
SONET/SDH-unique parameters) would avoid the need for developing a =
series of=20
specialized solutions.</SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN></FONT><FONT=20
face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt">Our =
response: As we=20
noted previously, it is certainly our intention that functionality and =
any=20
protocol extensions that we develop should be easily extensible to =
support other=20
than SONET/SDH technology, especially technologies covered by GMPLS =
(e.g. OTN).=20
This is the basis of GMPLS and GMPLS call functionality development. If =
you have=20
identified any specific concerns with the current approach, we would =
appreciate=20
your input.</SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">Your&nbsp;Question=20
2:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>VCAT group signaling =
relates=20
closely to multi-layer call modeling, and it is our understanding that =
the draft=20
is only addressing the constituent server layer call.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>We plan to perform =
further work to=20
clarify the interlayer call relationship in terms of the ASON multilayer =
&#8220;call=20
supporting call construct&#8221;.</SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: Noted. We look forward to further communication from=20
you.</SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
Question 3:<SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>We =
agree that=20
connections are not moved between calls; the ASON &#8220;call supporting =
calls&#8221;=20
construct is consistent with not moving connections between calls.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>Rec. G.7041 and G.7042 are =
only=20
concerned with membership of the VCAT group, and not with the use of a =
member=20
that has been removed (it is assumed to simply go back into the pool of=20
resources, where it can be drawn upon for other purposes).<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>Thus G.7041 and G.7042 do not =
support=20
the direct movement of a connection from one VCAT group to another. =
Changing the=20
association of a server layer call/connection to a VCAT group does not=20
necessarily result in removal/deletion of that=20
call/connection.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: Noted.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">Your&nbsp;Question=20
4:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>We appreciate your =
clarification=20
of the use of a single call. However we suggest that you do not preclude =

extension to use multiple calls. This is useful for example in diverse =
routing=20
applications.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>=

<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">As=20
noted in our previous liaison, the call construct as proposed in this =
draft is=20
used to coordinate the (single type) server layer connections for the =
VCAT=20
functionality. This does not preclude use of RFC 4974 in support of =
G.8080 call=20
functionality. To ensure that we understand correctly your request, can =
you=20
provide additional information regarding using multiple calls in support =
of=20
diverse routing=20
applications?</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FO=
NT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">Your&nbsp;Question=20
5:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>We understand that =
this draft is=20
only addressing the constituent server layer call; i.e., not the ASON =
multilayer=20
call supporting call construct. However, we suggest that you do not =
preclude=20
extensions to use a call in the VCAT=20
layer.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FO=
NT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: As noted above, this is not precluded. We look forward to =
future=20
communication from you as you progress this=20
work.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FON=
T></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA">Your&nbsp;Question=20
6:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>We understand that =
GMPLS only=20
supports the IP address format, and that the actual addresses may be =
different=20
in each layer.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>We believe =
it would=20
be useful to clarify the difference between addresses used in regards to =

delivering messages to a control component, and identifiers used for the =

forwarding plane resources=20
themselves.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN=
></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Please=20
refer to RFC 4990. This draft does not modify existing procedures. If =
you have=20
any questions with regard to GMPLS addressing, we welcome informal =
dialogue on=20
the CCAMP exploder and, of course, you may also ask via=20
Liaison.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></=
SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Question=20
7:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Thank you for the =
clarification=20
which confirms that the VCAT layer Call Controllers are assumed to be =
adjacent=20
from a control plane=20
perspective.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPA=
N></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: Noted. To ensure that we understand your question on "direct=20
signalling connectivity" and "adjacent", to be precise, it is assumed =
that the=20
Call Controllers can exchange call control messages. This does not =
require that=20
they be=20
adjacent.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN><=
/SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Question=20
8:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Thank you for the=20
clarification.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></S=
PAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response:=20
Noted.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SP=
AN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Question=20
9:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Based upon your =
observation, we=20
view that a protocol independent definition of the call ID should be =
abstracted=20
from G.7713.2, where it is expressed in protocol specific terms; the =
most=20
appropriate Recommendation for this definition would be=20
G.7713.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></S=
PAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: Thank you for the=20
clarification.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></S=
PAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
<SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Question=20
10:<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Your interpretation =
of G.8080=20
is correct regarding E-NNI reference points and adjacent call =
controllers.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>There is no reference to RSVP =
sessions=20
in G.8080; it was used as an example of the consequence of using =
different=20
protocols in different domains.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>It=20
is our understanding from the discussions that concatenated GMPLS =
RSVP-TE=20
connections (homogenous signaling protocol) that are part of the same =
end-to-end=20
network connection do not need to change the session object, and policy =
could be=20
applied at a transit (inter-domain) hop. <SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Please confirm that our =
understanding is=20
correct.</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></=
SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Our=20
response: <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Your=20
understanding is correct that even though one session is used, policy =
may be=20
applied by any&nbsp;processing node (manager)&nbsp;of the call message, =
and=20
RFC4974 supports multiple call managers along the path between ingress =
and=20
egress. Please refer to RFC 4974. Note, the RSVP signaling protocol =
model allows=20
for the application of local policy by any processing node&nbsp;of the=20
request&nbsp;(regardless if a connection or=20
call).</SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SP=
AN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><SPAN =

style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-ansi-language: EN-US; mso-bidi-font-size: 12.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
AR-SA"></SPAN></SPAN></SPAN></SPAN></SPAN></FONT><FONT=20
face=3D"Times New Roman"><SPAN class=3D822315520-16012008>The latest =
version of this=20
work can be found at:</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-l=
cas-03.txt">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vc=
at-lcas-03.txt</A></SPAN></FONT></P>
<P><FONT face=3D"Times New Roman"><SPAN class=3D822315520-16012008>We =
welcome any=20
further comments.</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman">Best regards,</FONT></P>
<P><FONT face=3D"Times New Roman">Adrian Farrel<SPAN =
class=3D822315520-16012008> and=20
Deborah Brungard</SPAN></FONT></P>
<P><FONT face=3D"Times New Roman">IETF&nbsp;<SPAN =
class=3D822315520-16012008>CCAMP=20
</SPAN>working group co-chairs</FONT></P>
<P><FONT face=3D"Times New Roman">Attachment(s):<SPAN =
class=3D822315520-16012008>=20
</SPAN>No document has been attached</FONT></P>
<P><FONT face=3D"Times New Roman" =
size=3D2></FONT>&nbsp;</P></FONT></BODY></HTML>

------_=_NextPart_001_01C85954.5B0F5017--

Envelope-to: [email-masked]
Delivery-date: Thu, 17 Jan 2008 19:32:09 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>
Subject: Document Action: 'Interworking Requirements to Support  operation of MPLS-TE over GMPLS Networks' to Informational RFC 
Message-Id: <[email-masked]>
Date: Thu, 17 Jan 2008 14:30:41 -0500

The IESG has approved the following document:

- 'Interworking Requirements to Support operation of MPLS-TE over GMPLS 
   Networks '
   <draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt

Technical Summary
 
   This informational document describes Service Provider requirements
   for operating MPLS-TE networks over GMPLS networks.
 
Working Group Summary
 
   No dissent reported (see PROTO writeup by Adrian Farrel). 
 
Protocol Quality
 
   Ross Callon has reviewed this document for the IESG, and it has been
   updated based on my (mostly minor clarifying) comments.

Delivery-date: Thu, 17 Jan 2008 17:18:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward with VCAT/LCAS...
Date: Thu, 17 Jan 2008 12:17:59 -0500
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

Alex, I assume that the "one step" case below is simply an optimization
of the "loose coupling + policy" approach.  That is, the policy is to
teardown the server when the client no longer needs it.  I think it
would be a mistake to define this behaviour in a protocol without the
ability to control whether the server layer is torn down when its
association with the client layer is removed.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alex Conta
Sent: January 14, 2008 14:47
To: [email-masked]
Subject: RE: Moving forward with VCAT/LCAS...

Greg,
=20
>From the perspective of the "users" of a VCG - applications or clients
of the VCG  which are the layers above the VCG (above both VCG client
and server). -  the awareness, the information about the VCG members,
and furthermore, their presence before, or after VCG creation or tear
down, does not really seem relevant, or directly useful.=20
=20
>From a "management/provisioning" perspective, setting up the components,
independently from the client layer - as a first setup step - and then
converting/transforming these elements into VCG members, once a VCG
group (and client) has been set up - as a second setup step - and then
at tear down, after VCGs tear down, keeping the server elements around,
seem to be reducing the number of subsequent setup operations, if those
elements can be and are reused with subsequent newly created VCGs.
=20
It can be argued though, that in a case - a VCG application - in which
existing server elements CANNOT  be reused, a one step creation or
tearing down of VCGs - in which client and server elements are
created/setup, or torn down together, instead of a two step, and keeping
server layer elements around - is more appropriate.=20
=20
So the preferred "default" behavior may depend on the type of VCG
applications, and could be best left as a choice for the system
developer to make.=20
=20
Regards,
Alex Conta
=20

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]]
Sent: Friday, January 11, 2008 11:03 AM
To: Alex Conta
Subject: Re: Moving forward with VCAT/LCAS...

Nice analysis/summary Alex.  I like the "looser coupling" + policy
(default behavior) approach that you put forward.
Let me know if you've got solution preferences (on or off the list).

Regards

Greg B.
<snip>

Delivery-date: Thu, 17 Jan 2008 17:13:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward with VCAT/LCAS...
Date: Thu, 17 Jan 2008 12:08:15 -0500
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

Sorry about the delay in responding, I don't check this list daily.

A connection can't exist outside of a call.  However, if you mean can a
server call (with associated connection) exist outside of a client (in
this case VCAT) call, the answer is yes.  The model I'm responding from
assumes that a VCAT call contains only one VCG, and that it has a
relationship with one or more server layer calls where those server
layer calls contain a connection or connections.  It's a more general
model for inverse mux. The server layer call could exist ahead of time,
and then be allocated to a client call.

The client could also disassociate itself from a server layer call and
it is an independent decision as to whether that server layer call then
releases its connection(s) and terminates.  If it stays up, it could be
associated with a different client call at a later time.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: January 10, 2008 21:34
To: [email-masked]
Subject: Re: Moving forward with VCAT/LCAS...

Stephen,

In this architecture, can a connection exist outside a call and then be
designated as a connection that fulfils the service identified by the
call?

Thanks,
Adrian
----- Original Message -----
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 10, 2008 3:04 PM
Subject: RE: Moving forward with VCAT/LCAS...

Greg, I support these requirements.  In transport architecture, layers
are separated and this allows a business separation of service.  The
relationship between the client layer (VCAT in this case) and server
layer should be policy driven.  That is, the setup/teardown of server
layer LSPs in response to client layer requests, should not be
automatically coded in a protocol/implementation, but be subject to a
policy decision.

An additional requirement that's similar to (a), would be to be able to
use an existing LSP in response to a VCAT setup.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: January 8, 2008 12:28
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft
was discussed and there seemed to be two possible additions to the
requirements section of the draft. From the slide presentation these
were:

(a) Be able to set up member LSPs (and data plane LSPs -- server
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist after a VCG
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these
additional requirements? This is a WG draft so polling of the list is
required (right Adrian?). I'll clean up the language if there is a
desire to add these to the current draft. Note that these requirements
may break or require rework of the current "multiple co-signaled member
sets" solution in the draft.

Regards

Greg B.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Envelope-to: [email-masked]
Delivery-date: Tue, 15 Jan 2008 02:35:45 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>
Subject: Document Action: 'Framework for MPLS-TE to GMPLS  migration' to Informational RFC 
Message-Id: <[email-masked]>
Date: Mon, 14 Jan 2008 21:32:55 -0500

The IESG has approved the following document:

- 'Framework for MPLS-TE to GMPLS migration '
   <draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt> as an Informational RFC

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt

Technical Summary
 
    This informational framework document presents several migration 
    models and strategies for migrating from MPLS-TE to GMPLS. This 
    document provides a migration toolkit to aid the operator in
    selection of an appropriate strategy. This framework document 
    also lists a set of solutions that may aid in interworking, and
    highlights a set of potential issues.

Working Group Summary
 
    No dissent reported (see PROTO writeup by Adrian Farrel)
 
Protocol Quality
 
    Ross Callon has reviewed this for the IESG. As this informational 
    document just describes possibilities for migration, it is not
    implemented per se.

Delivery-date: Mon, 14 Jan 2008 19:49:22 +0000
Date: Mon, 14 Jan 2008 14:47:26 -0500
From: Alex Conta <[email-masked]>
Subject: RE: Moving forward with VCAT/LCAS...
To: [email-masked]

Greg,
 
>From the perspective of the "users" of a VCG - applications or clients
of the VCG  which are the layers above the VCG (above both VCG client
and server). -  the awareness, the information about the VCG members,
and furthermore, their presence before, or after VCG creation or tear
down, does not really seem relevant, or directly useful. 
 
>From a "management/provisioning" perspective, setting up the components,
independently from the client layer - as a first setup step - and then
converting/transforming these elements into VCG members, once a VCG
group (and client) has been set up - as a second setup step - and then
at tear down, after VCGs tear down, keeping the server elements around,
seem to be reducing the number of subsequent setup operations, if those
elements can be and are reused with subsequent newly created VCGs.
 
It can be argued though, that in a case - a VCG application - in which
existing server elements CANNOT  be reused, a one step creation or
tearing down of VCGs - in which client and server elements are
created/setup, or torn down together, instead of a two step, and keeping
server layer elements around - is more appropriate. 
 
So the preferred "default" behavior may depend on the type of VCG
applications, and could be best left as a choice for the system
developer to make. 
 
Regards,
Alex Conta

-----Original Message-----
From: Greg Bernstein [mailto:[email-masked]] 
Sent: Friday, January 11, 2008 11:03 AM
To: Alex Conta
Subject: Re: Moving forward with VCAT/LCAS...

Nice analysis/summary Alex.  I like the "looser coupling" + policy
(default behavior) approach that you put forward.
Let me know if you've got solution preferences (on or off the list).

Regards

Greg B.

Alex Conta wrote: 
Supporting the two requirements makes sense.

A VCG member (server) has some basic functionality that is similar to
non-VCG members, and the mechanisms to setup that functionality is
usually similar/same (for instance, setting up the DS3 functionality of
the DS3 members of a VCG is similar to setting up non-VCG DS3s.) 

Transforming a non-VCG member into a VCG member, and vice-versa, a VCG
member into a non-VCG member, is just a matter of additional setup - VCG
setup (through management, control plane, policy driver, etc...)

An implication of the support of these two requirements seems to be a
choice of behavior of the implementation of the VCG tear down functions.

1. provide the function of terminating all functions and tearing down
all VCG members (servers) at the time of tearing down their VCG
(client).

2. provide the function of terminating only the "VCG member" functions,
transforming VCG members into non-VCG members, and thus have the non-VCG
functionality of the server layer entities survive the tear down of the
VCG (client).

An implementation may have a choice of "default behavior", which could
be mentioned in the draft. 

Regards,
Alex Conta

-----Original Message-----
From: [email-masked] 
[mailto:[email-masked]] On Behalf Of Greg Bernstein
Sent: Tuesday, January 08, 2008 12:28 PM
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the 
VCAT/LCAS draft 
was discussed and there seemed to be two possible additions to the 
requirements section of the draft. From the slide 
presentation these were:

(a) Be able to set up member LSPs (and data plane LSPs -- server 
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist 
after a VCG 
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these 
additional requirements? This is a WG draft so polling of the list is 
required (right Adrian?). I'll clean up the language if there is a 
desire to add these to the current draft. Note that these 
requirements 
may break or require rework of the current "multiple 
co-signaled member 
sets" solution in the draft.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Mon, 14 Jan 2008 16:16:42 +0000
Date: Mon, 14 Jan 2008 11:14:26 -0500
From: Alex Conta <[email-masked]>
Subject: RE: Moving forward with VCAT/LCAS...
To: [email-masked]

Supporting the two requirements makes sense.

A VCG member (server) has some basic functionality that is similar to
non-VCG members, and the mechanisms to setup that functionality is
usually similar/same (for instance, setting up the DS3 functionality of
the DS3 members of a VCG is similar to setting up non-VCG DS3s.) 

Transforming a non-VCG member into a VCG member, and vice-versa, a VCG
member into a non-VCG member, is just a matter of additional setup - VCG
setup (through management, control plane, policy driver, etc...)

An implication of the support of these two requirements seems to be a
choice of behavior of the implementation of the VCG tear down functions.

1. provide the function of terminating all functions and tearing down
all VCG members (servers) at the time of tearing down their VCG
(client).

2. provide the function of terminating only the "VCG member" functions,
transforming VCG members into non-VCG members, and thus have the non-VCG
functionality of the server layer entities survive the tear down of the
VCG (client).

An implementation may have a choice of "default behavior", which could
be mentioned in the draft. 

Regards,
Alex Conta

Delivery-date: Sun, 13 Jan 2008 17:19:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, "Ronald Bonica" <[email-masked]>, "Kenji Kumaki" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: draft-ietf-ccamp-mpls-gmpls-interwork-reqts revised after IESG review
Date: Sun, 13 Jan 2008 17:17:41 -0000

The new revision of this I-D is to address comments made during IESG review 
as below.

Thanks,
Adrian

===
Section 3
New paragraph at end of section
ADD
   The functional requirements for GMPLS-MPLS interworking described in
   this section must be met by any device participating in the
   interworking. This may include routers, servers, network management
   devices, path computation elements, etc.
===
Section 3.2
New paragraphs at end of section
ADD
   Note that multiple GMPLS LSPs may be set up between a given pair of
   Border Routers in support of connectivity in the MPLS client network.
   If these LSPs are advertised as TE links in the client network, the
   use of link bundling [RFC4201] can reduce any scaling concerns
   associated with the advertisements.

   The application of the Path Computation Element (PCE) [RFC4655] in
   the context of an inter-layer network [PCE-INTER-LAYER] may be
   considered to determine an end-to-end LSP with triggered GMPLS
   segment or tunnel.
===
Section 3.5
New paragraph at end of section
ADD
   The use of PCE [RFC4655] may provide a solution for non-PSC GMPLS
   networks supporting PSC MPLS networks.
===
Section 8.1
ADD
   [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
             MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
===
Section 8.2
ADD
   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

Delivery-date: Sun, 13 Jan 2008 16:12:52 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt 
Date: Sun, 13 Jan 2008 11:10:01 -0500

--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           : Interworking Requirements to Support operation of MPLS-TE over GMPLS Networks
	Author(s)       : K. Kumaki, et al.
	Filename        : draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt
	Pages           : 13
	Date            : 2008-01-13

Operation of a Multiprotocol Label Switching (MPLS) traffic
engineering (TE) network as a client network to a Generalized MPLS
(GMPLS) network has enhanced operational capabilities compared to
those provided by a co-existent protocol model (i.e., operation of
MPLS-TE over an independently managed transport layer).

The GMPLS network may be a packet or a non-packet network, and may
itself be a multi-layer network supporting both packet and non-packet
technologies. A MPLS-TE Label Switched Path (LSP) originates and
terminates on an MPLS Label Switching Router (LSR). The GMPLS network
provides transparent transport for the end-to-end MPLS-TE LSP.

This document describes a framework and Service Provider requirements
for operating MPLS-TE networks over GMPLS networks.

K.Kumaki et al.

 [page 1]

draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04
  January 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-mpls-gmpls-interwork-reqts-04.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-mpls-gmpls-interwork-reqts-04.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-mpls-gmpls-interwork-reqts-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-gmpls-interwork-reqts-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-01-13110353.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Delivery-date: Sun, 13 Jan 2008 11:26:27 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Kohei Shiomoto" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Subject: draft-ietf-ccamp-mpls-gmple-framework updated after IESG review
Date: Sun, 13 Jan 2008 11:25:43 -0000

Hi,

Changes are below (as approved by the IESG).

Thanks,
Adrian

==
Section 4.3
Replace final paragraph
OLD
   Interoperability concerns, though, are exacerbated by this migration
   model, unless all LSRs in the network are updated simultaneously and
   there is a clear understanding of which subset of features are to be
   included in the hybrid LSRs. Interworking between a hybrid LSR and an
   unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
   LSR as described in the previous sections and puts the unchanged LSR
   in the role of an MPLS LSR. The potential for different hybrids
   within the network will complicate matters considerably.
NEW
   Interoperability concerns though are exacerbated by this migration
   model, unless all LSRs in the network are updated simultaneously and
   there is a clear understanding of which subset of features are to be
   included in the hybrid LSRs. Interworking between a hybrid LSR and an
   unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS
   LSR as described in the previous sections and puts the unchanged LSR
   in the role of an MPLS LSR. The potential for different hybrids
   within the network will complicate matters considerably. This model 
   is, therefore, only appropriate for use when the set of new features
   to be deployed is well known and limited, and where there is a clear
   understanding of and agreement on this set of features by the network
   operators of the ISP(s) involved as well as all vendors whose 
   equipment will be involved in the migration.
===
Section 5
Update 4th paragraph
OLD
   The second strategy for PSC and non-PSC networks is to migrate from
   the PSC network to GMPLS, first, and then enable GMPLS within the
   non-PSC network. The PSC network is migrated as described before, and
   when the entire PSC network is completely converted to GMPLS, GMPLS-
   based non-PSC devices and networks may be introduced without any
   issues of interworking between MPLS and GMPLS.
NEW
   The second strategy is to migrate the PSC network to GMPLS first, and
   then enable GMPLS within the non-PSC network. The PSC network is 
   migrated as described before, and when the entire PSC network is 
   completely converted to GMPLS, GMPLS-based non-PSC devices and 
   networks may be introduced without any issues of interworking between
   MPLS and GMPLS.
===
Section 5.1.4
New section
ADD
5.1.4. Path Computation Element

   The Path Computation Element (PCE) [RFC4655] may provide an 
   additional tool to aid MPLS to GMPLS migration. If a layered network
   approach (Section 5.1.1) is used, PCEs may be used to facilitate the
   computation of paths for LSPs in the different layers 
   [PCE-INTER-LAYER].
===
Section 12.2
Add new references
ADD
   [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation
             Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [PCE-INTER-LAYER] Oki, E., Le Roux , J-L,. and Farrel, A., "Framework
             for PCE-Based Inter-Layer MPLS and GMPLS Traffic
             Engineering," draft-ietf-pce-inter-layer-frwk, work in  
             progress.
===

Delivery-date: Sun, 13 Jan 2008 11:23:29 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt 
Date: Sun, 13 Jan 2008 06:20:02 -0500

--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           : Framework for MPLS-TE to GMPLS migration
	Author(s)       : K. Shiomoto, et al.
	Filename        : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt
	Pages           : 19
	Date            : 2008-01-13

The migration from Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) to Generalized MPLS (GMPLS) is the process of
evolving an MPLS-TE control plane to a GMPLS control plane. An
appropriate migration strategy will be selected based on various
factors including the service provider's network deployment plan,
customer demand, and operational policy.

This document presents several migration models and strategies for
migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE
and GMPLS devices, or networks, may coexist which may require
interworking between MPLS-TE and GMPLS protocols. Aspects of the
interworking required are discussed as it will influence the choice
of a migration strategy. This framework document provides a migration
toolkit to aid the operator in selection of an appropriate strategy.

This framework document also lists a set of solutions that may aid in
interworking, and highlights a set of potential issues.

 Shiomoto et al.

[page 1]

 draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05

  January 2008

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-mpls-gmpls-interwork-fmwk-05.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-mpls-gmpls-interwork-fmwk-05.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-mpls-gmpls-interwork-fmwk-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2008-01-13061248.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 11 Jan 2008 02:35:31 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Moving forward with VCAT/LCAS...
Date: Fri, 11 Jan 2008 02:33:39 -0000

Stephen,

In this architecture, can a connection exist outside a call and then be 
designated as a connection that fulfils the service identified by the call?

Thanks,
Adrian
----- Original Message ----- 
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 10, 2008 3:04 PM
Subject: RE: Moving forward with VCAT/LCAS...

Greg, I support these requirements.  In transport architecture, layers
are separated and this allows a business separation of service.  The
relationship between the client layer (VCAT in this case) and server
layer should be policy driven.  That is, the setup/teardown of server
layer LSPs in response to client layer requests, should not be
automatically coded in a protocol/implementation, but be subject to a
policy decision.

An additional requirement that's similar to (a), would be to be able to
use an existing LSP in response to a VCAT setup.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: January 8, 2008 12:28
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft
was discussed and there seemed to be two possible additions to the
requirements section of the draft. From the slide presentation these
were:

(a) Be able to set up member LSPs (and data plane LSPs -- server
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist after a VCG
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these
additional requirements? This is a WG draft so polling of the list is
required (right Adrian?). I'll clean up the language if there is a
desire to add these to the current draft. Note that these requirements
may break or require rework of the current "multiple co-signaled member
sets" solution in the draft.

Regards

Greg B.

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 10 Jan 2008 17:22:43 +0000
Date: Thu, 10 Jan 2008 09:21:30 -0800
From: Greg Bernstein <[email-masked]>
To: Huub van Helvoort <[email-masked]>
CC: [email-masked]
Subject: Re: Moving forward with VCAT/LCAS...

Hi Huub, I think you hit the crux of the issue.  We (well I) outlined a 
possible solution to a particular "member sharing" scenario in the 
draft. Whether that is the right scenario and solution seems to be the 
discussion.  See below for more comments.

Cheers
Greg B.

Huub van Helvoort wrote:
> Hello Greg,
>
> You wrote:
>
>> Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS
>> draft was discussed and there seemed to be two possible additions to
>> the requirements section of the draft. From the slide presentation
>> these were:
>>
>> (a) Be able to set up member LSPs (and data plane LSPs -- server 
>> connections) prior to creation of VCG (Virtual Concatenation Group).
>
> If there are more such members would they have a relation with
> each other? e.g. a "pool" of member LSPs for a single VCG or for
> multiple VCGs that exist between the same end-points.
--> The solution that we (okay I'll take the blame) outlined in the 
draft assumes that we know ahead of time that we are going to do such a 
thing and we setup a "call" that can contain multiple VCGs and then can 
throw all the "pool LSPs" into that call to be shared amongst the 
different VCGs under control of a modified Notify message (we didn't 
furnish details, just sketched how this could be done if someone really 
wanted to do this...)  Some folks find the notion of multiple VCGs per 
call somewhat objectionable...
>
>> (b) Member LSPs (data plane and control plane) can exist after a
>> VCG using them has been removed.
>
> Will they be returned to the "pool" (if the previous answer is yes).
--> I don't know.  I guess that they could be used for other things.  In 
the member sharing case that we (okay I) outlined in the draft they 
could be either returned to the pool or torn down (i.e. the pool size 
could change).
>
>> For those interested in VCAT/LCAS what is your opinion on these 
>> additional requirements? This is a WG draft so polling of the list is
>>  required (right Adrian?). I'll clean up the language if there is a 
>> desire to add these to the current draft. Note that these
>> requirements may break or require rework of the current "multiple
>> co-signaled member sets" solution in the draft.
>
> Cheers, Huub.
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 10 Jan 2008 16:57:54 +0000
Date: Thu, 10 Jan 2008 17:56:12 +0100
From: Huub van Helvoort <[email-masked]>
To: Greg Bernstein <[email-masked]>
CC: [email-masked]
Subject: Re: Moving forward with VCAT/LCAS...

Hello Greg,

You wrote:

> Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS
> draft was discussed and there seemed to be two possible additions to
> the requirements section of the draft. From the slide presentation
> these were:
> 
> (a) Be able to set up member LSPs (and data plane LSPs -- server 
> connections) prior to creation of VCG (Virtual Concatenation Group).

If there are more such members would they have a relation with
each other? e.g. a "pool" of member LSPs for a single VCG or for
multiple VCGs that exist between the same end-points.

> (b) Member LSPs (data plane and control plane) can exist after a
> VCG using them has been removed.

Will they be returned to the "pool" (if the previous answer is yes).

> For those interested in VCAT/LCAS what is your opinion on these 
> additional requirements? This is a WG draft so polling of the list is
>  required (right Adrian?). I'll clean up the language if there is a 
> desire to add these to the current draft. Note that these
> requirements may break or require rework of the current "multiple
> co-signaled member sets" solution in the draft.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

Delivery-date: Thu, 10 Jan 2008 15:06:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward with VCAT/LCAS...
Date: Thu, 10 Jan 2008 10:04:55 -0500
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>

Greg, I support these requirements.  In transport architecture, layers
are separated and this allows a business separation of service.  The
relationship between the client layer (VCAT in this case) and server
layer should be policy driven.  That is, the setup/teardown of server
layer LSPs in response to client layer requests, should not be
automatically coded in a protocol/implementation, but be subject to a
policy decision.

An additional requirement that's similar to (a), would be to be able to
use an existing LSP in response to a VCAT setup.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: January 8, 2008 12:28
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft
was discussed and there seemed to be two possible additions to the
requirements section of the draft. From the slide presentation these
were:

(a) Be able to set up member LSPs (and data plane LSPs -- server
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist after a VCG
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these
additional requirements? This is a WG draft so polling of the list is
required (right Adrian?). I'll clean up the language if there is a
desire to add these to the current draft. Note that these requirements
may break or require rework of the current "multiple co-signaled member
sets" solution in the draft.

Regards

Greg B.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Thu, 10 Jan 2008 11:17:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>, <[email-masked]>, "Scott Bradner" <[email-masked]>
Subject: Draft liaison response to ITU-T on T-MPLS ring protection
Date: Thu, 10 Jan 2008 11:14:56 -0000

Hi,

Here is a brief draft response to the ITU-T's liaison that you can see at 
https://datatracker.ietf.org/documents/LIAISON/file502.pdf

Any comments?

Thanks,
Adrian

===

To: ITU-T Q9/15
Cc: Steven Trowbridge, Ghani Abbas, Ross Callon, Dave Ward, Scott Bradner, 
CCAMP Mailing List
From: IETF CCAMP Working Group
Subject: Response to Your Liaison on T-MPLS Ring Protection
In Response

Dear Ghani,

Thank you for your liaison from your Madeira interim meeting on T-MPLS Ring 
Protection, and for taking the time to keep us informed.

At the moment, it appears that your work is limited to the MPLS forwarding 
plane with control from the Management Plane with coordination with MPLS 
OAM. As such, this work falls within the remit of the IETF's MPLS and PWE3 
working groups. You will also be aware that the IAB has set up a design team 
to address issues in preparation of the potential cooperation between IETF 
and ITU-T on T-MPLS; we trust that you have appropriately consulted this 
team in keeping with the spirit of cooperation between the ITU-T and the 
IETF.

At such time as your work on T-MPLS ring protection (or indeed on any aspect 
of T-MPLS) extends to requirements or solutions for a control plane, we 
request that you communicate with us early in the process so that we may 
ensure that the industry arrives at a single and fully compatible solution.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP Working Group Co-Chairs 

Delivery-date: Thu, 10 Jan 2008 09:31:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward with VCAT/LCAS...
Date: Thu, 10 Jan 2008 10:28:24 +0100
From: "Diego Caviglia" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>

Hi Greg,
        I think are good requirements and should be included on the ID =
may be not as mandatory requirements.

BR

Diego

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On =
Behalf
> Of Greg Bernstein
> Sent: marted=EC 8 gennaio 2008 18.28
> To: [email-masked]
> Subject: Moving forward with VCAT/LCAS...
>=20
> Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS =
draft
> was discussed and there seemed to be two possible additions to the
> requirements section of the draft. From the slide presentation these =
were:
>=20
> (a) Be able to set up member LSPs (and data plane LSPs -- server
> connections) prior to creation of VCG (Virtual Concatenation Group).
> (b) "Member" LSPs (data plane and control plane) can exist after a VCG
> using them has been removed.
>=20
> For those interested in VCAT/LCAS what is your opinion on these
> additional requirements? This is a WG draft so polling of the list is
> required (right Adrian?). I'll clean up the language if there is a
> desire to add these to the current draft. Note that these requirements
> may break or require rework of the current "multiple co-signaled =
member
> sets" solution in the draft.
>=20
> Regards
>=20
> Greg B.
>=20
> --
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>=20
>=20

Delivery-date: Tue, 08 Jan 2008 19:24:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Moving forward with VCAT/LCAS...
Date: Tue, 8 Jan 2008 14:23:17 -0500
From: "Ong, Lyndon" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>

Hi Greg,

As you might expect, I support adding these as requirements for the
VCAT/LCAS
work.

Cheers,

Lyndon=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: Tuesday, January 08, 2008 9:28 AM
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft
was discussed and there seemed to be two possible additions to the
requirements section of the draft. From the slide presentation these
were:

(a) Be able to set up member LSPs (and data plane LSPs -- server
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist after a VCG
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these
additional requirements? This is a WG draft so polling of the list is
required (right Adrian?). I'll clean up the language if there is a
desire to add these to the current draft. Note that these requirements
may break or require rework of the current "multiple co-signaled member
sets" solution in the draft.

Regards

Greg B.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Tue, 08 Jan 2008 17:29:58 +0000
Date: Tue, 08 Jan 2008 09:27:59 -0800
From: Greg Bernstein <[email-masked]>
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft 
was discussed and there seemed to be two possible additions to the 
requirements section of the draft. From the slide presentation these were:

(a) Be able to set up member LSPs (and data plane LSPs -- server 
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) Member LSPs (data plane and control plane) can exist after a VCG 
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these 
additional requirements? This is a WG draft so polling of the list is 
required (right Adrian?). I'll clean up the language if there is a 
desire to add these to the current draft. Note that these requirements 
may break or require rework of the current "multiple co-signaled member 
sets" solution in the draft.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

Delivery-date: Mon, 07 Jan 2008 15:48:35 +0000
Date: Mon, 07 Jan 2008 10:45:16 -0500
Subject: Re: ccamp minutes
From: JP Vasseur <[email-masked]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>, <[email-masked]>

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

--B_3282547517_729358
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi,

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 31 Dec 2007 14:54:07 -0500
To: <[email-masked]>
Conversation: ccamp minutes
Subject: RE: ccamp minutes

Try this version - there were an excessive number of typos introduced in the
other uploaded version:
http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt
 
And thanks to our note takers - Dimitri, Martin, and Dan!

From: [email-masked] [mailto:[email-masked]] On Behalf
Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Monday, December 31, 2007 1:41 PM
To: [email-masked]
Subject: ccamp minutes

Hi CCAMP,
 
The minutes have been uploaded:
http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm
 
Let us know if any changes/additions.
 
Happy 2008!
Adrian and Deborah

--B_3282547517_729358
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: ccamp minutes</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Hi,<B=
R>
<BR>
<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>&quot;BRUNGARD, DEBORAH =
A, ATTLABS&quot; &lt;[email-masked]&gt;<BR>
<B>Date: </B>Mon, 31 Dec 2007 14:54:07 -0500<BR>
<B>To: </B>&lt;[email-masked]&gt;<BR>
<B>Conversation: </B>ccamp minutes<BR>
<B>Subject: </B>RE: ccamp minutes<BR>
<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12.0px'><FONT COLOR=3D"#0000FF"><FONT FA=
CE=3D"Arial">Try this version - there were an excessive number of typos introd=
uced in the other uploaded version:<BR>
<a href=3D"http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt">http://w=
ww3.ietf.org/proceedings/07dec/minutes/ccamp.txt</a><BR>
</FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">And thanks to our note take=
rs - Dimitri, Martin, and Dan!<BR>
</FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"></FONT><FONT FACE=3D"Tahoma"><B>From:<=
/B> [email-masked] [<a href=3D"mailto:[email-masked]]">mai=
lto:[email-masked]]</a> <B>On Behalf Of </B>BRUNGARD, DEBORAH A, A=
TTLABS<BR>
<B>Sent:</B> Monday, December 31, 2007 1:41 PM<BR>
<B>To:</B> [email-masked]<BR>
<B>Subject:</B> ccamp minutes<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><BR>
</FONT><FONT FACE=3D"Arial">Hi CCAMP,<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE=3D"Arial">The minutes have been uploaded:<BR>
<a href=3D"http://www3.ietf.org/proceedings/07dec/minutes/ccamp.htm">http://w=
ww3.ietf.org/proceedings/07dec/minutes/ccamp.htm</a><BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE=3D"Arial">Let us know if any changes/additions.<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
</FONT><FONT FACE=3D"Arial">Happy 2008!<BR>
Adrian and Deborah<BR>
</FONT><FONT FACE=3D"Verdana, Helvetica, Arial"> <BR>
<BR>
</FONT></SPAN>
</BODY>
</HTML>

--B_3282547517_729358--

Delivery-date: Thu, 03 Jan 2008 11:34:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Ross Callon" <[email-masked]>, <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, <[email-masked]>
Subject: Response to Your Questions about GMPLS Protocol Usage
Date: Thu, 3 Jan 2008 11:33:44 -0000

Dear Lyndon,

Thanks for your communication dated 29th November 2007 and your subsequent
email exchange with clarifications.

Please find below responses from CCAMP experts to the questions you posed.

May we take this opportunity to stress that we are open to receiving such
questions in a less formal way either directly or through the CCAMP mailing
list, and may be able to provide timely responses during the course of your
testing events.

> 1) One of the features provided in the OIF UNI 2.0 is the ability to
> non-disruptively modify service attributes associated with an LSP. The
> modification of the service attributes is limited to LSPs that were
> initiated using Shared Explicit filter style. Modification is performed
> by signaling a new LSP that utilizes the same Tunnel ID as the original
> LSP but with the new service parameters. Once the new LSP state is
> established, the original LSP state is removed.

 There are two distinct options for modifying an LSP. The first is
"in-place" modification where a new trigger Path message is sent for an
existing LSP. The second is the "make-before-break" approach to
tunnel/service modification first introduced in RFC 3209. You appear to be
referring to the latter case since you mention a new LSP.

> Non-disruptive modification was demonstrated in the 2007
> interoperability test by modifying the bandwidth of an LSP realized by a
> SONET/SDH VCAT group. In the process of testing, a number of questions
> arose regarding the RESV message flow. These questions included:
>
> - How many RESV messages are expected to be generated? Is it one since
>   the resources in use by both LSPs are the same, or two since the LSPs
>   are handled through separate signaling sessions.

 In make-before-break, each LSP is signaled independently.  Per LSP Resv
messages should be expected.  Assuming the old LSP is in-place at the time
of signaling the new LSP, and only one Path message is issued, then only one
Resv would be expected. That is, a Resv for the new LSP, but no further Resv
for the existing LSP.

When the old LSP is also modified as part of the make-before-break, e.g., to
update administrative status prior to alarm-free tear-down, then a Resv
message on the old LSP may also be generated.

> - What is the bandwidth amount that should be reflected in the RESV
>   messages? If separate RESV messages are generated for both LSPs, is it
>   the bandwidth requested in the corresponding PATH message? Or is it
>   the actual bandwidth being provided by the connection at the time the
>   RESV message is generated?

 According to RFC 4606:

    For a particular sender in a session, the contents of the FLOWSPEC
    object received in a Resv message SHOULD be identical to the contents
    of the SENDER_TSPEC object received in the corresponding Path
    message.  If the objects do not match, a ResvErr message with a
    "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.

 Again, in make-before-break, each LSP is signaled independently.

> In the interop test both approaches were observed. To facilitate the
> subsequent demonstration, receivers were expected to handle both cases.
>
> 2) In the process of testing, we found that not all implementations
> included Explicit Route Objects (ERO) in PATH messages when performing
> graceful deletion, even though earlier PATH messages for the LSP had
> included an ERO. For some intermediate node implementations, the lack of
> the ERO was seen as removing the 'pinned' nature of the connection,
> causing the node to interpret the PATH message as requiring a new path
> computation which may end up using a different route. Other
> implementations utilized the Session and Sender Template to relate the
> received PATH message with the existing connection thereby identifying
> the path the message should be forwarded on. This approach was taken by
> these implementations since inclusion of an ERO is not mandatory. We
> would appreciate CCAMP's thoughts on what the behavior should be.

As described in RFC 2205, Path and Resv messages are idempotent.  This means
that any Path message reflects full state, and differences between one Path
message and a subsequent Path message may be reasonably considered an
explicit change. Therefore, while there is no explicit requirement stated in
RFC 3473, it is typical to only modify the Admin Status Object in Path
messages sent in connection to RFC 3473 section 7.2.1. deletion procedures
(i.e. to include the full ERO as on previous Path messages).

It may be observed, however, that while an implementation detecting a change
in ERO (such as the removal of the ERO) may legitimately opt to reroute,
that implementation should also note the change in Admin Status associated
with the graceful deletion and may "assume" that such a reroute would be a
waste of time. Further, in a transport system, implementations should only
perform local reroutes (deviating from in-place LSPs) with extreme caution
since these risk impacting traffic.

> 3) In the process of testing, we found cases where the update of a
> link's attributes (i.e. available capacity) was not being done by
> advertising an updated LSA using the same LSAid, but by flushing the old
> LSA followed by generation of a new LSA with a new LSAid. Since the
> LSAid for Opaque LSAs is not tied to the resource being advertised
> (i.e. the resource is identified using TLVs in the Opaque LSA, not using
> the LSAid as is done with IPv4 OSPF LSAs), this can cause a problem as
> it causes the order that the LSAs are processed to become important. We
> would appreciate CCAMP's thoughts on what the behavior should be.

 The OSPF WG, is the proper WG to respond to this as they are the
authoritative source on OSPF technology.  From our perspective, RFC 2328
dictates the use of the same Link State ID when advertising a change in
information about a link, and  RFC 3630  states "The LSA ID has no
topological significance."

While it is certainly possible to advertise a change via issuing an LSA with
a new Link State ID and flushing old state, from the perspective of OSPF
this is not a change in link state, rather a completely new link.

In fact, when there are key changes to the information advertised about a
link (for example, a change to the Link Type or Link ID), the advertising
router should recognise that these changes represent the advertisement of a
new link and should use a new LSA with a new Link State ID. However, where
the change is clearly a change to the link state of an existing link, the
advertising router should use the same Link State ID.

> 4) Finally, in the process of testing, we found cases where established
> connections were deleted based on node restart procedures in RFC
> 3473. R163 of the OIF Carrier requirements (liaised to IETF in 12/2006)
> states deletion of established connections as the result of control
> plane failure (including node restart) shall not occur. It has been
> identified this could also occur when a number of cascaded nodes restart
> at the same time. We would appreciate CCAMP's thoughts on ways to
> prevent deletion of established connections from occurring when a node
> restarts.

 Without specific details, it's impossible to address the found cases or to
identify if they were due to implementation or specification issues.

More broadly, RFC 3473 does not require the removal of forwarding state,
even in the case of state synchronization errors, and implementations may
take different action (such as reporting the condition to a management
station). An implementation at a restarting node may consider that the lack
of control plane state at its (fully functional) neighbor indicates that the
removal of forwarding plane state has been attempted through the control
plane while the restarting node was down and should follow local policy in
determining how to react.

We would also like to direct you to RFC 5063 and
draft-ietf-ccamp-gr-description which may provide additional relevant
information.

We hope this addresses your questions.

 Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs

Delivery-date: Thu, 03 Jan 2008 11:26:09 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Greg Bernstein" <[email-masked]>, <[email-masked]>
Subject: Re: WSON framework draft and  ccamp minutes
Date: Thu, 3 Jan 2008 11:24:01 -0000

Hi Greg,

>> "a. Framework (Greg 10, 65/120)
>> Adrian: Who thinks that the WSON is relevant to us?  Not a unanimous show 
>> of hands,
>> but still a good show of hands. We will go to list to see if this is the 
>> right draft
>> for the framework."
>
> If I recall there was also no opposition to the framework moving forward 
> as a working group draft.  However,
> proper procedures require that we always ask the question on the list 
> (right?). Do the chairs then poll the CCAMP list or
> do I as an author?

The chairs.

In due course (i.e., when they dig out of the snow)

Adrian 

Delivery-date: Wed, 02 Jan 2008 16:23:58 +0000
Date: Wed, 02 Jan 2008 09:21:15 -0700
From: Greg Bernstein <[email-masked]>
To: [email-masked]
Subject: WSON framework draft and  ccamp minutes

This is a multi-part message in MIME format.
--------------010006040202010502050906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Happy 2008, Adrian, Deborah and CCAMP.  The meeting minutes said:
> Try this version - there were an excessive number of typos introduced 
> in the other uploaded version:
> http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt
>
"a. Framework (Greg 10, 65/120)
Adrian: Who thinks that the WSON is relevant to us?  Not a unanimous show of hands,
but still a good show of hands. We will go to list to see if this is the right draft
for the framework."

If I recall there was also no opposition to the framework moving forward as a working group draft.  However, 
proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or 
do I as an author?

In either case the formal question is the whether the WSON Framework draft 
http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt

should be adopted as a working group document. 

The document is aligned with the CCAMP charter, hits an area that GMPLS 
was originally intended to cover, and covers subsystems and processes 
currently used in industry but desiring GMPLS automation and 
restoration. Hence I hope that the support on the list for this draft 
becoming a WG document is as strong as the support we saw at the 
Vancouver meeting.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

--------------010006040202010502050906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Happy 2008, Adrian, Deborah and CCAMP.&nbsp; The meeting minutes said:<br>
<blockquote
 cite="mid:[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2900.3243" name="GENERATOR">
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="583125019-31122007">Try this version - there
were an excessive number of&nbsp;typos introduced in the other uploaded
version:</span></font></div>
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="583125019-31122007"><a moz-do-not-send="true"
 href="http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt">http://www3.ietf.org/proceedings/07dec/minutes/ccamp.txt</a></span></font></div>
  <div dir="ltr" align="left"><font color="#0000ff" face="Arial"
 size="2"><span class="583125019-31122007"></span></font> <br>
  </div>
</blockquote>
<pre>"a. Framework (Greg 10, 65/120)
Adrian: Who thinks that the WSON is relevant to us?  Not a unanimous show of hands,
but still a good show of hands. We will go to list to see if this is the right draft
for the framework."

If I recall there was also no opposition to the framework moving forward as a working group draft.  However, 
proper procedures require that we always ask the question on the list (right?). Do the chairs then poll the CCAMP list or 
do I as an author?

In either case the formal question is the whether the WSON Framework draft 
<a
 href="http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt">http://www.ietf.org/internet-drafts/draft-bernstein-ccamp-wavelength-switched-02.txt</a>
</pre>
should be adopted as a working group document.&nbsp; <br>
<br>
The document is aligned with the CCAMP charter, hits an area that GMPLS
was originally intended to cover, and covers subsystems and processes
currently used in industry but desiring GMPLS automation and
restoration. Hence I hope that the support on the list for this draft
becoming a WG document is as strong as the support we saw at the
Vancouver meeting.<br>
<br>
Regards<br>
<br>
Greg B.<br>
<pre class="moz-signature" cols="72">-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

</pre>
</body>
</html>

--------------010006040202010502050906--