Document Action: 'Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)' to Informational RFC

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions 
   for Automatically Switched Optical Network (ASON) '
   <draft-ietf-ccamp-gmpls-ason-reqts-07.txt> as an Informational RFC

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
   protocols has been defined to control different switching 
   technologies as well as different applications. These include support 
   for requesting Time Division Multiplexing (TDM) connections including 
   Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 
   (SDH) and Optical Transport Networks (OTNs). 
   This document concentrates on the signaling aspects of the GMPLS 
   suite of protocols. It identifies the features to be covered by the 
   GMPLS signaling protocol to support the capabilities of an 
   Automatically Switched Optical Network (ASON). This document provides 
   a problem statement and additional requirements on the GMPLS 
   signaling protocol to support the ASON functionality. 
 
Working Group Summary
 
 This document is the product of a design team that included IETF and ITU
 members. The goal of the document was to represent requirements for ASON
 networks received from ITU in a liaison statement in the form understandable
 for a usual IETF participant.
 
Protocol Quality
 
 This document has been reviewed for IESG by Alex Zinin. Adrian Farrel
 followed up with the WG on the provided comments.

IANA Note

  This document makes no request of and places no requirements
  on IANA.





Envelope-to: [e-mail]
Delivery-date: Mon, 31 Jan 2005 16:03:33 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Document Action: 'Requirements for Generalized MPLS (GMPLS)  Signaling Usage and Extensions for Automatically Switched Optical  Network (ASON)' to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 31 Jan 2005 10:58:41 -0500

The IESG has approved the following document:

- 'Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions 
   for Automatically Switched Optical Network (ASON) '
   <draft-ietf-ccamp-gmpls-ason-reqts-07.txt> as an Informational RFC

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
   protocols has been defined to control different switching 
   technologies as well as different applications. These include support 
   for requesting Time Division Multiplexing (TDM) connections including 
   Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 
   (SDH) and Optical Transport Networks (OTNs). 
   This document concentrates on the signaling aspects of the GMPLS 
   suite of protocols. It identifies the features to be covered by the 
   GMPLS signaling protocol to support the capabilities of an 
   Automatically Switched Optical Network (ASON). This document provides 
   a problem statement and additional requirements on the GMPLS 
   signaling protocol to support the ASON functionality. 
 
Working Group Summary
 
 This document is the product of a design team that included IETF and ITU
 members. The goal of the document was to represent requirements for ASON
 networks received from ITU in a liaison statement in the form understandable
 for a usual IETF participant.
 
Protocol Quality
 
 This document has been reviewed for IESG by Alex Zinin. Adrian Farrel
 followed up with the WG on the provided comments.

IANA Note

  This document makes no request of and places no requirements
  on IANA.




Envelope-to: [e-mail]
Delivery-date: Mon, 31 Jan 2005 15:53:12 +0000
Message-ID: <04dd01c507ac$eec67500$cacb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "JP Vasseur" <[e-mail]>, <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 31 Jan 2005 09:54:34 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Dimitri,

I agree with your points, hence my original questions.

Note that reoptimization within a *single* domain can be handled
"centrally" with the advantages I describe.

If there are multiple domains involved (as you point out) things get
messy. But note that it is only the domain in which reoptimization is
possible that is going to advertise a reoptimization possibility. Thus
this single domain can work out which LSPs would be best reoptimized, and
only notify the appropriate ingresses about the subset of LSPs. In this
case (again) the notifying domain would best make this decision in a
"centralized" manner.

Cheers,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "JP Vasseur" <[e-mail]>; <[e-mail]>
Sent: Sunday, January 30, 2005 12:48 PM
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-


>
> adrian, concerning the below point:
>
> >>> Question...
> >>>
> >>> How does the process of unsolicited notification (of a potential
> >>> better path rather than of a link going oos) avoid thrashing races?
As
> >>> a very simple example, consider the following n/w.
> >>>
> >>> <-A1-> <--A0-> <-A2->
> >>> A-----B       C-----D
> >>>       |       |
> >>>       |       |
> >>> E-----F---G---H-----I
> >>>
> >>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and
> >>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
> >>>
> >>> Now install a *low* bandwidth link BC capable of carrying either but
> >>> not both LSPs. Both B and F will notice that the LSPs entering A0
> >>> through them can be re-optimized and will report the fact to A and E
> >>> respectively.
> >>
> >>note that if the link is a "low" bw link, it is unlikely that B and F
> >>will report a better path but yes that could happen depending on the
> >>IGP links costs indeed.
> >
> >Well, Let us assume that all links are 10G except BC which is 9.8G. Let
us
> >assume that the LSPs are 5G each...
> >
> >>> Both A and E will attempt mb4b, but (of course) only one will
succeed.
> >>> In a small network, this is not a big deal, but in a large network
> >>> with a lot of LSPs this is clearly a waste of processing and will
> >>> cause a degree of network thrash maybe only in the control plane,
but
> >>> maybe in the data plane if a lower priority LSP is re-routed first.
In
> >>> fact, this scenario can cause significant disruption in the data
plane
> >>> as the re-routed LSP will be preempted and could have been
> >>> successfully left in its original place.
> >>
> >>Indeed, but this is no different that any other reoptimization
scenario
> >>in a single area. If for example, a link is restored within an area
> >>that could offer a potentially more optimal path to a large number of
> >>TE LSPs, there could be race conditions indeed. This is usually sorted
> >>out by using jittered reoptimization at the head-end.
>
> and how this is sorted out when there are multiple competing head-ends
> (that may belong to separate domains) ?
>
> >Sure. In a single domain you can apply sensible and rational
> reoptimization >centrally.
>
> note that this "central" processing is difficult to achieve when
multiple
> hea ends do not belong (or are not under the control of a single entity)
>
> > This is relatively trivial and works well because:
> >- repotimization of one LSP at a time is bound to lead to
> >  relatively poor results
> >- reoptimization is not time-critical
> >Note that it is very important that an operation like reoptimization
> should >not lead to LSPs being dropped.
> >[SNIP]
> >
> >>> Thus I would suggest removing the unsolicited notification of
> >>> reoptimization opportunities (while retaining the unsolicited
> >>> notification of links going oos) or requiring that the policy be
> >>> timer-based not event triggered.
> >>
> >>We would definitely prefer to keep this mode. Implementation could
just
> >>activate the function for *some* sensitive LSP + combined with with
> >>jittered reoptimization but such notification is desirable to quickly
> >>take advantage of a newly restored link.
> >
> >OK, that's interesting.
> >So I didn't see any descripition of processing rules for when 25:6 is
> >received. I (flasely) assumed that the text for 25:7 and 25:8 applied,
but
> >clearly it doesn't. Perhaps you'd like to add some processing thoughts
for
> >25:6?
> >
> >Cheers,
> >Adrian
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Mon, 31 Jan 2005 14:41:47 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Ali Sajassi <[e-mail]>
Cc: Ali Sajassi <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Mon, 31 Jan 2005 06:38:40 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C507A2.8E2D0F42"

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

------_=_NextPart_001_01C507A2.8E2D0F42
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, January 29, 2005 5:45 AM
To: Ali Sajassi
Cc: [e-mail]; Ali Sajassi; Shahram Davari; David Allan; '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



indeed the L2LSP approach does not target the two below listed category of equipment (i.e. .1q bridges and IP/MPLS LSRs) - so what is the exact question/issue from this perspective ? 
So the question I'd like to ask is what type of end-user applications you have in mind that would require the VLANs to be stitched together this way? 


=> what do you mean by end-user in this context ? this said, the first target is to address ethernet terminating hosts but not limited to (it has been pointed during the previous f2f meeting that the initial version covers point-to-point ethernet frame flows) 


In order to implement the Ethernet VLAN L2SC of your draft, what kind of Hardware is needed?
Can you reuse existing standard hardware or you need a different hardware?
 
now the point is not only in reducing the overhead - but on the underlying operations when those are not required 
In this case, I'd like to know the details of how maintainability (OAM) and reliability (redundancy) aspects of the operations are addressed 


=> concerning ETH OAM it is not addressed as part of this document (ETH OAM is addressed via IEEE and the present document let's the possibility for making of any suitable mechanism it delivers - this is consistent with the approach we have taken here where we specifically address control aspects)  


The ETH OAM defined in IEEE assumes Connectionless behavior. For example the loopback or trace-route assumes that every intermediate node knows how to send the reply back to the ingress. Since GMPLS creates
a Connection-oriented network, I am not sure how it can reuse ETH OAM !!!!!

- on the other side it could be interesting that you extend a bit on the scalability of EoMPLS - to which scaling dimensions are you referring here ?
To number of connections which is independent from number of VLANs. BTW, when talking about VLAN stitching, you are only limited to 4K VLANs per interface (4K connections) even if that interface is 10GE, so why do you want to impose such limitations in the aggregation (and/or core) networks.


=> well this has been already discussed as part of this thread - there is no such "VLAN stitching" operation and with in the next revision (in terms of number) we will have the possibility to reach 2^32   

How can you reach 2^32 ? And if it is not VLAN stitching, then could you simply explain the operation? aren't you sending label request from downstream to upstream? I am confused !!!!!!!!!! 


-Ali


ps: concerning the last point i suggest a further reading of RFC 3945 (this could also help sorting the question on how GMPLS applies to packet LSPs)

Ali Sajassi <[e-mail]>
01/28/2005 15:49 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari <[e-mail]>
cc: Shahram Davari <[e-mail]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs


There are two categories of Ethernet switches out there:

1) pure L2 switches - existing IEEE (.1q) bridges
2) L2/L3 switches - capable of both bridging and MPLS/IP switching (including support for EoMPLS)

Considering the current L2/L3 switches can support PtP Ethernet services end-to-end in a scalable way using EoMPLS, then the question is why do we need yet another alternate mechanism to provide the same end service without any obvious benefit. Is saving a few byte in the header the primary objective in here ? 
It should be noted that the proposed use of GMPLS control plane is not compatible with either of the above two category of switches and thus cannot be leveraged by them. 

-Ali


------_=_NextPart_001_01C507A2.8E2D0F42
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff 
size=2>Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> 
[e-mail] 
[mailto:[e-mail]]<BR><B>Sent:</B> Saturday, January 29, 
2005 5:45 AM<BR><B>To:</B> Ali Sajassi<BR><B>Cc:</B> 
[e-mail]; Ali Sajassi; Shahram Davari; David Allan; 
'[e-mail]'; 'Adrian Farrel'; [e-mail]<BR><B>Subject:</B> 
RE: Layer 2 Switching Caps LSPs<BR><BR></FONT><BR><BR><FONT size=4>indeed the 
L2LSP approach does not target the two below listed category of equipment (i.e. 
.1q bridges and IP/MPLS LSRs) - so what is the exact question/issue from this 
perspective ? </FONT><BR><FONT size=4>So the question I'd like to ask is what 
type of end-user applications you have in mind that would require the VLANs to 
be stitched together this way? </FONT><BR></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <P>=&gt; what do you mean by end-user in this context ? this said, the first 
  target is to address ethernet terminating hosts but not limited to (it has 
  been pointed during the previous f2f meeting that the initial version covers 
  point-to-point ethernet frame flows)<SPAN class=361582414-31012005><FONT 
  face=Arial color=#0000ff size=2>&nbsp;</FONT></SPAN></P><SPAN 
  class=361582414-31012005>
  <DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff size=2>In 
  order to implement the Ethernet VLAN L2SC of your draft, what kind of Hardware 
  is needed?</FONT></SPAN></DIV>
  <DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff size=2>Can 
  you reuse existing standard hardware or you need&nbsp;a 
  different&nbsp;hardware?</FONT></SPAN></DIV>
  <DIV></SPAN><SPAN class=361582414-31012005>&nbsp;</SPAN><BR><FONT size=4>now 
  the point is not only in reducing the overhead - but on the underlying 
  operations when those are not required </FONT><BR><FONT size=4>In this case, 
  I'd like to know the details of how maintainability (OAM) and reliability 
  (redundancy) aspects of the operations are addressed </FONT><BR></DIV>
  <P>=&gt; concerning ETH OAM it is not addressed as part of this document (ETH 
  OAM is addressed via IEEE and the present document let's the possibility for 
  making of any suitable mechanism it delivers - this is consistent with the 
  approach we have taken here where we specifically address control 
  aspects)&nbsp;<SPAN class=361582414-31012005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P><SPAN class=361582414-31012005>
  <DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff size=2>The 
  ETH OAM defined in IEEE assumes Connectionless behavior. For example the 
  loopback or trace-route assumes that every intermediate node knows how to send 
  the reply back to the ingress. Since GMPLS creates</FONT></SPAN></DIV>
  <DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff size=2>a 
  Connection-oriented network, I am not sure how it can reuse ETH OAM 
  !!!!!</FONT></SPAN></DIV>
  <DIV><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN></SPAN><BR><FONT size=4>- on the other side it could be 
  interesting that you extend a bit on the scalability of EoMPLS - to which 
  scaling dimensions are you referring here ?</FONT><BR><FONT size=4>To number 
  of connections which is independent from number of VLANs. BTW, when talking 
  about VLAN stitching, you are only limited to 4K VLANs per interface (4K 
  connections) even if that interface is 10GE, so why do you want to impose such 
  limitations in the aggregation (and/or core) networks.</FONT><BR></DIV>
  <P>=&gt; well this has been already discussed as part of this thread - there 
  is no such "VLAN stitching" operation and with in the next revision (in terms 
  of number) we will have the possibility to reach 2^32&nbsp;&nbsp;<SPAN 
  class=361582414-31012005><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></P>
  <P><SPAN class=361582414-31012005><FONT face=Arial color=#0000ff size=2>How 
  can you reach 2^32 ? And if it is not VLAN stitching, then&nbsp;could you 
  simply explain the operation? aren't you sending label request from downstream 
  to upstream? I am confused !!!!!!!!!!</FONT>&nbsp;</SPAN></P>
  <P><BR><FONT size=4>-Ali</FONT><BR><BR><BR><FONT size=4>ps: concerning the 
  last point i suggest a further reading of RFC 3945 (this could also help 
  sorting the question on how GMPLS applies to packet LSPs)</FONT><BR><BR><B>Ali 
  Sajassi &lt;[e-mail]&gt;</B><BR>01/28/2005 15:49 PST<BR><BR>To:<FONT 
  size=4> </FONT>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[e-mail]&gt;<BR>cc:<FONT size=4> </FONT>Shahram 
  Davari &lt;[e-mail]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan 
  &lt;[e-mail]&gt;, "'[e-mail]'" 
  &lt;[e-mail]&gt;, "'Adrian Farrel'" &lt;[e-mail]&gt;, 
  [e-mail]<BR>bcc:<FONT size=4> </FONT><BR>Subject:<FONT size=4> 
  </FONT>RE: Layer 2 Switching Caps LSPs<BR><BR><BR><FONT size=5>There are two 
  categories of Ethernet switches out there:</FONT><BR><BR><FONT size=5>1) pure 
  L2 switches - existing IEEE (.1q) bridges</FONT><BR><FONT size=5>2) L2/L3 
  switches - capable of both bridging and MPLS/IP switching (including support 
  for EoMPLS)</FONT><BR><BR><FONT size=5>Considering the current L2/L3 switches 
  can support PtP Ethernet services end-to-end in a scalable way using EoMPLS, 
  then the question is why do we need yet another alternate mechanism to provide 
  the same end service without any obvious benefit. Is saving a few byte in the 
  header the primary objective in here ? </FONT><BR><FONT size=5>It should be 
  noted that the proposed use of GMPLS control plane is not compatible with 
  either of the above two category of switches and thus cannot be leveraged by 
  them. </FONT><BR><BR><FONT size=5>-Ali</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C507A2.8E2D0F42--



Envelope-to: [e-mail]
Delivery-date: Sun, 30 Jan 2005 12:52:13 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: "JP Vasseur" <[e-mail]>, <[e-mail]>
From: [e-mail]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
MIME-Version: 1.0
Date: Sun, 30 Jan 2005 13:48:56 +0100
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

adrian, concerning the below point:

>>> Question...
>>>
>>> How does the process of unsolicited notification (of a potential
>>> better path rather than of a link going oos) avoid thrashing races? As
>>> a very simple example, consider the following n/w.
>>>
>>> <-A1-> <--A0-> <-A2->
>>> A-----B       C-----D
>>>       |       |
>>>       |       |
>>> E-----F---G---H-----I
>>>
>>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and
>>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>>>
>>> Now install a *low* bandwidth link BC capable of carrying either but
>>> not both LSPs. Both B and F will notice that the LSPs entering A0
>>> through them can be re-optimized and will report the fact to A and E
>>> respectively.
>>
>>note that if the link is a "low" bw link, it is unlikely that B and F
>>will report a better path but yes that could happen depending on the
>>IGP links costs indeed.
>
>Well, Let us assume that all links are 10G except BC which is 9.8G. Let us
>assume that the LSPs are 5G each...
>
>>> Both A and E will attempt mb4b, but (of course) only one will succeed.
>>> In a small network, this is not a big deal, but in a large network
>>> with a lot of LSPs this is clearly a waste of processing and will
>>> cause a degree of network thrash maybe only in the control plane, but
>>> maybe in the data plane if a lower priority LSP is re-routed first. In
>>> fact, this scenario can cause significant disruption in the data plane
>>> as the re-routed LSP will be preempted and could have been
>>> successfully left in its original place.
>>
>>Indeed, but this is no different that any other reoptimization scenario
>>in a single area. If for example, a link is restored within an area
>>that could offer a potentially more optimal path to a large number of
>>TE LSPs, there could be race conditions indeed. This is usually sorted
>>out by using jittered reoptimization at the head-end.

and how this is sorted out when there are multiple competing head-ends
(that may belong to separate domains) ?

>Sure. In a single domain you can apply sensible and rational
reoptimization >centrally.

note that this "central" processing is difficult to achieve when multiple
hea ends do not belong (or are not under the control of a single entity)

> This is relatively trivial and works well because:
>- repotimization of one LSP at a time is bound to lead to
>  relatively poor results
>- reoptimization is not time-critical
>Note that it is very important that an operation like reoptimization
should >not lead to LSPs being dropped.
>[SNIP]
>
>>> Thus I would suggest removing the unsolicited notification of
>>> reoptimization opportunities (while retaining the unsolicited
>>> notification of links going oos) or requiring that the policy be
>>> timer-based not event triggered.
>>
>>We would definitely prefer to keep this mode. Implementation could just
>>activate the function for *some* sensitive LSP + combined with with
>>jittered reoptimization but such notification is desirable to quickly
>>take advantage of a newly restored link.
>
>OK, that's interesting.
>So I didn't see any descripition of processing rules for when 25:6 is
>received. I (flasely) assumed that the text for 25:7 and 25:8 applied, but
>clearly it doesn't. Perhaps you'd like to add some processing thoughts for
>25:6?
>
>Cheers,
>Adrian





Envelope-to: [e-mail]
Delivery-date: Sun, 30 Jan 2005 06:56:54 +0000
Message-ID: <041901c50698$b8e41c40$cacb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "JP Vasseur" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Sat, 29 Jan 2005 14:59:42 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0405_01C50613.29DC35D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0405_01C50613.29DC35D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks JP (and thanks for the rigour of tracking down all of the points =
raised).

[SNIPPED]

>> It seems to me that this draft is applicable to a strict ERO where =
one=20
>> of the hops is a non-specific abstract node such as an AS number. =
This=20
>> is made clear in section 2, but the Abstract and Introduction (yeah,=20
>> and also the title and draft name) do not adequately expose this =
fact.=20
>> But, further, the Introduction talks only about reoptimization =
without=20
>> any mention of loose hops or abstract nodes. Thus the draft is=20
>> schizoid to the third degree - is this loose path reoptimization,=20
>> reoptimization of loose and non-specific abstract nodes, or general=20
>> reoptimization? The draft needs to be consistent and clear.
>
>Agree, the following definition has been adopted throughout the=20
>document: "A loosely routed LSP is defined as an LSP that follows a=20
>path that contains at least one loose hop or a strict (abstract node)=20
>hop"

So, to be clear, you are only interested in the reoptimization of such =
"loosely routed LSPs".

But note RFC 3209...
   An abstract node
   is a group of nodes whose internal topology is opaque to the ingress
   node of the LSP.  An abstract node is said to be simple if it
   contains only one physical node.
So your definition is not quite accurate since a "strict (abstract node) =
hop" includes a strict simple abstract node.

How about:
   A loosely routed LSP is defined as one that does not contain a full
   explicit route identifying each LSR along the path of the LSP at=20
   the time it is signaled by the ingress LSR. Such an LSP is signaled
   with no ERO, with an ERO that contains at least one loose hop, or
   with an ERO that contains an abstract node that is not a simple
   abstract node (that is, an abstract node that identifies more than
   one LSR).

>I guess that the document title can remain unchanged considering that a =

>loose path also includes the case of a path where at least one hop is=20
>an abstract node.

Following the above definition, that is true. Just check that the =
defintion appears early in the Introduction (and maybe in the Abstract).

>> Section 2 states that an ERO expansion is either up to the next loose =

>> hop or to the destination. But, in fact, the ERO expansion may also =
be=20
>> any partial fragment towards either of these targets (including next=20
>> hop resolution). I suggest re-wording this paragraph to list (as=20
>> bullets) what an ERO might contain, and in a separate list, what the=20
>> computation might produce.
>
>We listed in this paragraph the most usual case of ERO expansion. If=20
>you're ok with this, elaborating further on ERO expansion is out of the =

>scope of this document.

"Most usual" is subjective. Consider nested domains.
But I'm not too bothered about this particular issue, so leave the text.
=20
>> Section 4.1
>>
>> I'm not comfortable with the Session Attributes toggling like this.=20
>> This type of function is what the Admin Status object was invented=20
>> for.

?

>> In section 5.3.2
>> - The link (sub-code=3D7) or the node (sub-code=3D8) MUST be
>>  locally registered for further reference (the TE database must
>>  be updated)
>>
>> What does "the TE database must be updated" mean? Are you saying that =

>> the TED is now built from information flooded by the IGP *and* by=20
>> information fed back from signaling? If so (and I don't approve!) =
then=20
>> you must define what happens when you receive a new LSA for the=20
>> specific link that contradicts the information signaled. There is a=20
>> strong argument that says that *the* method we use for building the=20
>> TED is IGP flooding - if this mechanism doesn't provide you with the=20
>> information you need, then you should propose extensions to the IGP,=20
>> not hook the information onto signaling.

>Let me sightly disagree here. I'm fine to not mention this since this=20
>may be implementation specific. That said, I do think that this is=20
>highly desirable (in combination with timer-based mechanism) so as to=20
>speed convergence. Typically, upon receiving a PathErr message it does=20
>make sense to first update your TED or the head-end will keep trying=20
>the same path until an LSA/LSP get received. In many networks, such=20
>optimization is definitely required to speed up the TE LSP rerouting.=20

I really disagree (more than slightly :-)

It is absolutely OK to say that the failed/going-oos link/node can be =
supplied to the path computation component as an exclusion. This applies =
to the recomputation of the failed LSP.

It is very suspect to say that you will update the TED. This would apply =
to the computation of new LSP *only* by the LSR that happens to be the =
ingress for the failed LSP. How do you know that the next LSP computed =
will be computed at that LSR?

For this procedure to have any realistic meaning, you would want the =
information to reach all computation points, and the signaling protocol =
should not do this.

Certainly, if you cite "rapid convergence", we will have to convince the =
IGP WGs and the ADs that it is correct to distribute routing information =
using the signaling protocol, and not to make changes to the IGP as =
necessary.

Again, I would like to refer you to the crankback draft which handles =
this issue at ingress and transit computation points.

>> OTOH it may be that all you mean is that the Session state should be=20
>> updated to indicate the link or node that is being shut down so that=20
>> later recomputation can avoid this link. In this case, I suggest you=20
>> refer to the CCAMP crankback draft.

>Still such update may be beneficial to other TE LSP and is orthogonal=20
>to the use of crankback?

The only way in which it is orthogonal is that it has been specified =
differently.

We have three drafts we need to sort out here.
- Loose path reoptimization
- Crankback
- Graceful shutdown

It seems to me (humbly ;-) that crankback defines the mechanisms for =
reporting failed resources during LSP setup or after the LSP is =
established. It specifies the procedures by which various LSRs may =
attempt to reroute.

Graceful shutdown specifies procedures for withdrawing resources so that =
LSPs are moved using make-before-break before a resource is set oos. =
This uses existing routing and signaling procedures, but introduces new =
error codes so that we can distinguish graceful shutdown from failure =
cases.

Loose path reoptimization essentially defines how an ingress may request =
information about potential reoptimization, and how an LSR may report =
potential reoptimization. The former is, of course, new procedures. The =
latter is new error codes.

I think I recall that you agreed that the local maintenance stuff should =
move out of the Loose Path Reoptimization draft [did I make that up?] in =
which case, the discussion we are having applies only to the split =
between crankback and graceful shutdown.

>> In section 5.3.2
>> - ... Note that in the case of TE LSP
>>  spanning multiple administrative domains, it may be desirable
>>  for the boundary LSR to modify the RSVP PathError message and
>>  insert its own address for confidentiality reason.
>>
>> Yes. Good point, but doesn't the error code also need to change?=20
>> Otherwise it will appear that the border node is the node being taken =

>> oos.
>
>If you agree with this argument I would vote for keeping the same error =

>code since this would not change the action taken by the head-end.

Note that this debate needs to be split for reoptimization and graceful =
shutdown. [Increasingly I hope I did hear you say you would remove all =
graceful shutdown text from this draft!]
But absolutely it would...

    AS1     :    AS2 =20
            :
A---.....---B---D-------Z
         \  :\ /       /
          \ : E       /
           \:        /=20
            C---..../
            :

Graceful shutdown...
Link BD wants to go out of service.
B needs to report this to A so that there is a make-before-break =
resignaling.
B substitutes its address in the PathErr.
A assumes B is not healthy and routes through C (very sub-optimal).
A should have resignaled through B and allowed B to route via E.

Reoptimization...
LSP is via E. Link BD comes up.
B needs to signal simply "reoptimize".
Since B will do the recomputation, the PathErr can safely carry its =
address.

>> Section 6
>>
>> Need to describe the processing by an LSR that does not understand =
the=20
>> new flag (rather than understand it but not support it). Note that =
you=20
>> cannot define the behavior of legacy LSRs in this draft, so you must=20
>> reference behavior defined in some other document.
>>
>> Ditto the new error code.
>
>Unfortunately I do not think that RFC3209 specifies the behavior of a=20
>node receiving a SESSION ATTRIBUTE flag that it does not understand ... =

>An implementation should then just ignore such flag if it does not=20
>understand it.

You are correct. This is one of the joys in our life.=20

But since nothing is stated, there is a high risk that your new flag =
will be zeroed out by a transit LSR. Oh dear; does that mean that your =
extensions cannot be guaranteed to work unless the whole network is =
upgraded?

So you need to make some statement. (Or perhaps you'd like to write a =
BCP for 3209?)


>> Question...
>>
>> How does the process of unsolicited notification (of a potential=20
>> better path rather than of a link going oos) avoid thrashing races? =
As=20
>> a very simple example, consider the following n/w.
>>=20
>> <-A1-> <--A0-> <-A2->
>> A-----B       C-----D
>>       |       |
>>       |       |
>> E-----F---G---H-----I
>>
>> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and=20
>> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>>
>> Now install a *low* bandwidth link BC capable of carrying either but=20
>> not both LSPs. Both B and F will notice that the LSPs entering A0=20
>> through them can be re-optimized and will report the fact to A and E=20
>> respectively.

>note that if the link is a "low" bw link, it is unlikely that B and F=20
>will report a better path but yes that could happen depending on the=20
>IGP links costs indeed.

Well, Let us assume that all links are 10G except BC which is 9.8G. Let =
us assume that the LSPs are 5G each...

>> Both A and E will attempt mb4b, but (of course) only one will =
succeed.=20
>> In a small network, this is not a big deal, but in a large network=20
>> with a lot of LSPs this is clearly a waste of processing and will=20
>> cause a degree of network thrash maybe only in the control plane, but =

>> maybe in the data plane if a lower priority LSP is re-routed first. =
In=20
>> fact, this scenario can cause significant disruption in the data =
plane=20
>> as the re-routed LSP will be preempted and could have been=20
>> successfully left in its original place.
>
>Indeed, but this is no different that any other reoptimization scenario =

>in a single area. If for example, a link is restored within an area=20
>that could offer a potentially more optimal path to a large number of=20
>TE LSPs, there could be race conditions indeed. This is usually sorted=20
>out by using jittered reoptimization at the head-end.

Sure. In a single domain you can apply sensible and rational =
reoptimization centrally. This is relatively trivial and works well =
because:
- repotimization of one LSP at a time is bound to lead to=20
  relatively poor results
- reoptimization is not time-critical
Note that it is very important that an operation like reoptimization =
should not lead to LSPs being dropped.=20

[SNIP]

>> Thus I would suggest removing the unsolicited notification of=20
>> reoptimization opportunities (while retaining the unsolicited=20
>> notification of links going oos) or requiring that the policy be=20
>> timer-based not event triggered.
>
>We would definitely prefer to keep this mode. Implementation could just =

>activate the function for *some* sensitive LSP + combined with with=20
>jittered reoptimization but such notification is desirable to quickly=20
>take advantage of a newly restored link.

OK, that's interesting.
So I didn't see any descripition of processing rules for when 25:6 is =
received. I (flasely) assumed that the text for 25:7 and 25:8 applied, =
but clearly it doesn't. Perhaps you'd like to add some processing =
thoughts for 25:6?

Cheers,
Adrian
------=_NextPart_000_0405_01C50613.29DC35D0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Thanks JP (and thanks for the rigour =
of tracking=20
down all of the points raised).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>[SNIPPED]</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><BR><FONT face=3DCourier =
size=3D2>&gt;&gt; It=20
seems to me that this draft is applicable to a strict ERO where one =
<BR>&gt;&gt;=20
of the hops is a non-specific abstract node such as an AS number. This=20
<BR>&gt;&gt; is made clear in section 2, but the Abstract and =
Introduction=20
(yeah, <BR>&gt;&gt; and also the title and draft name) do not adequately =
expose=20
this fact. <BR>&gt;&gt; But, further, the Introduction talks only about=20
reoptimization without <BR>&gt;&gt; any mention of loose hops or =
abstract nodes.=20
Thus the draft is <BR>&gt;&gt; schizoid to the third degree - is this =
loose path=20
reoptimization, <BR>&gt;&gt; reoptimization of loose and non-specific =
abstract=20
nodes, or general <BR>&gt;&gt; reoptimization? The draft needs to be =
consistent=20
and clear.<BR>&gt;<BR>&gt;Agree, the following definition has been =
adopted=20
throughout the <BR>&gt;document: "A loosely routed LSP is defined as an =
LSP that=20
follows a <BR>&gt;path that contains at least one loose hop or a strict=20
(abstract node) <BR>&gt;hop"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>So, to be clear, you are only =
interested in the=20
reoptimization of such "loosely routed LSPs".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>But note RFC 3209...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; An abstract =
node<BR>&nbsp;&nbsp; is=20
a group of nodes whose internal topology is opaque to the=20
ingress<BR>&nbsp;&nbsp; node of the LSP.&nbsp; An abstract node is said =
to be=20
simple if it<BR>&nbsp;&nbsp; contains only one physical =
node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>So your definition is not quite =
accurate since a=20
"strict (abstract node) hop" includes a strict simple abstract=20
node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>How about:</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; A loosely routed LSP is =
defined as=20
one that does not contain a full</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp; &nbsp;explicit route =
identifying each LSR=20
along the path of the LSP at </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; the time it is signaled =
by the=20
ingress LSR. Such an LSP is signaled</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; with no ERO, with an ERO =
that=20
contains at least one loose hop, or</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;with an ERO that =
contains an=20
abstract node that is not a simple</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;abstract node (that =
is, an=20
abstract node that identifies more than</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; one LSR).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;I guess that the document title =
can remain=20
unchanged considering that a <BR>&gt;loose path also includes the case =
of a path=20
where at least one hop is <BR>&gt;an abstract node.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Following the above definition, that =
is true.=20
Just check that the defintion appears early in the Introduction (and =
maybe in=20
the Abstract).</DIV>
<DIV><BR>&gt;&gt; Section 2 states that an ERO expansion is either up to =
the=20
next loose <BR>&gt;&gt; hop or to the destination. But, in fact, the ERO =

expansion may also be <BR>&gt;&gt; any partial fragment towards either =
of these=20
targets (including next <BR>&gt;&gt; hop resolution). I suggest =
re-wording this=20
paragraph to list (as <BR>&gt;&gt; bullets) what an ERO might contain, =
and in a=20
separate list, what the <BR>&gt;&gt; computation might=20
produce.<BR>&gt;<BR>&gt;We listed in this paragraph the most usual case =
of ERO=20
expansion. If <BR>&gt;you're ok with this, elaborating further on ERO =
expansion=20
is out of the <BR>&gt;scope of this document.</DIV>
<DIV>&nbsp;</DIV>
<DIV>"Most usual" is subjective. Consider nested domains.</DIV>
<DIV>But I'm not too bothered about this particular issue, so leave the=20
text.</DIV>
<DIV>&nbsp;<BR>&gt;&gt; Section 4.1<BR>&gt;&gt;<BR>&gt;&gt; I'm not =
comfortable=20
with the Session Attributes toggling like this. <BR>&gt;&gt; This type =
of=20
function is what the Admin Status object was invented <BR>&gt;&gt; =
for.</DIV>
<DIV>&nbsp;</DIV>
<DIV>?</DIV>
<DIV><BR>&gt;&gt; In section 5.3.2<BR>&gt;&gt; - The link (sub-code=3D7) =
or the=20
node (sub-code=3D8) MUST be<BR>&gt;&gt;&nbsp; locally registered for =
further=20
reference (the TE database must<BR>&gt;&gt; &nbsp;be=20
updated)<BR>&gt;&gt;<BR>&gt;&gt; What does "the TE database must be =
updated"=20
mean? Are you saying that <BR>&gt;&gt; the TED is now built from =
information=20
flooded by the IGP *and* by <BR>&gt;&gt; information fed back from =
signaling? If=20
so (and I don't approve!) then <BR>&gt;&gt; you must define what happens =
when=20
you receive a new LSA for the <BR>&gt;&gt; specific link that =
contradicts the=20
information signaled. There is a <BR>&gt;&gt; strong argument that says =
that=20
*the* method we use for building the <BR>&gt;&gt; TED is IGP flooding - =
if this=20
mechanism doesn't provide you with the <BR>&gt;&gt; information you =
need, then=20
you should propose extensions to the IGP, <BR>&gt;&gt; not hook the =
information=20
onto signaling.<BR><BR>&gt;Let me sightly disagree here. I'm fine to not =
mention=20
this since this <BR>&gt;may be implementation specific. That said, I do =
think=20
that this is <BR>&gt;highly desirable (in combination with timer-based=20
mechanism) so as to <BR>&gt;speed convergence. Typically, upon receiving =
a=20
PathErr message it does <BR>&gt;make sense to first update your TED or =
the=20
head-end will keep trying <BR>&gt;the same path until an LSA/LSP get =
received.=20
In many networks, such <BR>&gt;optimization is definitely required to =
speed up=20
the TE LSP rerouting. <BR></DIV>
<DIV>I really disagree (more than slightly :-)</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is absolutely OK to say that the failed/going-oos link/node can =
be=20
supplied to the path computation component as an exclusion. This applies =
to the=20
recomputation of the failed LSP.</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is very suspect to say that you will update the TED. This would =
apply to=20
the computation of new LSP *only* by the LSR that happens to be the =
ingress for=20
the failed LSP. How do you know that the next LSP computed will be =
computed at=20
that LSR?</DIV>
<DIV>&nbsp;</DIV>
<DIV>For this procedure to have any realistic meaning, you would want =
the=20
information to reach all computation points, and the signaling protocol =
should=20
not do this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Certainly, if you cite "rapid convergence", we will have to =
convince the=20
IGP WGs and the ADs that it is correct to distribute routing information =
using=20
the signaling protocol, and not to make changes to the IGP as =
necessary.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Again, I would like to refer you to the crankback draft which =
handles this=20
issue at ingress and transit computation points.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt; OTOH it may be that all you mean is that the Session state =
should=20
be <BR>&gt;&gt; updated to indicate the link or node that is being shut =
down so=20
that <BR>&gt;&gt; later recomputation can avoid this link. In this case, =
I=20
suggest you <BR>&gt;&gt; refer to the CCAMP crankback =
draft.<BR><BR>&gt;Still=20
such update may be beneficial to other TE LSP and is orthogonal =
<BR>&gt;to the=20
use of crankback?</DIV>
<DIV>&nbsp;</DIV>
<DIV>The only way in which it is orthogonal is that it has been =
specified=20
differently.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We have three drafts we need to sort out here.</DIV>
<DIV>- Loose path reoptimization</DIV>
<DIV>- Crankback</DIV>
<DIV>- Graceful shutdown</DIV>
<DIV>&nbsp;</DIV>
<DIV>It seems to me (humbly ;-) that crankback defines the mechanisms =
for=20
reporting failed resources during LSP setup or after the LSP is =
established. It=20
specifies the procedures by which various LSRs may attempt to =
reroute.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Graceful shutdown specifies procedures for withdrawing resources so =
that=20
LSPs are moved using make-before-break before a resource is set oos. =
This uses=20
existing routing and signaling procedures, but introduces new error =
codes so=20
that we can distinguish graceful shutdown from failure cases.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Loose path reoptimization essentially defines how an ingress may =
request=20
information about potential reoptimization, and how an LSR may report =
potential=20
reoptimization. The former is, of course, new procedures. The latter is =
new=20
error codes.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think I recall that you agreed that the local maintenance stuff =
should=20
move out of the Loose Path Reoptimization draft [did I make that up?] in =
which=20
case, the discussion we are having applies only to the split between =
crankback=20
and graceful shutdown.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt; In section 5.3.2<BR>&gt;&gt; - ... Note that in the case =
of TE=20
LSP<BR>&gt;&gt;&nbsp; spanning multiple administrative domains, it may =
be=20
desirable<BR>&gt;&gt;&nbsp; for the boundary LSR to modify the RSVP =
PathError=20
message and<BR>&gt;&gt; &nbsp;insert its own address for confidentiality =

reason.<BR>&gt;&gt;<BR>&gt;&gt; Yes. Good point, but doesn't the error =
code also=20
need to change? <BR>&gt;&gt; Otherwise it will appear that the border =
node is=20
the node being taken <BR>&gt;&gt; oos.<BR>&gt;<BR>&gt;If you agree with =
this=20
argument I would vote for keeping the same error <BR>&gt;code since this =
would=20
not change the action taken by the head-end.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Note that&nbsp;this debate needs to be split for reoptimization and =

graceful shutdown. [Increasingly I hope I did hear you say you would =
remove all=20
graceful&nbsp;shutdown text from this draft!]</DIV>
<DIV>But absolutely it would...</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;AS1&nbsp;&nbsp;&nbsp;&nbsp; =
:&nbsp;&nbsp;&nbsp;=20
AS2&nbsp;&nbsp;</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
:</DIV>
<DIV>A---.....---B---D-------Z</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \&nbsp; :\=20
/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \=20
:&nbsp;E&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\:=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
/ </DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;C---..../</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;:<BR></DIV>
<DIV>Graceful shutdown...</DIV>
<DIV>Link BD wants to go out of service.</DIV>
<DIV>B needs to report this to A so that there is a make-before-break=20
resignaling.</DIV>
<DIV>B substitutes its address in the PathErr.</DIV>
<DIV>A assumes B is not healthy and routes through C (very =
sub-optimal).</DIV>
<DIV>A should have resignaled through B and allowed B to route via =
E.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Reoptimization...</DIV>
<DIV>LSP is via E. Link BD comes up.</DIV>
<DIV>B needs to signal simply "reoptimize".</DIV>
<DIV>Since B will do the recomputation, the PathErr can safely carry its =

address.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;&gt; Section 6<BR>&gt;&gt;<BR>&gt;&gt; Need to describe the =
processing=20
by an LSR that does not understand the <BR>&gt;&gt; new flag (rather =
than=20
understand it but not support it). Note that you <BR>&gt;&gt; cannot =
define the=20
behavior of legacy LSRs in this draft, so you must <BR>&gt;&gt; =
reference=20
behavior defined in some other document.<BR>&gt;&gt;<BR>&gt;&gt; Ditto =
the new=20
error code.<BR>&gt;<BR>&gt;Unfortunately I do not think that RFC3209 =
specifies=20
the behavior of a <BR>&gt;node receiving a SESSION ATTRIBUTE flag that =
it does=20
not understand ... <BR>&gt;An implementation should then just ignore =
such flag=20
if it does not <BR>&gt;understand it.</DIV>
<DIV>&nbsp;</DIV>
<DIV>You are correct. This is one of the joys in our life. </DIV>
<DIV>&nbsp;</DIV>
<DIV>But since nothing is stated, there is a high risk that your new =
flag will=20
be zeroed out by a transit LSR. Oh dear; does that mean that your =
extensions=20
cannot be guaranteed to work unless the whole network is upgraded?</DIV>
<DIV>&nbsp;</DIV>
<DIV>So you need to make some statement. (Or perhaps you'd like to write =
a BCP=20
for 3209?)<BR><BR><BR>&gt;&gt;&nbsp;Question...<BR>&gt;&gt;<BR>&gt;&gt; =
How does=20
the process of unsolicited notification (of a potential <BR>&gt;&gt; =
better path=20
rather than of a link going oos) avoid thrashing races? As <BR>&gt;&gt; =
a very=20
simple example, consider the following n/w.<BR>&gt;&gt; <BR>&gt;&gt;=20
&lt;-A1-&gt; &lt;--A0-&gt; &lt;-A2-&gt;<BR>&gt;&gt;=20
A-----B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
C-----D<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
|<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<BR>&gt;&gt;=20
E-----F---G---H-----I<BR>&gt;&gt;<BR>&gt;&gt; Set up two LSPs AI and ED =
using=20
EROs {A,B(L),H(L),I} and <BR>&gt;&gt; {E,F(L),C(L),D} producing paths =
ABFGHI and=20
EFGHCD.<BR>&gt;&gt;<BR>&gt;&gt; Now install a *low* bandwidth link BC =
capable of=20
carrying either but <BR>&gt;&gt; not both LSPs. Both B and F will notice =
that=20
the LSPs entering A0 <BR>&gt;&gt; through them can be re-optimized and =
will=20
report the fact to A and E <BR>&gt;&gt; respectively.<BR><BR>&gt;note =
that if=20
the link is a "low" bw link, it is unlikely that B and F <BR>&gt;will =
report a=20
better path but yes that could happen depending on the <BR>&gt;IGP links =
costs=20
indeed.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Well, Let us assume that all links are 10G except BC which is 9.8G. =
Let us=20
assume that the LSPs are 5G each...</DIV>
<DIV><BR>&gt;&gt; Both A and E will attempt mb4b, but (of course) only =
one will=20
succeed. <BR>&gt;&gt; In a small network, this is not a big deal, but in =
a large=20
network <BR>&gt;&gt; with a lot of LSPs this is clearly a waste of =
processing=20
and will <BR>&gt;&gt; cause a degree of network thrash maybe only in the =
control=20
plane, but <BR>&gt;&gt; maybe in the data plane if a lower priority LSP =
is=20
re-routed first. In <BR>&gt;&gt; fact, this scenario can cause =
significant=20
disruption in the data plane <BR>&gt;&gt; as the re-routed LSP will be =
preempted=20
and could have been <BR>&gt;&gt; successfully left in its original =
place.</DIV>
<DIV>&gt;</DIV>
<DIV>&gt;Indeed, but this is no different that any other reoptimization =
scenario=20
<BR>&gt;in a single area. If for example, a link is restored within an =
area=20
<BR>&gt;that could offer a potentially more optimal path to a large =
number of=20
<BR>&gt;TE LSPs, there could be race conditions indeed. This is usually =
sorted=20
<BR>&gt;out by using jittered reoptimization at the head-end.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Sure. In a single domain you can apply sensible and rational =
reoptimization=20
centrally. This is relatively trivial and works well because:</DIV>
<DIV>- repotimization of one LSP at a time is bound to lead to </DIV>
<DIV>&nbsp; relatively poor results</DIV>
<DIV>- reoptimization is not time-critical</DIV>
<DIV>Note that it is very important that an operation like =
reoptimization should=20
not lead to LSPs being dropped. <BR></DIV>
<DIV>[SNIP]</DIV>
<DIV><BR>&gt;&gt; Thus I would suggest removing the unsolicited =
notification of=20
<BR>&gt;&gt; reoptimization opportunities (while retaining the =
unsolicited=20
<BR>&gt;&gt; notification of links going oos) or requiring that the =
policy be=20
<BR>&gt;&gt; timer-based not event triggered.<BR>&gt;<BR>&gt;We would =
definitely=20
prefer to keep this mode. Implementation could just <BR>&gt;activate the =

function for *some* sensitive LSP + combined with with <BR>&gt;jittered=20
reoptimization but such notification is desirable to quickly =
<BR>&gt;take=20
advantage of a newly restored link.</DIV>
<DIV>&nbsp;</DIV>
<DIV>OK, that's interesting.</DIV>
<DIV>So I didn't see any descripition of processing rules for when 25:6 =
is=20
received. I (flasely) assumed that the text for 25:7 and 25:8 applied, =
but=20
clearly it doesn't. Perhaps you'd like to add some processing thoughts =
for=20
25:6?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Cheers,</DIV>
<DIV>Adrian</DIV></FONT></BODY></HTML>

------=_NextPart_000_0405_01C50613.29DC35D0--




Envelope-to: [e-mail]
Delivery-date: Sat, 29 Jan 2005 10:50:41 +0000
To: Ali Sajassi <[e-mail]>
Cc: [e-mail], Ali Sajassi <[e-mail]>, Shahram Davari <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 11:44:47 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+Jm5ic3A7PEJSPjxCUj48QlI+PEZPTlQgU0laRT00PmluZGVlZCB0aGUgTDJMU1AgYXBwcm9h
Y2ggZG9lcyBub3QgdGFyZ2V0IHRoZSB0d28gYmVsb3cgbGlzdGVkIGNhdGVnb3J5IG9mIGVxdWlw
bWVudCAoaS5lLiAuMXEgYnJpZGdlcyBhbmQgSVAvTVBMUyBMU1JzKSAtIHNvIHdoYXQgaXMgdGhl
IGV4YWN0IHF1ZXN0aW9uL2lzc3VlIGZyb20gdGhpcyBwZXJzcGVjdGl2ZSA/IDwvRk9OVD48QlI+
PEZPTlQgU0laRT00PlNvIHRoZSBxdWVzdGlvbiBJJ2QgbGlrZSB0byBhc2sgaXMgd2hhdCB0eXBl
IG9mIGVuZC11c2VyIGFwcGxpY2F0aW9ucyB5b3UgaGF2ZSBpbiBtaW5kIHRoYXQgd291bGQgcmVx
dWlyZSB0aGUgVkxBTnMgdG8gYmUgc3RpdGNoZWQgdG9nZXRoZXIgdGhpcyB3YXk/IDwvRk9OVD48
QlI+PC9QPjxQPj0mZ3Q7IHdoYXQgZG8geW91IG1lYW4gYnkgZW5kLXVzZXIgaW4gdGhpcyBjb250
ZXh0ID8gdGhpcyBzYWlkLCB0aGUgZmlyc3QgdGFyZ2V0IGlzIHRvIGFkZHJlc3MgZXRoZXJuZXQg
dGVybWluYXRpbmcgaG9zdHMgYnV0IG5vdCBsaW1pdGVkIHRvIChpdCBoYXMgYmVlbiBwb2ludGVk
IGR1cmluZyB0aGUgcHJldmlvdXMgZjJmIG1lZXRpbmcgdGhhdCB0aGUgaW5pdGlhbCB2ZXJzaW9u
IGNvdmVycyBwb2ludC10by1wb2ludCBldGhlcm5ldCBmcmFtZSBmbG93cyk8L1A+PFA+PEJSPjxG
T05UIFNJWkU9ND5ub3cgdGhlIHBvaW50IGlzIG5vdCBvbmx5IGluIHJlZHVjaW5nIHRoZSBvdmVy
aGVhZCAtIGJ1dCBvbiB0aGUgdW5kZXJseWluZyBvcGVyYXRpb25zIHdoZW4gdGhvc2UgYXJlIG5v
dCByZXF1aXJlZCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5JbiB0aGlzIGNhc2UsIEknZCBsaWtl
IHRvIGtub3cgdGhlIGRldGFpbHMgb2YgaG93IG1haW50YWluYWJpbGl0eSAoT0FNKSBhbmQgcmVs
aWFiaWxpdHkgKHJlZHVuZGFuY3kpIGFzcGVjdHMgb2YgdGhlIG9wZXJhdGlvbnMgYXJlIGFkZHJl
c3NlZCA8L0ZPTlQ+PEJSPjwvUD48UD49Jmd0OyBjb25jZXJuaW5nIEVUSCBPQU0gaXQgaXMgbm90
IGFkZHJlc3NlZCBhcyBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgKEVUSCBPQU0gaXMgYWRkcmVzc2Vk
IHZpYSBJRUVFIGFuZCB0aGUgcHJlc2VudCBkb2N1bWVudCBsZXQncyB0aGUgcG9zc2liaWxpdHkg
Zm9yIG1ha2luZyBvZiBhbnkgc3VpdGFibGUgbWVjaGFuaXNtIGl0IGRlbGl2ZXJzIC0gdGhpcyBp
cyBjb25zaXN0ZW50IHdpdGggdGhlIGFwcHJvYWNoIHdlIGhhdmUgdGFrZW4gaGVyZSB3aGVyZSB3
ZSBzcGVjaWZpY2FsbHkgYWRkcmVzcyBjb250cm9sIGFzcGVjdHMpIDwvUD48UD48QlI+PEZPTlQg
U0laRT00Pi0gb24gdGhlIG90aGVyIHNpZGUgaXQgY291bGQgYmUgaW50ZXJlc3RpbmcgdGhhdCB5
b3UgZXh0ZW5kIGEgYml0IG9uIHRoZSBzY2FsYWJpbGl0eSBvZiBFb01QTFMgLSB0byB3aGljaCBz
Y2FsaW5nIGRpbWVuc2lvbnMgYXJlIHlvdSByZWZlcnJpbmcgaGVyZSA/PC9GT05UPjxCUj48Rk9O
VCBTSVpFPTQ+VG8gbnVtYmVyIG9mIGNvbm5lY3Rpb25zIHdoaWNoIGlzIGluZGVwZW5kZW50IGZy
b20gbnVtYmVyIG9mIFZMQU5zLiBCVFcsIHdoZW4gdGFsa2luZyBhYm91dCBWTEFOIHN0aXRjaGlu
ZywgeW91IGFyZSBvbmx5IGxpbWl0ZWQgdG8gNEsgVkxBTnMgcGVyIGludGVyZmFjZSAoNEsgY29u
bmVjdGlvbnMpIGV2ZW4gaWYgdGhhdCBpbnRlcmZhY2UgaXMgMTBHRSwgc28gd2h5IGRvIHlvdSB3
YW50IHRvIGltcG9zZSBzdWNoIGxpbWl0YXRpb25zIGluIHRoZSBhZ2dyZWdhdGlvbiAoYW5kL29y
IGNvcmUpIG5ldHdvcmtzLjwvRk9OVD48QlI+PC9QPjxQPj0mZ3Q7IHdlbGwgdGhpcyBoYXMgYmVl
biBhbHJlYWR5IGRpc2N1c3NlZCBhcyBwYXJ0IG9mIHRoaXMgdGhyZWFkIC0gdGhlcmUgaXMgbm8g
c3VjaCAmcXVvdDtWTEFOIHN0aXRjaGluZyZxdW90OyBvcGVyYXRpb24gYW5kIHdpdGggaW4gdGhl
IG5leHQgcmV2aXNpb24gKGluIHRlcm1zIG9mIG51bWJlcikgd2Ugd2lsbCBoYXZlIHRoZSBwb3Nz
aWJpbGl0eSB0byByZWFjaCAyXjMyICZuYnNwOzwvUD48UD48QlI+PEZPTlQgU0laRT00Pi1BbGk8
L0ZPTlQ+PEJSPjxCUj48QlI+PEZPTlQgU0laRT00PnBzOiBjb25jZXJuaW5nIHRoZSBsYXN0IHBv
aW50IGkgc3VnZ2VzdCBhIGZ1cnRoZXIgcmVhZGluZyBvZiBSRkMgMzk0NSAodGhpcyBjb3VsZCBh
bHNvIGhlbHAgc29ydGluZyB0aGUgcXVlc3Rpb24gb24gaG93IEdNUExTIGFwcGxpZXMgdG8gcGFj
a2V0IExTUHMpPC9GT05UPjxCUj48QlI+PEI+QWxpIFNhamFzc2kgJmx0O3NhamFzc2lAY2lzY28u
Y29tJmd0OzwvQj48QlI+MDEvMjgvMjAwNSAxNTo0OSBQU1Q8QlI+PEJSPlRvOjxGT05UIFNJWkU9
ND4gPC9GT05UPkRpbWl0cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwsIFNoYWhy
YW0gRGF2YXJpICZsdDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZndDs8QlI+Y2M6PEZP
TlQgU0laRT00PiA8L0ZPTlQ+U2hhaHJhbSBEYXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1z
aWVycmEuY29tJmd0OywgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwg
RGF2aWQgQWxsYW4gJmx0O2RhbGxhbkBub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7LCAmcXVvdDsnZHBh
cGFkaW1pdHJpb3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGltaXRyaW91QHBzZy5jb20mZ3Q7
LCAmcXVvdDsnQWRyaWFuIEZhcnJlbCcmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7
LCBjY2FtcEBvcHMuaWV0Zi5vcmc8QlI+YmNjOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5TdWJq
ZWN0OjxGT05UIFNJWkU9ND4gPC9GT05UPlJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8
QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+VGhlcmUgYXJlIHR3byBjYXRlZ29yaWVzIG9mIEV0aGVy
bmV0IHN3aXRjaGVzIG91dCB0aGVyZTo8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+MSkgcHVy
ZSBMMiBzd2l0Y2hlcyAtIGV4aXN0aW5nIElFRUUgKC4xcSkgYnJpZGdlczwvRk9OVD48QlI+PEZP
TlQgU0laRT01PjIpIEwyL0wzIHN3aXRjaGVzIC0gY2FwYWJsZSBvZiBib3RoIGJyaWRnaW5nIGFu
ZCBNUExTL0lQIHN3aXRjaGluZyAoaW5jbHVkaW5nIHN1cHBvcnQgZm9yIEVvTVBMUyk8L0ZPTlQ+
PEJSPjxCUj48Rk9OVCBTSVpFPTU+Q29uc2lkZXJpbmcgdGhlIGN1cnJlbnQgTDIvTDMgc3dpdGNo
ZXMgY2FuIHN1cHBvcnQgUHRQIEV0aGVybmV0IHNlcnZpY2VzIGVuZC10by1lbmQgaW4gYSBzY2Fs
YWJsZSB3YXkgdXNpbmcgRW9NUExTLCB0aGVuIHRoZSBxdWVzdGlvbiBpcyB3aHkgZG8gd2UgbmVl
ZCB5ZXQgYW5vdGhlciBhbHRlcm5hdGUgbWVjaGFuaXNtIHRvIHByb3ZpZGUgdGhlIHNhbWUgZW5k
IHNlcnZpY2Ugd2l0aG91dCBhbnkgb2J2aW91cyBiZW5lZml0LiBJcyBzYXZpbmcgYSBmZXcgYnl0
ZSBpbiB0aGUgaGVhZGVyIHRoZSBwcmltYXJ5IG9iamVjdGl2ZSBpbiBoZXJlID8gPC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTU+SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIHByb3Bvc2VkIHVzZSBv
ZiBHTVBMUyBjb250cm9sIHBsYW5lIGlzIG5vdCBjb21wYXRpYmxlIHdpdGggZWl0aGVyIG9mIHRo
ZSBhYm92ZSB0d28gY2F0ZWdvcnkgb2Ygc3dpdGNoZXMgYW5kIHRodXMgY2Fubm90IGJlIGxldmVy
YWdlZCBieSB0aGVtLiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+LUFsaTwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Sat, 29 Jan 2005 01:07:48 +0000
Message-Id: <[e-mail]>
Date: Fri, 28 Jan 2005 17:06:04 -0800
To: [e-mail], Ali Sajassi <[e-mail]>
From: Ali Sajassi <[e-mail]>
Subject: RE: Layer 2 Switching Caps LSPs
Cc: [e-mail], Shahram Davari <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_676401383==_.ALT"

--=====================_676401383==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:09 AM 1/29/2005 +0100, [e-mail] wrote:

>indeed the L2LSP approach does not target the two below listed category of 
>equipment (i.e. .1q bridges and IP/MPLS LSRs) - so what is the exact 
>question/issue from this perspective ?

So the question I'd like to ask is what type of end-user applications you 
have in mind that would require the VLANs to be stitched together this way?

>now the point is not only in reducing the overhead - but on the underlying 
>operations when those are not required

In this case, I'd like to know the details of how maintainability (OAM) and 
reliability (redundancy) aspects of the operations are addressed ?

>- on the other side it could be interesting that you extend a bit on the 
>scalability of EoMPLS - to which scaling dimensions are you referring here ?

To number of connections which is independent from number of VLANs. BTW, 
when talking about VLAN stitching, you are only limited to 4K VLANs per 
interface (4K connections) even if that interface is 10GE, so why do you 
want to impose such limitations in the aggregation (and/or core) networks.

-Ali


>ps: concerning the last point i suggest a further reading of RFC 3945 
>(this could also help sorting the question on how GMPLS applies to packet LSPs)
>
>Ali Sajassi <[e-mail]>
>01/28/2005 15:49 PST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
><[e-mail]>
>cc: Shahram Davari <[e-mail]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[e-mail]>, 
>"'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" 
><[e-mail]>, [e-mail]
>bcc:
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>There are two categories of Ethernet switches out there:
>
>1) pure L2 switches - existing IEEE (.1q) bridges
>2) L2/L3 switches - capable of both bridging and MPLS/IP switching 
>(including support for EoMPLS)
>
>Considering the current L2/L3 switches can support PtP Ethernet services 
>end-to-end in a scalable way using EoMPLS, then the question is why do we 
>need yet another alternate mechanism to provide the same end service 
>without any obvious benefit. Is saving a few byte in the header the 
>primary objective in here ?
>It should be noted that the proposed use of GMPLS control plane is not 
>compatible with either of the above two category of switches and thus 
>cannot be leveraged by them.
>
>-Ali

--=====================_676401383==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 01:09 AM 1/29/2005 +0100, [e-mail] 
wrote:<br>
<br>
<blockquote type=cite cite>indeed the L2LSP approach does not target the
two below listed category of equipment (i.e. .1q bridges and IP/MPLS
LSRs) - so what is the exact question/issue from this perspective ?
</blockquote><br>
So the question I'd like to ask is what type of end-user applications you
have in mind that would require the VLANs to be stitched together this
way? <br>
<br>
<blockquote type=cite cite>now the point is not only in reducing the
overhead - but on the underlying operations when those are not required
</blockquote><br>
In this case, I'd like to know the details of how maintainability (OAM)
and reliability (redundancy) aspects of the operations are addressed
?<br>
<br>
<blockquote type=cite cite>- on the other side it could be interesting
that you extend a bit on the scalability of EoMPLS - to which scaling
dimensions are you referring here ?</blockquote><br>
To number of connections which is independent from number of VLANs. BTW,
when talking about VLAN stitching, you are only limited to 4K VLANs per
interface (4K connections) even if that interface is 10GE, so why do you
want to impose such limitations in the aggregation (and/or core)
networks.<br>
<br>
-Ali<br>
<br>
<br>
<blockquote type=cite cite>ps: concerning the last point i suggest a
further reading of RFC 3945 (this could also help sorting the question on
how GMPLS applies to packet LSPs)<br>
<br>
<font size=2><b>Ali Sajassi &lt;[e-mail]&gt;</b></font><br>
<font size=2>01/28/2005 15:49 PST</font><br>
<br>
<font size=2>To:</font> <font size=2>Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari
&lt;[e-mail]&gt;</font><br>
<font size=2>cc:</font> <font size=2>Shahram Davari
&lt;[e-mail]&gt;, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan
&lt;[e-mail]&gt;, &quot;'[e-mail]'&quot;
&lt;[e-mail]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[e-mail]&gt;, [e-mail]</font><br>
<font size=2>bcc:</font> <br>
<font size=2>Subject:</font> <font size=2>RE: Layer 2 Switching Caps
LSPs</font><br>
<br>
<br>
<font size=4>There are two categories of Ethernet switches out
there:</font><br>
<br>
<font size=4>1) pure L2 switches - existing IEEE (.1q)
bridges</font><br>
<font size=4>2) L2/L3 switches - capable of both bridging and MPLS/IP
switching (including support for EoMPLS)</font><br>
<br>
<font size=4>Considering the current L2/L3 switches can support PtP
Ethernet services end-to-end in a scalable way using EoMPLS, then the
question is why do we need yet another alternate mechanism to provide the
same end service without any obvious benefit. Is saving a few byte in the
header the primary objective in here ? </font><br>
<font size=4>It should be noted that the proposed use of GMPLS control
plane is not compatible with either of the above two category of switches
and thus cannot be leveraged by them. </font><br>
<br>
<font size=4>-Ali</font><br>
</blockquote></html>

--=====================_676401383==_.ALT--



Envelope-to: [e-mail]
Delivery-date: Sat, 29 Jan 2005 00:11:08 +0000
To: Ali Sajassi <[e-mail]>
Cc: [e-mail], Shahram Davari <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 01:09:59 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+aW5kZWVkIHRoZSBMMkxTUCBhcHByb2FjaCBkb2VzIG5vdCB0YXJnZXQgdGhlIHR3byBiZWxv
dyBsaXN0ZWQgY2F0ZWdvcnkgb2YgZXF1aXBtZW50IChpLmUuIC4xcSBicmlkZ2VzIGFuZCBJUC9N
UExTIExTUnMpIC0gc28gd2hhdCBpcyB0aGUgZXhhY3QgcXVlc3Rpb24vaXNzdWUgZnJvbSB0aGlz
IHBlcnNwZWN0aXZlID8gbm93IHRoZSBwb2ludCBpcyBub3Qgb25seSBpbiByZWR1Y2luZyB0aGUg
b3ZlcmhlYWQgLSBidXQgb24gdGhlIHVuZGVybHlpbmcgb3BlcmF0aW9ucyB3aGVuIHRob3NlIGFy
ZSBub3QgcmVxdWlyZWQgLSBvbiB0aGUgb3RoZXIgc2lkZSBpdCBjb3VsZCBiZSBpbnRlcmVzdGlu
ZyB0aGF0IHlvdSBleHRlbmQgYSBiaXQgb24gdGhlIHNjYWxhYmlsaXR5IG9mIEVvTVBMUyAtIHRv
IHdoaWNoIHNjYWxpbmcgZGltZW5zaW9ucyBhcmUgeW91IHJlZmVycmluZyBoZXJlID88L1A+PFA+
cHM6IGNvbmNlcm5pbmcgdGhlIGxhc3QgcG9pbnQgaSBzdWdnZXN0IGEgZnVydGhlciByZWFkaW5n
IG9mIFJGQyAzOTQ1ICh0aGlzIGNvdWxkIGFsc28gaGVscCBzb3J0aW5nIHRoZSBxdWVzdGlvbiBv
biBob3cgR01QTFMgYXBwbGllcyB0byBwYWNrZXQgTFNQcyk8QlI+PEJSPjxGT05UIFNJWkU9Mj48
Qj5BbGkgU2FqYXNzaSAmbHQ7c2FqYXNzaUBjaXNjby5jb20mZ3Q7PC9CPjwvRk9OVD48QlI+PEZP
TlQgU0laRT0yPjAxLzI4LzIwMDUgMTU6NDkgUFNUPC9GT05UPjxCUj48QlI+IDxGT05UIFNJWkU9
Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRF
TEBBTENBVEVMLCBTaGFocmFtIERhdmFyaSAmbHQ7U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5j
b20mZ3Q7PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPlNo
YWhyYW0gRGF2YXJpICZsdDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZndDssIERpbWl0
cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUwsIERhdmlkIEFsbGFuICZsdDtkYWxs
YW5Abm9ydGVsbmV0d29ya3MuY29tJmd0OywgJnF1b3Q7J2RwYXBhZGltaXRyaW91QHBzZy5jb20n
JnF1b3Q7ICZsdDtkcGFwYWRpbWl0cmlvdUBwc2cuY29tJmd0OywgJnF1b3Q7J0FkcmlhbiBGYXJy
ZWwnJnF1b3Q7ICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgY2NhbXBAb3BzLmlldGYub3Jn
PC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj4gPEZPTlQgU0laRT0yPlN1
YmplY3Q6PC9GT05UPiA8Rk9OVCBTSVpFPTI+UkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQ
czwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIFNJWkU9ND5UaGVyZSBhcmUgdHdvIGNh
dGVnb3JpZXMgb2YgRXRoZXJuZXQgc3dpdGNoZXMgb3V0IHRoZXJlOjwvRk9OVD48QlI+PEJSPjxG
T05UIFNJWkU9ND4xKSBwdXJlIEwyIHN3aXRjaGVzIC0gZXhpc3RpbmcgSUVFRSAoLjFxKSBicmlk
Z2VzPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+MikgTDIvTDMgc3dpdGNoZXMgLSBjYXBhYmxlIG9m
IGJvdGggYnJpZGdpbmcgYW5kIE1QTFMvSVAgc3dpdGNoaW5nIChpbmNsdWRpbmcgc3VwcG9ydCBm
b3IgRW9NUExTKTwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND5Db25zaWRlcmluZyB0aGUgY3Vy
cmVudCBMMi9MMyBzd2l0Y2hlcyBjYW4gc3VwcG9ydCBQdFAgRXRoZXJuZXQgc2VydmljZXMgZW5k
LXRvLWVuZCBpbiBhIHNjYWxhYmxlIHdheSB1c2luZyBFb01QTFMsIHRoZW4gdGhlIHF1ZXN0aW9u
IGlzIHdoeSBkbyB3ZSBuZWVkIHlldCBhbm90aGVyIGFsdGVybmF0ZSBtZWNoYW5pc20gdG8gcHJv
dmlkZSB0aGUgc2FtZSBlbmQgc2VydmljZSB3aXRob3V0IGFueSBvYnZpb3VzIGJlbmVmaXQuIElz
IHNhdmluZyBhIGZldyBieXRlIGluIHRoZSBoZWFkZXIgdGhlIHByaW1hcnkgb2JqZWN0aXZlIGlu
IGhlcmUgPyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5JdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0
aGUgcHJvcG9zZWQgdXNlIG9mIEdNUExTIGNvbnRyb2wgcGxhbmUgaXMgbm90IGNvbXBhdGlibGUg
d2l0aCBlaXRoZXIgb2YgdGhlIGFib3ZlIHR3byBjYXRlZ29yeSBvZiBzd2l0Y2hlcyBhbmQgdGh1
cyBjYW5ub3QgYmUgbGV2ZXJhZ2VkIGJ5IHRoZW0uIDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9
ND4tQWxpPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PkF0IDEwOjA2IFBNIDEvMjgvMjAwNSAr
MDEwMCwgRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgd3JvdGU6PC9GT05UPjxCUj48
QlI+PEZPTlQgU0laRT00PnRoaXMgYSB2YXN0IHRvcGljIHRoYXQgY2FuIGJlIGFuc3dlcmVkIGlu
IHNldmVyYWwgd2F5cyAtIGhvd2V2ZXIgb25lIHNob3J0IHJlc3BvbnNlIGNhbiBiZSB3aHkgKHdo
ZW4geW91IGFyZSBub3QgaW4gYW4gSVAvTVBMUyBlbnZpcm9ubWVudCkgaXMgdGhlcmUgYW55IHJh
dGlvbmFsZSB0byBtYW5kYXRlIGFuIE1QTFMgdHJhbnNwb3J0IG5ldHdvcmsgdG8gY2FycnkgRXRo
ZXJuZXQgcGF5bG9hZCB3aGlsZSB0ZWNobmlxdWVzIGV4aXN0IHRvIGFjaGlldmUgdGhlIHNhbWUg
bGV2ZWwgb2YgY29udHJvbCB1c2luZyBHTVBMUyAoKikgd2l0aG91dCB0aGUgYnVyZGVuIG9mIGhh
dmluZyB0byBjb25zaWRlciB0aGUgY29zdCBvZiBhbiBhZGRpdGlvbmFsIElQL01QTFMgZGF0YSBw
bGFuZSBieSB1c2luZyBkaXJlY3RseSBhbiBFdGhlcm5ldCBkYXRhIHBsYW5lIC0gb25lIGV4YW1w
bGUgKGFtb25nIG1hbnkpIGlzIHRoZSBwb3NzaWJpbGl0eSB0byB1c2UgdGhlIE1BQyBsYXllciBk
aXJlY3RseSAob3ZlciBhbiBFdGhlcm5ldCBQSFkgZm9yIGluc3RhbmNlKSB3aXRob3V0IGhhdmlu
ZyB0byBjb25zaWRlciBhbiBFVEgtb3Zlci1QVy1vdmVyLU1QTFMgZW52aXJvbm1lbnQgd2hlcmUg
YXQgdGhlIGVuZCB5b3Ugd2lsbCBoYXZlIHRvIGNhcnJ5IHRoZSBNUExTIHBhY2tldHMgb3ZlciBh
bm90aGVyIGRhdGEgbGluayBsYXllciB0aGF0IGNvdWxkIGJlIHRoZSBFVEggTUFDIGxheWVyIGl0
c2VsZiA/PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PigqKSBpIHNob3VkIHNheSBldmVuIGJl
dHRlciBiZWNhdXNlIHRoZSBHTVBMUyBtZWNoYW5pc21zIGFuZCBhZGRlZCB2YWx1ZSBmb3IgcGFj
a2V0IChQU0MpIG5ldHdvcmtzIGFyZSAoc3RpbGwpIG5vdCB3aWRlbHkgY29uc2lkZXJlZCBhcyB0
aGUgZGUtZmFjdG8gY29udHJvbCBwbGFuZSBmb3Igc3VjaCBlbnZpcm9ubWVudHMgZXZlbiBpZiB3
ZSBob3BlIHRoaXMgd2lsbCBiZSB0aGUgY2FzZSB3aXRoIHRoZSAoTVBMUyB0byBHTVBMUykgbWln
cmF0aW9uIHBoYXNlIGZvciBQU0MgbmV0d29ya3MgdGhhdCBpcyBnb2luZyB0byBiZSAoaG9wZWZ1
bGx5KSBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgQ0NBTVAgY2hhcnRlciAtIHRoaXMgc2Fp
ZCB0aGUgY29udHJvbCBwbGFuZSBhc3NvY2lhdGVkIHRvIFBXIGlzIHN0aWxsIHJlc3RyaWN0ZWQg
dG8gTERQIHRoZXJlZm9yZSBpIGFtIG5vdCBzdXJlIHRoaXMgaXMgZXZlciBnb2luZyB0byBhY2hp
ZXZlIHRoZSBzYW1lIGxldmVsIG9mIGNvbnRyb2wgYW5kIGNhcGFiaWxpdGllcyB0aGFuIHRob3Nl
IGNvbnNpZGVyZWQgaW4gdGhlIHByZXNlbnQgTDJMU1AgY29udGV4dDwvRk9OVD48QlI+PEJSPjxC
Uj48Qj5TaGFocmFtIERhdmFyaSAmbHQ7U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5jb20mZ3Q7
PC9CPjxCUj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+MDEvMjgvMjAwNSAx
MjoxMiBQU1Q8QlI+PEJSPlRvOjxGT05UIFNJWkU9ND4gPC9GT05UPlNoYWhyYW0gRGF2YXJpICZs
dDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZndDssIERpbWl0cmkgUEFQQURJTUlUUklP
VS9CRS9BTENBVEVMQEFMQ0FURUwsIERhdmlkIEFsbGFuICZsdDtkYWxsYW5Abm9ydGVsbmV0d29y
a3MuY29tJmd0OzxCUj5jYzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD4mcXVvdDsnZHBhcGFkaW1pdHJp
b3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGltaXRyaW91QHBzZy5jb20mZ3Q7LCAmcXVvdDsn
QWRyaWFuIEZhcnJlbCcmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCBjY2FtcEBv
cHMuaWV0Zi5vcmc8QlI+YmNjOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj5TdWJqZWN0OjxGT05U
IFNJWkU9ND4gPC9GT05UPlJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8QlI+PEJSPjxC
Uj48Rk9OVCBTSVpFPTQ+U29ycnkgRGltaXRyaSw8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+
TGV0IG1lIGNvcnJlY3QgbXkgcHJldmlvdXMgZW1haWw6PC9GT05UPjxCUj48QlI+PEZPTlQgU0la
RT00PldoYXQgaXMgdGhlIGFwcGxpY2F0aW9uIGRyaXZpbmcgdGhlIGNoYW5nZSBvZiB0aGUgRXRo
ZXJuZXQgc3dpdGNoIGNvbnRyb2wtcGxhbmUgdG8gR01QTFMuJm5ic3A7IFdoeSBub3QganVzdCBk
byBFdGhlcm5ldCBvdmVyIE1QTFM/PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pi1TaGFocmFt
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9ND48Qj5Gcm9tOjwvQj4gb3duZXItY2NhbXBAb3BzLmlldGYub3JnIDwv
Rk9OVD48Rk9OVCBTSVpFPTQgQ09MT1I9QkxVRT48VT48QSBIUkVGPW1haWx0bzpvd25lci1jY2Ft
cEBvcHMuaWV0Zi5vcmclNURPbj5tYWlsdG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXTwvQT48
L1U+PEI+PFU+T248L1U+PC9CPjxVPjxBIEhSRUY9bnVsbD4gQmVoYWxmIE9mIDwvQT48L1U+PC9G
T05UPjxGT05UIFNJWkU9NCBDT0xPUj1CTEFDSz48QSBIUkVGPW51bGw+U2hhaHJhbSBEYXZhcmk8
L0E+PC9GT05UPjxBIEhSRUY9bnVsbD48QlI+PEZPTlQgU0laRT00PjxCPlNlbnQ6PC9CPiBGcmlk
YXksIEphbnVhcnkgMjgsIDIwMDUgMjo1MCBQTTwvRk9OVD48QlI+PEZPTlQgU0laRT00PjxCPlRv
OjwvQj4gJ0RpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlJzsgRGF2aWQgQWxsYW48L0ZP
TlQ+PEJSPjxGT05UIFNJWkU9ND48Qj5DYzo8L0I+ICdkcGFwYWRpbWl0cmlvdUBwc2cuY29tJzsg
J0FkcmlhbiBGYXJyZWwnOyBjY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9
ND48Qj5TdWJqZWN0OjwvQj4gUkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczwvRk9OVD48
QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+RGltaXRyaSw8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpF
PTQ+V2hhdCB0aGUgYXBwbGljYXRpb24gZGVyaXZpbmcgY2hhbmdpbmcgdGhlIEV0aGVybmV0IHN3
aXRjaCBkYXRhLXBsYW5lIHRvIEdNUExTLiZuYnNwOyBXaHkgbm90IGRvIEV0aGVybmV0IG92ZXIg
TVBMUz88L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+LVNoYWhyYW08L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48QlI+PEZPTlQgU0laRT00
PjxCPkZyb206PC9CPiBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSA8L0ZPTlQ+PC9B
PjxGT05UIFNJWkU9NCBDT0xPUj1CTFVFPjxVPm1haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VA
YWxjYXRlbC5iZTwvVT48L0ZPTlQ+PEZPTlQgU0laRT00IENPTE9SPUJMQUNLPjxBIEhSRUY9bnVs
bD5dPC9BPjwvRk9OVD48QSBIUkVGPW51bGw+PEJSPjxGT05UIFNJWkU9ND48Qj5TZW50OjwvQj4g
RnJpZGF5LCBKYW51YXJ5IDI4LCAyMDA1IDI6MTggUE08L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND48
Qj5Ubzo8L0I+IERhdmlkIEFsbGFuPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+PEI+Q2M6PC9CPiAn
RGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUnOyAnZHBhcGFkaW1pdHJpb3VAcHNnLmNv
bSc7ICdBZHJpYW4gRmFycmVsJzsgU2hhaHJhbSBEYXZhcmk7IGNjYW1wQG9wcy5pZXRmLm9yZzwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PjxCPlN1YmplY3Q6PC9CPiBSRTogTGF5ZXIgMiBTd2l0Y2hp
bmcgQ2FwcyBMU1BzPC9GT05UPjxCUj48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+ZGF2ZSAtIHNl
ZSBpbi1saW5lIDwvRk9OVD48QlI+PEJSPjxGT05UIFNJWkU9ND48Qj4mcXVvdDtEYXZpZCBBbGxh
biZxdW90OyAmbHQ7ZGFsbGFuQG5vcnRlbG5ldHdvcmtzLmNvbSZndDs8L0I+PC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+U2VudCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+MDEvMjgvMjAwNSAxMzo1NCBFU1Q8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpF
PTQ+VG86PC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxGT05UIFNJWkU9ND5EaW1pdHJpIFBB
UEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENBVEVMPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Y2M6
PC9GT05UPjxGT05UIFNJWkU9NT4gPC9GT05UPjxGT05UIFNJWkU9ND4mcXVvdDsnZHBhcGFkaW1p
dHJpb3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGltaXRyaW91QHBzZy5jb20mZ3Q7LCAmcXVv
dDsnQWRyaWFuIEZhcnJlbCcmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7LCAmcXVv
dDsnU2hhaHJhbSBEYXZhcmknJnF1b3Q7ICZsdDtTaGFocmFtX0RhdmFyaUBwbWMtc2llcnJhLmNv
bSZndDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT00PmJjYzo8L0ZP
TlQ+PEZPTlQgU0laRT01PiA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND5TdWJqZWN0OjwvRk9OVD48
Rk9OVCBTSVpFPTU+IDwvRk9OVD48Rk9OVCBTSVpFPTQ+UkU6IExheWVyIDIgU3dpdGNoaW5nIENh
cHMgTFNQczwvRk9OVD48QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTU+SGkgRGltaXRyaTo8L0ZPTlQ+
PEZPTlQgU0laRT02PiA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+Jmd0OyZuYnNwOyBvbiZu
YnNwOyB0aGUgb3RoZXIgc2lkZSwgdGhlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtWTEFOIGxhYmVs
JnF1b3Q7IGhhcyBjcmVhdGVkIHNvbWUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0OyBjb25m
dXNpb247IHRoZXJlZm9yZSwgaW4gYSBuZXh0IHJlbGVhc2UgaSB3aWxsIHNpbXBseSByZWZlciA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7IHRvIGEgJnF1b3Q7bGFiZWwmcXVvdDsgPC9GT05U
PjxCUj48Rk9OVCBTSVpFPTU+Jmd0OyBvZiAzMiBiaXRzICh1bnN0cnVjdHVyZWQpIGJlY2F1c2Ug
dGhlIGludGVudGlvbiB3YXMgKGFuZCBzdGlsbCBpcykgdG8gPC9GT05UPjxCUj48Rk9OVCBTSVpF
PTU+Jmd0OyBmaW5kIGFuIGVhc3kgd2F5IHRvIG1hcCB0aGUgY29udHJvbCBvZiB0aGUgZXRoZXJu
ZXQgZnJhbWUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+Jmd0OyBmbG93cyBvbiBlYWNoIDwvRk9O
VD48QlI+PEZPTlQgU0laRT01PiZndDsgZGV2aWNlIHRoZXkgdHJhdmVyc2VzIHdpdGhvdXQgbWFr
aW5nIGFueSBhc3N1bXB0aW9uIG9uIGhvdyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7IHRo
aXMgZmxvdyBpcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7IHByb2Nlc3NlZCBpbnNpZGUg
ZWFjaCBub2RlIGF0IHRoZSBkYXRhIHBsYW5lIGxldmVsIChub3RlOiBvbiBsYWJlbCA8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9NT4mZ3Q7IHZhbHVlcywgUkZDIDM5NDYgdG9vayBhbiBlcXVpdmFsZW50
IGFwcHJvYWNoIC0gZm9yIGNpcmN1aXRzIC0gd2hlcmUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTU+
Jmd0OyBzb25ldC9zZGggbXVsdGlwbGV4aW5nIHN0cnVjdHVyZXMgaGF2ZSBiZWVuIHVzZWQgdG8g
Y3JlYXRlIHVuaXF1ZSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9NT4mZ3Q7IG11bHRpcGxleCBlbnRy
eSBuYW1lcyBpLmUuIGxhYmVscyAtIHRoaXMgY29uY2VwdCBpcyBoZXJlIGFwcGxpZWQgZm9yIDwv
Rk9OVD48QlI+PEZPTlQgU0laRT01PiZndDsgJnF1b3Q7dmlydHVhbCZxdW90OyBjaXJjdWl0cyks
IHNvLCBpZiB0aGUgd29ya2luZyBncm91cCBpcyB3aWxsaW5nIHRvIDwvRk9OVD48QlI+PEZPTlQg
U0laRT01PiZndDsgZW50ZXIgaW50byBhIDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDsgZGF0
YSBwbGFuZSBvcmllbnRlZCBkaXNjdXNzaW9uIHRvIGNsYXJpZnkgdGhlIGJlaGF2aW91cihzKSBv
bnRvIHdoaWNoIDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDsgdGhlIHByZXNlbnQgYXBwcm9h
Y2ggd291bGQgYmUgcG90ZW50aWFsbHkgYXBwbGljYWJsZSB0aGlzIGlzIDwvRk9OVD48QlI+PEZP
TlQgU0laRT01PiZndDsgZmluZSB3aXRoIDwvRk9OVD48QlI+PEZPTlQgU0laRT01PiZndDsgbWUg
YXMgbG9uZyBhcyB3ZSBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgaW5pdGlhbCBtb3RpdmF0
aW9ucyA8L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+U28gaWYgSSB1bmRlcnN0YW5kIGNvcnJl
Y3RseSB0aGVyZSBpcyBhbiBhYnN0cmFjdCBsYWJlbCB0aGF0IHJlcHJlc2VudHMgYSBmbG93IGF0
IGFuIGludGVybWVkaWF0ZSBkZXZpY2UgYnV0IHdpdGggbWFraW5nIG5vIHJlcHJlc2VudGF0aW9u
cyBhcyB0byBob3cgdGhlIGZsb3cgdHJhbnNpdHMgdGhlIGRldmljZS4gQXMgdGhlIGFic3RyYWN0
IGxhYmVsIGlzIG5vdCB0aWVkIGRpcmVjdGx5IHRvIGFueSByZWFsIGltcGxlbWVudGF0aW9uIGJ1
dCBpcyBtZXJlbHkgYSB1c2VmdWwgaWRlbnRpZmllciB0byBhbGxvdyB0d28gTFNIcyBvZiB0aGUg
TFNQIHRvIGJlIHRpZWQgdG9nZXRoZXIsIFNvIGl0IGlzIG5vdCBhIGxhYmVsIGluIHRoZSBzZW5z
ZSB0aGF0IHRoZXJlIGlzIG5vdCBhIGxvZ2ljYWwgZGF0YXBsYW5lIGlkZW50aWZpZXIgaW4gdGhl
IHBhY2tldCBlbmNhcHN1bGF0aW9uLCBub3IgZG9lcyBpdCBjb3JyZXNwb25kIHRvIGEgdGltZXNs
b3QgZXRjLiBEbyBJIGhhdmUgdGhpcyByaWdodD88L0ZPTlQ+PEJSPjxCUj48Rk9OVCBTSVpFPTU+
LSZndDsgbW9yZSBwcmVjaXNlbHkgdGhlIGRyYWZ0IGRvZXMgbm90IG1hbmRhdGUgYW55IHNwZWNp
ZmljIHJlcHJlc2VudGF0aW9uIGF0IHRoZSBkYXRhIHBsYW5lIGxldmVsIChzbyB0aGUgbGFzdCBz
dGF0ZW1lbnQgZ29lcyBhIHN0ZXAgYmV5b25kIG15IHN0YXRlbWVudCkgLSBpbiBwYXJ0aWN1bGFy
IHRoaXMgcmVwcmVzZW50YXRpb24gZG9lcyBub3QgYXNzdW1lIGEgbW9kaWZpY2F0aW9uIG9mIHRo
ZSBldGhlcm5ldCBmcmFtZSBmb3JtYXQgLSB0aGlzIGZvbGxvd3MgdGhlIGFwcHJvYWNoIG9mIFJG
QyAzNDcxIHdoZXJlIHRoZSB3YXZlbGVuZ3RoIGxhYmVsIGZvciBpbnN0YW5jZSBpcyBzaW1wbHkg
YSAzMi1iaXQgdmFsdWUgdGhhdCBpcyBpbnRlcnByZXRlZCBsb2NhbGx5IChhZnRlciBuZWdvdGlh
dGlvbikgYnV0IHllcyB0aGlzIGFic3RyYWN0aW9uIGRvZXMgbm90IG1hbmRhdGUgYW4gZXhhY3Qg
MToxIHJlcHJlc2VudGF0aW9uIHdpdGggdGhlIGV0aGVybmV0IGRhdGEgcGxhbmUgKGluIGZhY3Qg
dGhlIGluaXRpYWwgZG9jdW1lbnQgc3VnZ2VzdGVkIG9uZSBzdWNoIHJlcHJlc2VudGF0aW9uIGJ1
dCBpdCBzZWVtcyB0aGF0IHVzaW5nIHNwZWNpZmljIHRlcm1zIGNyZWF0ZXMgc29tZSBjb25mdXNp
b24pPC9GT05UPjxCUj48QlI+PEJSPjxGT05UIFNJWkU9NT5EYXZlPC9GT05UPjxGT05UIFNJWkU9
Nj4gPC9GT05UPjwvQT48L1A+



Envelope-to: [e-mail]
Delivery-date: Sat, 29 Jan 2005 00:01:23 +0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50595.BF41F866"
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 00:01:56 -0000
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUFddCnYH3s/tNoQ0S7iojy67yefwACSHvAAAM78ZA=
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

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

Deborah I am a little unclear on a few things here....please see
in-line:
=20
 -----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: 28 January 2005 22:10
To: Shahram Davari; [e-mail]; David Allan
Cc: [e-mail]; Adrian Farrel; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Hi Shahram,
=20
Thanks for all the interest, as Dimitri doesn't seem to be available
today, I'll do my best French to answer-
=20
The use of GMPLS for Ethernet is a very different application than
Ethernet over MPLS.=20
NH=3D> So its must be OOB yes?...which is a key corollary of GMPLS.  So =
is
OOB is a key driver then, as it sure is a consequence?
=20
  It not only provides a control plane which may be used for L2SC,  it
also provides the capability to support an end-to-end L2 LSP automated
set up across GMPLS regions =20
NH=3D> Is there a good definition of what a 'GMPLS region' is as I don't
know what this means.....is it perhaps one where there is no MPLS?
=20
 (e.g. Ethernet/GFP_SONET which I recalled mentioned on an earlier
mail). The GMPLS architecture document describes the benefits for using
GMPLS with PSC and L2SC. This draft was not intended to introduce any
new switching capabilities than already discussed in gmpls-arch,
RFC3471, RFC3473. We hoped with the draft to be proactive in detailing
the use of GMPLS signaling for L2 LSPs (with the hopes of preventing
mis-interpretations). We all are aware of the current market interest on
Ethernet.=20
NH=3D> Are you meaning native ethernet or something else?
=20
  Considering the discussion, the draft has definitely initiated
discussion.=20
NH=3D> Its sure created some confusion......and I don't think you have
really answered Shahram's question, which to remind you was:  Why GPMLS
and not over MPLS?   Can you please be precise as to what are the key
drivers/requirements here as I am struggling to grasp the intent.  The
seemingly obvious ones are that if we have GMPLS we don't need MPLS at
all here and we can use an OOB control-plane....is that correct?=20
=20
Dave - also thanks - I'll let Dimitri answer in detail, though one
comment on Ethernet OAM. The use of GMPLS as a control plane for
Ethernet is the same as GMPLS for SONET (or GMPLS for LSC) with regards
to data plane monitoring.=20
NH=3D> Since  GMPLS is nothing more that an OOB control-plane, and SDH,
for example, has its own data-plane OAM which has nothing to do with the
control-plane, you must therefore be saying that the OAM is 'whatever is
specified for ethernet'.....because there is no MPLS data-plane.  Is
that right....seems to be?
=20
thanks....regards, Neil=20
=20
Deborah

  _____ =20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Sorry Dimitri,
=20
Let me correct my previous email:
=20

What is the application driving the change of the Ethernet switch
control-plane to GMPLS.  Why not just do Ethernet over MPLS?
=20
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Dimitri,
=20
What the application deriving changing the Ethernet switch data-plane to
GMPLS.  Why not do Ethernet over MPLS?
=20
-Shahram

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: '[e-mail]'; '[e-mail]';
'Adrian Farrel'; Shahram Davari; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



dave - see in-line=20

"David Allan" <[e-mail]>
Sent by: [e-mail]
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'[e-mail]'" <[e-mail]>, "'Adrian
Farrel'" <[e-mail]>, "'Shahram Davari'"
<[e-mail]>, [e-mail]
bcc:=20
Subject: RE: Layer 2 Switching Caps LSPs




Hi Dimitri:=20

>  on  the other side, the use of the term "VLAN label" has created some

> confusion; therefore, in a next release i will simply refer=20
> to a "label"=20
> of 32 bits (unstructured) because the intention was (and still is) to=20
> find an easy way to map the control of the ethernet frame=20
> flows on each=20
> device they traverses without making any assumption on how=20
> this flow is=20
> processed inside each node at the data plane level (note: on label=20
> values, RFC 3946 took an equivalent approach - for circuits - where=20
> sonet/sdh multiplexing structures have been used to create unique=20
> multiplex entry names i.e. labels - this concept is here applied for=20
> "virtual" circuits), so, if the working group is willing to=20
> enter into a=20
> data plane oriented discussion to clarify the behaviour(s) onto which=20
> the present approach would be potentially applicable this is=20
> fine with=20
> me as long as we are within the scope of the initial motivations=20

So if I understand correctly there is an abstract label that represents
a flow at an intermediate device but with making no representations as
to how the flow transits the device. As the abstract label is not tied
directly to any real implementation but is merely a useful identifier to
allow two LSHs of the LSP to be tied together, So it is not a label in
the sense that there is not a logical dataplane identifier in the packet
encapsulation, nor does it correspond to a timeslot etc. Do I have this
right?


-> more precisely the draft does not mandate any specific representation
at the data plane level (so the last statement goes a step beyond my
statement) - in particular this representation does not assume a
modification of the ethernet frame format - this follows the approach of
RFC 3471 where the wavelength label for instance is simply a 32-bit
value that is interpreted locally (after negotiation) but yes this
abstraction does not mandate an exact 1:1 representation with the
ethernet data plane (in fact the initial document suggested one such
representation but it seems that using specific terms creates some
confusion)


Dave=20


------_=_NextPart_001_01C50595.BF41F866
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D602205122-28012005><FONT face=3D"Comic Sans MS" =
color=3D#800000=20
size=3D2>Deborah I am a little unclear on a few things here....please =
see=20
in-line:</FONT></SPAN></DIV>
<DIV><SPAN class=3D602205122-28012005></SPAN><FONT face=3DTahoma><FONT =
size=3D2><SPAN=20
class=3D602205122-28012005><FONT face=3D"Comic Sans MS"=20
color=3D#800000></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D602205122-28012005>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] <B>On Behalf =
Of=20
</B>Brungard, Deborah A, ALABS<BR><B>Sent:</B> 28 January 2005=20
22:10<BR><B>To:</B> Shahram Davari; [e-mail]; =
David=20
Allan<BR><B>Cc:</B> [e-mail]; Adrian Farrel;=20
[e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps=20
LSPs<BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #800000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Hi Shahram,</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>Thanks for all the interest, as Dimitri =
doesn't seem to=20
  be available today, I'll do my best French to =
answer-</FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2>The use of GMPLS for Ethernet is a very =
different=20
  application than Ethernet over MPLS.<SPAN =
class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" =
color=3D#800000>&nbsp;</FONT></SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN class=3D602205122-28012005><FONT =
face=3D"Comic Sans MS"=20
  color=3D#800000>NH=3D&gt; So its must be OOB yes?...which is a key =
corollary of=20
  GMPLS.&nbsp; So is&nbsp;OOB is a key driver then, as it sure is a=20
  consequence?</FONT></SPAN></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2><SPAN=20
  class=3D602205122-28012005></SPAN></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D602205122-28012005>&nbsp;</SPAN> It not=20
  only provides a control plane which may be used for L2SC,<SPAN=20
  class=3D602205122-28012005><FONT face=3D"Comic Sans MS"=20
  color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN><SPAN=20
  class=3D389441821-28012005><FONT face=3DArial color=3D#0000ff><FONT =
size=3D2> it also=20
  provides the capability to support an end-to-end L2 LSP automated set =
up=20
  across GMPLS regions&nbsp;<SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS"=20
  color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" color=3D#800000>NH=3D&gt; Is there a good =
definition of what=20
  a 'GMPLS region' is as I don't&nbsp;know what this means.....is it =
perhaps one=20
  where there is no MPLS?</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D602205122-28012005></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D602205122-28012005>&nbsp;</SPAN>(e.g.=20
  Ethernet/GFP_SONET which I recalled mentioned on an earlier mail). The =
GMPLS=20
  architecture document describes the benefits for using GMPLS with PSC =
and=20
  L2SC. This draft was not intended to introduce any new switching =
capabilities=20
  than already discussed in gmpls-arch, RFC3471, RFC3473. We hoped with =
the=20
  draft to be proactive in detailing the use of GMPLS signaling for L2 =
LSPs=20
  (with the hopes of preventing mis-interpretations). We all are aware =
of the=20
  current market interest&nbsp;on&nbsp;Ethernet.<SPAN=20
  class=3D602205122-28012005><FONT face=3D"Comic Sans MS"=20
  color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" color=3D#800000>NH=3D&gt; Are you meaning =
native ethernet or=20
  something else?</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN=20
  class=3D602205122-28012005></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN =
class=3D602205122-28012005>&nbsp;</SPAN>=20
  Considering the discussion, the draft has definitely initiated=20
  discussion.<SPAN class=3D602205122-28012005><FONT face=3D"Comic Sans =
MS"=20
  color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" color=3D#800000>NH=3D&gt; Its sure created some =

  confusion......and I don't think you have really answered Shahram's =
question,=20
  which to remind you was:&nbsp; Why GPMLS and not over =
MPLS?</FONT>&nbsp;<FONT=20
  face=3D"Comic Sans MS" color=3D#800000>&nbsp; Can you please be =
precise as to what=20
  are the key drivers/requirements here as I am struggling to grasp the=20
  intent.&nbsp; The seemingly obvious ones are that if we have GMPLS we =
don't=20
  need MPLS at all here and we can use an OOB control-plane....is that=20
  correct?&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2>Dave - also thanks - I'll let Dimitri =
answer in=20
  detail, though one comment on Ethernet OAM. The use of GMPLS as a =
control=20
  plane for Ethernet is the same as&nbsp;GMPLS for SONET (or GMPLS for =
LSC) with=20
  regards to data plane monitoring.<SPAN =
class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS"=20
  color=3D#800000>&nbsp;</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" color=3D#800000>NH=3D&gt;&nbsp;Since&nbsp; =
GMPLS is nothing=20
  more that an OOB control-plane, and SDH, for example, has its&nbsp;own =

  data-plane OAM&nbsp;which has nothing&nbsp;to do with the =
control-plane, you=20
  must therefore be saying that the OAM is 'whatever is specified for=20
  ethernet'.....because there is no MPLS data-plane.&nbsp; Is that=20
  right....seems to be?</FONT></SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT face=3D"Comic Sans MS" color=3D#800000 =
size=3D2><SPAN=20
  class=3D602205122-28012005></SPAN></FONT></FONT></SPAN><SPAN=20
  class=3D389441821-28012005><FONT face=3DArial color=3D#0000ff><FONT =
size=3D2><SPAN=20
  class=3D602205122-28012005></SPAN></FONT></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff><FONT size=3D2><SPAN class=3D602205122-28012005><FONT=20
  face=3D"Comic Sans MS" color=3D#800000>thanks....regards,=20
  Neil</FONT>&nbsp;</SPAN></FONT></FONT></SPAN></DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><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> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of </B>Shahram=20
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 3:12 PM<BR><B>To:</B> =
Shahram=20
  Davari; '[e-mail]'; David Allan<BR><B>Cc:</B>=20
  '[e-mail]'; 'Adrian Farrel';=20
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps=20
  LSPs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=3D122481020-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Sorry Dimitri,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D122481020-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D122481020-28012005><FONT face=3DArial =
color=3D#0000ff size=3D2>Let=20
  me correct my previous email:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D122481020-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D122481020-28012005>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>What&nbsp;<SPAN class=3D122481020-28012005>is </SPAN>the =
application=20
  driving&nbsp;<SPAN class=3D122481020-28012005>the </SPAN>chang<SPAN=20
  class=3D122481020-28012005>e</SPAN>&nbsp;<SPAN =
class=3D122481020-28012005>of=20
  </SPAN>the Ethernet switch&nbsp;<SPAN=20
  class=3D122481020-28012005>control</SPAN>-plane to GMPLS.&nbsp; Why =
not <SPAN=20
  class=3D122481020-28012005>just do </SPAN>Ethernet over=20
MPLS?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982584819-28012005><SPAN =
class=3D122481020-28012005><FONT=20
  face=3DArial color=3D#0000ff=20
  size=3D2>-Shahram</FONT></SPAN></SPAN></DIV></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> =
[e-mail]=20
    [mailto:[e-mail]]<B>On Behalf Of </B>Shahram=20
    Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 =
PM<BR><B>To:</B>=20
    '[e-mail]'; David Allan<BR><B>Cc:</B>=20
    '[e-mail]'; 'Adrian Farrel';=20
    [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps=20
    LSPs<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Dimitri,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>What the application deriving changing the Ethernet switch =
data-plane=20
    to GMPLS.&nbsp; Why not do Ethernet over MPLS?</FONT></SPAN></DIV>
    <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>-Shahram</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>=20
      [e-mail]=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Friday, =
January=20
      28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B>=20
      '[e-mail]'; '[e-mail]'; =
'Adrian=20
      Farrel'; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: =
Layer 2=20
      Switching Caps LSPs<BR><BR></FONT></DIV>
      <P>dave - see in-line <BR><BR><FONT size=3D2><B>"David Allan"=20
      &lt;[e-mail]&gt;</B></FONT><BR><FONT =
size=3D2>Sent by:=20
      [e-mail]</FONT><BR><FONT size=3D2>01/28/2005 13:54 =

      EST</FONT><BR><BR><FONT size=3D2>To:</FONT> <FONT size=3D2>Dimitri =

      PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT =
size=3D2>cc:</FONT> <FONT=20
      size=3D2>"'[e-mail]'" =
&lt;[e-mail]&gt;, "'Adrian=20
      Farrel'" &lt;[e-mail]&gt;, "'Shahram Davari'"=20
      &lt;[e-mail]&gt;, =
[e-mail]</FONT><BR><FONT=20
      size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>RE: Layer=20
      2 Switching Caps LSPs</FONT><BR><BR><BR></P>
      <P>Hi Dimitri:<FONT size=3D4> </FONT><BR><FONT =
size=3D4></FONT><BR>&gt;&nbsp;=20
      on&nbsp; the other side, the use of the term "VLAN label" has =
created some=20
      <BR>&gt; confusion; therefore, in a next release i will simply =
refer=20
      <BR>&gt; to a "label" <BR>&gt; of 32 bits (unstructured) because =
the=20
      intention was (and still is) to <BR>&gt; find an easy way to map =
the=20
      control of the ethernet frame <BR>&gt; flows on each <BR>&gt; =
device they=20
      traverses without making any assumption on how <BR>&gt; this flow =
is=20
      <BR>&gt; processed inside each node at the data plane level (note: =
on=20
      label <BR>&gt; values, RFC 3946 took an equivalent approach - for =
circuits=20
      - where <BR>&gt; sonet/sdh multiplexing structures have been used =
to=20
      create unique <BR>&gt; multiplex entry names i.e. labels - this =
concept is=20
      here applied for <BR>&gt; "virtual" circuits), so, if the working =
group is=20
      willing to <BR>&gt; enter into a <BR>&gt; data plane oriented =
discussion=20
      to clarify the behaviour(s) onto which <BR>&gt; the present =
approach would=20
      be potentially applicable this is <BR>&gt; fine with <BR>&gt; me =
as long=20
      as we are within the scope of the initial motivations <BR><BR>So =
if I=20
      understand correctly there is an abstract label that represents a =
flow at=20
      an intermediate device but with making no representations as to =
how the=20
      flow transits the device. As the abstract label is not tied =
directly to=20
      any real implementation but is merely a useful identifier to allow =
two=20
      LSHs of the LSP to be tied together, So it is not a label in the =
sense=20
      that there is not a logical dataplane identifier in the packet=20
      encapsulation, nor does it correspond to a timeslot etc. Do I have =
this=20
      right?<BR></P>
      <P>-&gt; more precisely the draft does not mandate any specific=20
      representation at the data plane level (so the last statement goes =
a step=20
      beyond my statement) - in particular this representation does not =
assume a=20
      modification of the ethernet frame format - this follows the =
approach of=20
      RFC 3471 where the wavelength label for instance is simply a =
32-bit value=20
      that is interpreted locally (after negotiation) but yes this =
abstraction=20
      does not mandate an exact 1:1 representation with the ethernet =
data plane=20
      (in fact the initial document suggested one such representation =
but it=20
      seems that using specific terms creates some confusion)</P>
      <P><BR>Dave<FONT size=3D4>=20
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50595.BF41F866--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 23:51:56 +0000
Message-Id: <[e-mail]>
Date: Fri, 28 Jan 2005 15:49:51 -0800
To: [e-mail], Shahram Davari <[e-mail]>
From: Ali Sajassi <[e-mail]>
Subject: RE: Layer 2 Switching Caps LSPs
Cc: Shahram Davari <[e-mail]>, "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_671827997==_.ALT"

--=====================_671827997==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


There are two categories of Ethernet switches out there:

1) pure L2 switches - existing IEEE (.1q) bridges
2) L2/L3 switches - capable of both bridging and MPLS/IP switching 
(including support for EoMPLS)

Considering the current L2/L3 switches can support PtP Ethernet services 
end-to-end in a scalable way using EoMPLS, then the question is why do we 
need yet another alternate mechanism to provide the same end service 
without any obvious benefit. Is saving a few byte in the header the primary 
objective in here ?
It should be noted that the proposed use of GMPLS control plane is not 
compatible with either of the above two category of switches and thus 
cannot be leveraged by them.

-Ali

At 10:06 PM 1/28/2005 +0100, [e-mail] wrote:

>this a vast topic that can be answered in several ways - however one short 
>response can be why (when you are not in an IP/MPLS environment) is there 
>any rationale to mandate an MPLS transport network to carry Ethernet 
>payload while techniques exist to achieve the same level of control using 
>GMPLS (*) without the burden of having to consider the cost of an 
>additional IP/MPLS data plane by using directly an Ethernet data plane - 
>one example (among many) is the possibility to use the MAC layer directly 
>(over an Ethernet PHY for instance) without having to consider an 
>ETH-over-PW-over-MPLS environment where at the end you will have to carry 
>the MPLS packets over another data link layer that could be the ETH MAC 
>layer itself ?
>
>(*) i shoud say even better because the GMPLS mechanisms and added value 
>for packet (PSC) networks are (still) not widely considered as the 
>de-facto control plane for such environments even if we hope this will be 
>the case with the (MPLS to GMPLS) migration phase for PSC networks that is 
>going to be (hopefully) in the next revision of the CCAMP charter - this 
>said the control plane associated to PW is still restricted to LDP 
>therefore i am not sure this is ever going to achieve the same level of 
>control and capabilities than those considered in the present L2LSP context
>
>
>Shahram Davari <[e-mail]>
>Sent by: [e-mail]
>01/28/2005 12:12 PST
>
>To: Shahram Davari <[e-mail]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[e-mail]>
>cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" 
><[e-mail]>, [e-mail]
>bcc:
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>Sorry Dimitri,
>
>Let me correct my previous email:
>
>What is the application driving the change of the Ethernet switch 
>control-plane to GMPLS.  Why not just do Ethernet over MPLS?
>
>-Shahram
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf 
>Of Shahram Davari
>Sent: Friday, January 28, 2005 2:50 PM
>To: '[e-mail]'; David Allan
>Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>Dimitri,
>
>What the application deriving changing the Ethernet switch data-plane to 
>GMPLS.  Why not do Ethernet over MPLS?
>
>-Shahram
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]]
>Sent: Friday, January 28, 2005 2:18 PM
>To: David Allan
>Cc: '[e-mail]'; '[e-mail]'; 'Adrian 
>Farrel'; Shahram Davari; [e-mail]
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>
>dave - see in-line
>
>"David Allan" <[e-mail]>
>Sent by: [e-mail]
>01/28/2005 13:54 EST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" 
><[e-mail]>, "'Shahram Davari'" <[e-mail]>, 
>[e-mail]
>bcc:
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>Hi Dimitri:
>
> >  on  the other side, the use of the term "VLAN label" has created some
> > confusion; therefore, in a next release i will simply refer
> > to a "label"
> > of 32 bits (unstructured) because the intention was (and still is) to
> > find an easy way to map the control of the ethernet frame
> > flows on each
> > device they traverses without making any assumption on how
> > this flow is
> > processed inside each node at the data plane level (note: on label
> > values, RFC 3946 took an equivalent approach - for circuits - where
> > sonet/sdh multiplexing structures have been used to create unique
> > multiplex entry names i.e. labels - this concept is here applied for
> > "virtual" circuits), so, if the working group is willing to
> > enter into a
> > data plane oriented discussion to clarify the behaviour(s) onto which
> > the present approach would be potentially applicable this is
> > fine with
> > me as long as we are within the scope of the initial motivations
>
>So if I understand correctly there is an abstract label that represents a 
>flow at an intermediate device but with making no representations as to 
>how the flow transits the device. As the abstract label is not tied 
>directly to any real implementation but is merely a useful identifier to 
>allow two LSHs of the LSP to be tied together, So it is not a label in the 
>sense that there is not a logical dataplane identifier in the packet 
>encapsulation, nor does it correspond to a timeslot etc. Do I have this right?
>
>-> more precisely the draft does not mandate any specific representation 
>at the data plane level (so the last statement goes a step beyond my 
>statement) - in particular this representation does not assume a 
>modification of the ethernet frame format - this follows the approach of 
>RFC 3471 where the wavelength label for instance is simply a 32-bit value 
>that is interpreted locally (after negotiation) but yes this abstraction 
>does not mandate an exact 1:1 representation with the ethernet data plane 
>(in fact the initial document suggested one such representation but it 
>seems that using specific terms creates some confusion)
>
>
>Dave

--=====================_671827997==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
There are two categories of Ethernet switches out there:<br>
<br>
1) pure L2 switches - existing IEEE (.1q) bridges<br>
2) L2/L3 switches - capable of both bridging and MPLS/IP switching
(including support for EoMPLS)<br>
<br>
Considering the current L2/L3 switches can support PtP Ethernet services
end-to-end in a scalable way using EoMPLS, then the question is why do we
need yet another alternate mechanism to provide the same end service
without any obvious benefit. Is saving a few byte in the header the
primary objective in here ? <br>
It should be noted that the proposed use of GMPLS control plane is not
compatible with either of the above two category of switches and thus
cannot be leveraged by them. <br>
<br>
-Ali<br>
&nbsp;<br>
At 10:06 PM 1/28/2005 +0100, [e-mail] 
wrote:<br>
<br>
<blockquote type=cite cite>this a vast topic that can be answered in
several ways - however one short response can be why (when you are not in
an IP/MPLS environment) is there any rationale to mandate an MPLS
transport network to carry Ethernet payload while techniques exist to
achieve the same level of control using GMPLS (*) without the burden of
having to consider the cost of an additional IP/MPLS data plane by using
directly an Ethernet data plane - one example (among many) is the
possibility to use the MAC layer directly (over an Ethernet PHY for
instance) without having to consider an ETH-over-PW-over-MPLS environment
where at the end you will have to carry the MPLS packets over another
data link layer that could be the ETH MAC layer itself ?<br>
<br>
(*) i shoud say even better because the GMPLS mechanisms and added value
for packet (PSC) networks are (still) not widely considered as the
de-facto control plane for such environments even if we hope this will be
the case with the (MPLS to GMPLS) migration phase for PSC networks that
is going to be (hopefully) in the next revision of the CCAMP charter -
this said the control plane associated to PW is still restricted to LDP
therefore i am not sure this is ever going to achieve the same level of
control and capabilities than those considered in the present L2LSP
context<br>
<br>
<br>
<font size=2><b>Shahram Davari
&lt;[e-mail]&gt;</b></font><br>
<font size=2>Sent by: [e-mail]</font><br>
<font size=2>01/28/2005 12:12 PST</font><br>
<br>
<font size=2>To:</font> <font size=2>Shahram Davari
&lt;[e-mail]&gt;, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan
&lt;[e-mail]&gt;</font><br>
<font size=2>cc:</font> <font size=2>&quot;'[e-mail]'&quot;
&lt;[e-mail]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[e-mail]&gt;, [e-mail]</font><br>
<font size=2>bcc:</font> <br>
<font size=2>Subject:</font> <font size=2>RE: Layer 2 Switching Caps
LSPs</font><br>
<br>
<br>
Sorry Dimitri,<br>
<br>
Let me correct my previous email:<br>
<br>
What is the application driving the change of the Ethernet switch
control-plane to GMPLS.&nbsp; Why not just do Ethernet over MPLS?<br>
<br>
-Shahram<br>
-----Original Message-----<br>
<b>From:</b> [e-mail]
[<a href="mailto:[e-mail]%5DOn" eudora="autourl">mailto:[e-mail]]</a><a href="mailto:[e-mail]%5DOn" eudora="autourl"><b>On</a>
Behalf Of </b>Shahram Davari<br>
<b>Sent:</b> Friday, January 28, 2005 2:50 PM<br>
<b>To:</b> '[e-mail]'; David Allan<br>
<b>Cc:</b> '[e-mail]'; 'Adrian Farrel';
[e-mail]<br>
<b>Subject:</b> RE: Layer 2 Switching Caps LSPs<br>
<br>
<br>
Dimitri,<br>
<br>
What the application deriving changing the Ethernet switch data-plane to
GMPLS.&nbsp; Why not do Ethernet over MPLS?<br>
<br>
-Shahram<br>
-----Original Message-----<br>
<b>From:</b> [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>
<b>Sent:</b> Friday, January 28, 2005 2:18 PM<br>
<b>To:</b> David Allan<br>
<b>Cc:</b> '[e-mail]'; '[e-mail]';
'Adrian Farrel'; Shahram Davari; [e-mail]<br>
<b>Subject:</b> RE: Layer 2 Switching Caps LSPs<br>
<br>
<br>
<br>
<font size=4>dave - see in-line </font><br>
<br>
<b>&quot;David Allan&quot; &lt;[e-mail]&gt;</b><br>
Sent by: [e-mail]<br>
01/28/2005 13:54 EST<br>
<br>
To:<font size=4> </font>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL<br>
cc:<font size=4> </font>&quot;'[e-mail]'&quot;
&lt;[e-mail]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[e-mail]&gt;, &quot;'Shahram Davari'&quot;
&lt;[e-mail]&gt;, [e-mail]<br>
bcc:<font size=4> </font><br>
Subject:<font size=4> </font>RE: Layer 2 Switching Caps LSPs<br>
<br>
<br>
<font size=4>Hi Dimitri:</font><font size=5> </font><br>
<br>
<font size=4>&gt;&nbsp; on&nbsp; the other side, the use of the term
&quot;VLAN label&quot; has created some </font><br>
<font size=4>&gt; confusion; therefore, in a next release i will simply
refer </font><br>
<font size=4>&gt; to a &quot;label&quot; </font><br>
<font size=4>&gt; of 32 bits (unstructured) because the intention was
(and still is) to </font><br>
<font size=4>&gt; find an easy way to map the control of the ethernet
frame </font><br>
<font size=4>&gt; flows on each </font><br>
<font size=4>&gt; device they traverses without making any assumption on
how </font><br>
<font size=4>&gt; this flow is </font><br>
<font size=4>&gt; processed inside each node at the data plane level
(note: on label </font><br>
<font size=4>&gt; values, RFC 3946 took an equivalent approach - for
circuits - where </font><br>
<font size=4>&gt; sonet/sdh multiplexing structures have been used to
create unique </font><br>
<font size=4>&gt; multiplex entry names i.e. labels - this concept is
here applied for </font><br>
<font size=4>&gt; &quot;virtual&quot; circuits), so, if the working group
is willing to </font><br>
<font size=4>&gt; enter into a </font><br>
<font size=4>&gt; data plane oriented discussion to clarify the
behaviour(s) onto which </font><br>
<font size=4>&gt; the present approach would be potentially applicable
this is </font><br>
<font size=4>&gt; fine with </font><br>
<font size=4>&gt; me as long as we are within the scope of the initial
motivations </font><br>
<br>
<font size=4>So if I understand correctly there is an abstract label that
represents a flow at an intermediate device but with making no
representations as to how the flow transits the device. As the abstract
label is not tied directly to any real implementation but is merely a
useful identifier to allow two LSHs of the LSP to be tied together, So it
is not a label in the sense that there is not a logical dataplane
identifier in the packet encapsulation, nor does it correspond to a
timeslot etc. Do I have this right?</font><br>
<br>
<font size=4>-&gt; more precisely the draft does not mandate any specific
representation at the data plane level (so the last statement goes a step
beyond my statement) - in particular this representation does not assume
a modification of the ethernet frame format - this follows the approach
of RFC 3471 where the wavelength label for instance is simply a 32-bit
value that is interpreted locally (after negotiation) but yes this
abstraction does not mandate an exact 1:1 representation with the
ethernet data plane (in fact the initial document suggested one such
representation but it seems that using specific terms creates some
confusion)</font><br>
<br>
<br>
<font size=4>Dave</font><font size=5> </font></blockquote></html>

--=====================_671827997==_.ALT--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 22:25:19 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'Brungard, Deborah A, ALABS'" <[e-mail]>, [e-mail], David Allan <[e-mail]>
Cc: [e-mail], Adrian Farrel <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 14:24:14 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50588.19627F06"

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

------_=_NextPart_001_01C50588.19627F06
Content-Type: text/plain

Deborah,
 
If GMPLS is used as a replacement of Ethernet Spanning Tree protocol, could you please explain what kind of OAM is needed to run on these so-called LSPs? Ethernet OAM or MPLS OAM? 
 
-Shahram

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
Sent: Friday, January 28, 2005 5:10 PM
To: Shahram Davari; [e-mail]; David Allan
Cc: [e-mail]; Adrian Farrel; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Hi Shahram,
 
Thanks for all the interest, as Dimitri doesn't seem to be available today, I'll do my best French to answer-
 
The use of GMPLS for Ethernet is a very different application than Ethernet over MPLS. It not only provides a control plane which may be used for L2SC, it also provides the capability to support an end-to-end L2 LSP automated set up across GMPLS regions (e.g. Ethernet/GFP_SONET which I recalled mentioned on an earlier mail). The GMPLS architecture document describes the benefits for using GMPLS with PSC and L2SC. This draft was not intended to introduce any new switching capabilities than already discussed in gmpls-arch, RFC3471, RFC3473. We hoped with the draft to be proactive in detailing the use of GMPLS signaling for L2 LSPs (with the hopes of preventing mis-interpretations). We all are aware of the current market interest on Ethernet. Considering the discussion, the draft has definitely initiated discussion.
 
Dave - also thanks - I'll let Dimitri answer in detail, though one comment on Ethernet OAM. The use of GMPLS as a control plane for Ethernet is the same as GMPLS for SONET (or GMPLS for LSC) with regards to data plane monitoring.
 
Deborah

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Sorry Dimitri,
 
Let me correct my previous email:
 

What is the application driving the change of the Ethernet switch control-plane to GMPLS.  Why not just do Ethernet over MPLS?
 
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Dimitri,
 
What the application deriving changing the Ethernet switch data-plane to GMPLS.  Why not do Ethernet over MPLS?
 
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: '[e-mail]'; '[e-mail]'; 'Adrian Farrel'; Shahram Davari; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



dave - see in-line 

"David Allan" <[e-mail]>
Sent by: [e-mail]
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs




Hi Dimitri: 

>  on  the other side, the use of the term "VLAN label" has created some 
> confusion; therefore, in a next release i will simply refer 
> to a "label" 
> of 32 bits (unstructured) because the intention was (and still is) to 
> find an easy way to map the control of the ethernet frame 
> flows on each 
> device they traverses without making any assumption on how 
> this flow is 
> processed inside each node at the data plane level (note: on label 
> values, RFC 3946 took an equivalent approach - for circuits - where 
> sonet/sdh multiplexing structures have been used to create unique 
> multiplex entry names i.e. labels - this concept is here applied for 
> "virtual" circuits), so, if the working group is willing to 
> enter into a 
> data plane oriented discussion to clarify the behaviour(s) onto which 
> the present approach would be potentially applicable this is 
> fine with 
> me as long as we are within the scope of the initial motivations 

So if I understand correctly there is an abstract label that represents a flow at an intermediate device but with making no representations as to how the flow transits the device. As the abstract label is not tied directly to any real implementation but is merely a useful identifier to allow two LSHs of the LSP to be tied together, So it is not a label in the sense that there is not a logical dataplane identifier in the packet encapsulation, nor does it correspond to a timeslot etc. Do I have this right?


-> more precisely the draft does not mandate any specific representation at the data plane level (so the last statement goes a step beyond my statement) - in particular this representation does not assume a modification of the ethernet frame format - this follows the approach of RFC 3471 where the wavelength label for instance is simply a 32-bit value that is interpreted locally (after negotiation) but yes this abstraction does not mandate an exact 1:1 representation with the ethernet data plane (in fact the initial document suggested one such representation but it seems that using specific terms creates some confusion)


Dave 


------_=_NextPart_001_01C50588.19627F06
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=752042022-28012005><FONT face=Arial color=#0000ff 
size=2>Deborah,</FONT></SPAN></DIV>
<DIV><SPAN class=752042022-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=752042022-28012005><FONT face=Arial color=#0000ff size=2>If 
GMPLS is&nbsp;used as a replacement of Ethernet Spanning Tree protocol, could 
you please explain what kind of OAM is needed to run on these so-called LSPs? 
Ethernet OAM or MPLS OAM? </FONT></SPAN></DIV>
<DIV><SPAN class=752042022-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=752042022-28012005><FONT face=Arial color=#0000ff 
size=2>-Shahram</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Brungard, Deborah A, ALABS 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, January 28, 2005 5:10 
  PM<BR><B>To:</B> Shahram Davari; [e-mail]; David 
  Allan<BR><B>Cc:</B> [e-mail]; Adrian Farrel; 
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
  LSPs<BR><BR></FONT></DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2>Hi Shahram,</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2>Thanks for all the interest, as Dimitri doesn't seem to 
  be available today, I'll do my best French to answer-</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2>The use of GMPLS for Ethernet is a very different 
  application than Ethernet over MPLS. It not only provides a control plane 
  which may be used for L2SC, it also provides the capability to support an 
  end-to-end L2 LSP automated set up across GMPLS regions (e.g. 
  Ethernet/GFP_SONET which I recalled mentioned on an earlier mail). The GMPLS 
  architecture document describes the benefits for using GMPLS with PSC and 
  L2SC. This draft was not intended to introduce any new switching capabilities 
  than already discussed in gmpls-arch, RFC3471, RFC3473. We hoped with the 
  draft to be proactive in detailing the use of GMPLS signaling for L2 LSPs 
  (with the hopes of preventing mis-interpretations). We all are aware of the 
  current market interest&nbsp;on&nbsp;Ethernet. Considering the discussion, the 
  draft has definitely initiated discussion.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2>Dave - also thanks - I'll let Dimitri answer in detail, 
  though one comment on Ethernet OAM. The use of GMPLS as a control plane for 
  Ethernet is the same as&nbsp;GMPLS for SONET (or GMPLS for LSC) with regards 
  to data plane monitoring.</FONT></SPAN></DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV dir=ltr align=left><SPAN class=389441821-28012005><FONT face=Arial 
  color=#0000ff size=2>Deborah</FONT></SPAN></DIV><BR>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> [e-mail] 
  [mailto:[e-mail]] <B>On Behalf Of </B>Shahram 
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 3:12 PM<BR><B>To:</B> Shahram 
  Davari; '[e-mail]'; David Allan<BR><B>Cc:</B> 
  '[e-mail]'; 'Adrian Farrel'; 
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
  LSPs<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff 
  size=2>Sorry Dimitri,</FONT></SPAN></DIV>
  <DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff size=2>Let 
  me correct my previous email:</FONT></SPAN></DIV>
  <DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=122481020-28012005>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2>What&nbsp;<SPAN class=122481020-28012005>is </SPAN>the application 
  driving&nbsp;<SPAN class=122481020-28012005>the </SPAN>chang<SPAN 
  class=122481020-28012005>e</SPAN>&nbsp;<SPAN class=122481020-28012005>of 
  </SPAN>the Ethernet switch&nbsp;<SPAN 
  class=122481020-28012005>control</SPAN>-plane to GMPLS.&nbsp; Why not <SPAN 
  class=122481020-28012005>just do </SPAN>Ethernet over 
MPLS?</FONT></SPAN></DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=982584819-28012005><SPAN class=122481020-28012005><FONT 
  face=Arial color=#0000ff 
  size=2>-Shahram</FONT></SPAN></SPAN></DIV></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> [e-mail] 
    [mailto:[e-mail]]<B>On Behalf Of </B>Shahram 
    Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B> 
    '[e-mail]'; David Allan<BR><B>Cc:</B> 
    '[e-mail]'; 'Adrian Farrel'; 
    [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
    LSPs<BR><BR></FONT></DIV>
    <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
    size=2>Dimitri,</FONT></SPAN></DIV>
    <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
    size=2>What the application deriving changing the Ethernet switch data-plane 
    to GMPLS.&nbsp; Why not do Ethernet over MPLS?</FONT></SPAN></DIV>
    <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
    size=2>-Shahram</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> 
      [e-mail] 
      [mailto:[e-mail]]<BR><B>Sent:</B> Friday, January 
      28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
      '[e-mail]'; '[e-mail]'; 'Adrian 
      Farrel'; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
      Switching Caps LSPs<BR><BR></FONT></DIV>
      <P>dave - see in-line <BR><BR><FONT size=2><B>"David Allan" 
      &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
      [e-mail]</FONT><BR><FONT size=2>01/28/2005 13:54 
      EST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Dimitri 
      PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=2>cc:</FONT> <FONT 
      size=2>"'[e-mail]'" &lt;[e-mail]&gt;, "'Adrian 
      Farrel'" &lt;[e-mail]&gt;, "'Shahram Davari'" 
      &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT 
      size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: Layer 
      2 Switching Caps LSPs</FONT><BR><BR><BR></P>
      <P>Hi Dimitri:<FONT size=4> </FONT><BR><FONT size=4></FONT><BR>&gt;&nbsp; 
      on&nbsp; the other side, the use of the term "VLAN label" has created some 
      <BR>&gt; confusion; therefore, in a next release i will simply refer 
      <BR>&gt; to a "label" <BR>&gt; of 32 bits (unstructured) because the 
      intention was (and still is) to <BR>&gt; find an easy way to map the 
      control of the ethernet frame <BR>&gt; flows on each <BR>&gt; device they 
      traverses without making any assumption on how <BR>&gt; this flow is 
      <BR>&gt; processed inside each node at the data plane level (note: on 
      label <BR>&gt; values, RFC 3946 took an equivalent approach - for circuits 
      - where <BR>&gt; sonet/sdh multiplexing structures have been used to 
      create unique <BR>&gt; multiplex entry names i.e. labels - this concept is 
      here applied for <BR>&gt; "virtual" circuits), so, if the working group is 
      willing to <BR>&gt; enter into a <BR>&gt; data plane oriented discussion 
      to clarify the behaviour(s) onto which <BR>&gt; the present approach would 
      be potentially applicable this is <BR>&gt; fine with <BR>&gt; me as long 
      as we are within the scope of the initial motivations <BR><BR>So if I 
      understand correctly there is an abstract label that represents a flow at 
      an intermediate device but with making no representations as to how the 
      flow transits the device. As the abstract label is not tied directly to 
      any real implementation but is merely a useful identifier to allow two 
      LSHs of the LSP to be tied together, So it is not a label in the sense 
      that there is not a logical dataplane identifier in the packet 
      encapsulation, nor does it correspond to a timeslot etc. Do I have this 
      right?<BR></P>
      <P>-&gt; more precisely the draft does not mandate any specific 
      representation at the data plane level (so the last statement goes a step 
      beyond my statement) - in particular this representation does not assume a 
      modification of the ethernet frame format - this follows the approach of 
      RFC 3471 where the wavelength label for instance is simply a 32-bit value 
      that is interpreted locally (after negotiation) but yes this abstraction 
      does not mandate an exact 1:1 representation with the ethernet data plane 
      (in fact the initial document suggested one such representation but it 
      seems that using specific terms creates some confusion)</P>
      <P><BR>Dave<FONT size=4> 
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50588.19627F06--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 22:12:05 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50586.1915A3EA"
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 16:09:55 -0600
Message-ID: <[e-mail]>
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUFddCnYH3s/tNoQ0S7iojy67yefwACSHvA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Shahram Davari" <[e-mail]>, <[e-mail]>, "David Allan" <[e-mail]>
Cc: <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C50586.1915A3EA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Shahram,
=20
Thanks for all the interest, as Dimitri doesn't seem to be available
today, I'll do my best French to answer-
=20
The use of GMPLS for Ethernet is a very different application than
Ethernet over MPLS. It not only provides a control plane which may be
used for L2SC, it also provides the capability to support an end-to-end
L2 LSP automated set up across GMPLS regions (e.g. Ethernet/GFP_SONET
which I recalled mentioned on an earlier mail). The GMPLS architecture
document describes the benefits for using GMPLS with PSC and L2SC. This
draft was not intended to introduce any new switching capabilities than
already discussed in gmpls-arch, RFC3471, RFC3473. We hoped with the
draft to be proactive in detailing the use of GMPLS signaling for L2
LSPs (with the hopes of preventing mis-interpretations). We all are
aware of the current market interest on Ethernet. Considering the
discussion, the draft has definitely initiated discussion.
=20
Dave - also thanks - I'll let Dimitri answer in detail, though one
comment on Ethernet OAM. The use of GMPLS as a control plane for
Ethernet is the same as GMPLS for SONET (or GMPLS for LSC) with regards
to data plane monitoring.
=20
Deborah

  _____ =20

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Sorry Dimitri,
=20
Let me correct my previous email:
=20
What is the application driving the change of the Ethernet switch
control-plane to GMPLS.  Why not just do Ethernet over MPLS?
=20
-Shahram

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]]On Behalf Of Shahram Davari
	Sent: Friday, January 28, 2005 2:50 PM
	To: '[e-mail]'; David Allan
	Cc: '[e-mail]'; 'Adrian Farrel';
[e-mail]
	Subject: RE: Layer 2 Switching Caps LSPs
=09
=09
	Dimitri,
	=20
	What the application deriving changing the Ethernet switch
data-plane to GMPLS.  Why not do Ethernet over MPLS?
	=20
	-Shahram

		-----Original Message-----
		From: [e-mail]
[mailto:[e-mail]]
		Sent: Friday, January 28, 2005 2:18 PM
		To: David Allan
		Cc: '[e-mail]';
'[e-mail]'; 'Adrian Farrel'; Shahram Davari;
[e-mail]
		Subject: RE: Layer 2 Switching Caps LSPs
	=09
	=09

		dave - see in-line=20
	=09
		"David Allan" <[e-mail]>
		Sent by: [e-mail]
		01/28/2005 13:54 EST
	=09
		To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		cc: "'[e-mail]'" <[e-mail]>,
"'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'"
<[e-mail]>, [e-mail]
		bcc:=20
		Subject: RE: Layer 2 Switching Caps LSPs
	=09
	=09
	=09

		Hi Dimitri:=20
	=09
		>  on  the other side, the use of the term "VLAN label"
has created some=20
		> confusion; therefore, in a next release i will simply
refer=20
		> to a "label"=20
		> of 32 bits (unstructured) because the intention was
(and still is) to=20
		> find an easy way to map the control of the ethernet
frame=20
		> flows on each=20
		> device they traverses without making any assumption on
how=20
		> this flow is=20
		> processed inside each node at the data plane level
(note: on label=20
		> values, RFC 3946 took an equivalent approach - for
circuits - where=20
		> sonet/sdh multiplexing structures have been used to
create unique=20
		> multiplex entry names i.e. labels - this concept is
here applied for=20
		> "virtual" circuits), so, if the working group is
willing to=20
		> enter into a=20
		> data plane oriented discussion to clarify the
behaviour(s) onto which=20
		> the present approach would be potentially applicable
this is=20
		> fine with=20
		> me as long as we are within the scope of the initial
motivations=20
	=09
		So if I understand correctly there is an abstract label
that represents a flow at an intermediate device but with making no
representations as to how the flow transits the device. As the abstract
label is not tied directly to any real implementation but is merely a
useful identifier to allow two LSHs of the LSP to be tied together, So
it is not a label in the sense that there is not a logical dataplane
identifier in the packet encapsulation, nor does it correspond to a
timeslot etc. Do I have this right?
	=09

		-> more precisely the draft does not mandate any
specific representation at the data plane level (so the last statement
goes a step beyond my statement) - in particular this representation
does not assume a modification of the ethernet frame format - this
follows the approach of RFC 3471 where the wavelength label for instance
is simply a 32-bit value that is interpreted locally (after negotiation)
but yes this abstraction does not mandate an exact 1:1 representation
with the ethernet data plane (in fact the initial document suggested one
such representation but it seems that using specific terms creates some
confusion)

	=09
		Dave=20


------_=_NextPart_001_01C50586.1915A3EA
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.1479" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi Shahram,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks for all the interest, as Dimitri doesn't =
seem to be=20
available today, I'll do my best French to answer-</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The use of GMPLS for Ethernet is a very =
different=20
application than Ethernet over MPLS. It not only provides a control =
plane which=20
may be used for L2SC, it also provides the capability to support an =
end-to-end=20
L2 LSP automated set up across GMPLS regions (e.g. Ethernet/GFP_SONET =
which I=20
recalled mentioned on an earlier mail). The GMPLS architecture document=20
describes the benefits for using GMPLS with PSC and L2SC. This draft was =
not=20
intended to introduce any new switching capabilities than already =
discussed in=20
gmpls-arch, RFC3471, RFC3473. We hoped with the draft to be proactive in =

detailing the use of GMPLS signaling for L2 LSPs (with the hopes of =
preventing=20
mis-interpretations). We all are aware of the current market=20
interest&nbsp;on&nbsp;Ethernet. Considering the discussion, the draft =
has=20
definitely initiated discussion.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Dave - also thanks - I'll let Dimitri answer in =
detail,=20
though one comment on Ethernet OAM. The use of GMPLS as a control plane =
for=20
Ethernet is the same as&nbsp;GMPLS for SONET (or GMPLS for LSC) with =
regards to=20
data plane monitoring.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D389441821-28012005><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> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of </B>Shahram=20
Davari<BR><B>Sent:</B> Friday, January 28, 2005 3:12 PM<BR><B>To:</B> =
Shahram=20
Davari; '[e-mail]'; David Allan<BR><B>Cc:</B>=20
'[e-mail]'; 'Adrian Farrel'; =
[e-mail]<BR><B>Subject:</B>=20
RE: Layer 2 Switching Caps LSPs<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D122481020-28012005><FONT face=3DArial color=3D#0000ff =
size=3D2>Sorry=20
Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=3D122481020-28012005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D122481020-28012005><FONT face=3DArial color=3D#0000ff =
size=3D2>Let me=20
correct my previous email:</FONT></SPAN></DIV>
<DIV><SPAN class=3D122481020-28012005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D122481020-28012005>
<DIV><SPAN class=3D982584819-28012005><FONT face=3DArial color=3D#0000ff =

size=3D2>What&nbsp;<SPAN class=3D122481020-28012005>is </SPAN>the =
application=20
driving&nbsp;<SPAN class=3D122481020-28012005>the </SPAN>chang<SPAN=20
class=3D122481020-28012005>e</SPAN>&nbsp;<SPAN =
class=3D122481020-28012005>of=20
</SPAN>the Ethernet switch&nbsp;<SPAN=20
class=3D122481020-28012005>control</SPAN>-plane to GMPLS.&nbsp; Why not =
<SPAN=20
class=3D122481020-28012005>just do </SPAN>Ethernet over =
MPLS?</FONT></SPAN></DIV>
<DIV><SPAN class=3D982584819-28012005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D982584819-28012005><SPAN =
class=3D122481020-28012005><FONT=20
face=3DArial color=3D#0000ff =
size=3D2>-Shahram</FONT></SPAN></SPAN></DIV></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> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Shahram=20
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B>=20
  '[e-mail]'; David Allan<BR><B>Cc:</B>=20
  '[e-mail]'; 'Adrian Farrel';=20
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps=20
  LSPs<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Dimitri,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff size=3D2>What=20
  the application deriving changing the Ethernet switch data-plane to=20
  GMPLS.&nbsp; Why not do Ethernet over MPLS?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D982584819-28012005><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>-Shahram</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>=20
    [e-mail]=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Friday, =
January=20
    28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B>=20
    '[e-mail]'; '[e-mail]'; =
'Adrian=20
    Farrel'; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: =
Layer 2=20
    Switching Caps LSPs<BR><BR></FONT></DIV>
    <P>dave - see in-line <BR><BR><FONT size=3D2><B>"David Allan"=20
    &lt;[e-mail]&gt;</B></FONT><BR><FONT size=3D2>Sent =
by:=20
    [e-mail]</FONT><BR><FONT size=3D2>01/28/2005 13:54=20
    EST</FONT><BR><BR><FONT size=3D2>To:</FONT> <FONT size=3D2>Dimitri=20
    PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=3D2>cc:</FONT> =
<FONT=20
    size=3D2>"'[e-mail]'" &lt;[e-mail]&gt;, =
"'Adrian=20
    Farrel'" &lt;[e-mail]&gt;, "'Shahram Davari'"=20
    &lt;[e-mail]&gt;, =
[e-mail]</FONT><BR><FONT=20
    size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>RE: Layer 2=20
    Switching Caps LSPs</FONT><BR><BR><BR></P>
    <P>Hi Dimitri:<FONT size=3D4> </FONT><BR><FONT =
size=3D4></FONT><BR>&gt;&nbsp;=20
    on&nbsp; the other side, the use of the term "VLAN label" has =
created some=20
    <BR>&gt; confusion; therefore, in a next release i will simply refer =

    <BR>&gt; to a "label" <BR>&gt; of 32 bits (unstructured) because the =

    intention was (and still is) to <BR>&gt; find an easy way to map the =
control=20
    of the ethernet frame <BR>&gt; flows on each <BR>&gt; device they =
traverses=20
    without making any assumption on how <BR>&gt; this flow is <BR>&gt;=20
    processed inside each node at the data plane level (note: on label =
<BR>&gt;=20
    values, RFC 3946 took an equivalent approach - for circuits - where =
<BR>&gt;=20
    sonet/sdh multiplexing structures have been used to create unique =
<BR>&gt;=20
    multiplex entry names i.e. labels - this concept is here applied for =

    <BR>&gt; "virtual" circuits), so, if the working group is willing to =

    <BR>&gt; enter into a <BR>&gt; data plane oriented discussion to =
clarify the=20
    behaviour(s) onto which <BR>&gt; the present approach would be =
potentially=20
    applicable this is <BR>&gt; fine with <BR>&gt; me as long as we are =
within=20
    the scope of the initial motivations <BR><BR>So if I understand =
correctly=20
    there is an abstract label that represents a flow at an intermediate =
device=20
    but with making no representations as to how the flow transits the =
device.=20
    As the abstract label is not tied directly to any real =
implementation but is=20
    merely a useful identifier to allow two LSHs of the LSP to be tied =
together,=20
    So it is not a label in the sense that there is not a logical =
dataplane=20
    identifier in the packet encapsulation, nor does it correspond to a =
timeslot=20
    etc. Do I have this right?<BR></P>
    <P>-&gt; more precisely the draft does not mandate any specific=20
    representation at the data plane level (so the last statement goes a =
step=20
    beyond my statement) - in particular this representation does not =
assume a=20
    modification of the ethernet frame format - this follows the =
approach of RFC=20
    3471 where the wavelength label for instance is simply a 32-bit =
value that=20
    is interpreted locally (after negotiation) but yes this abstraction =
does not=20
    mandate an exact 1:1 representation with the ethernet data plane (in =
fact=20
    the initial document suggested one such representation but it seems =
that=20
    using specific terms creates some confusion)</P>
    <P><BR>Dave<FONT size=3D4> =
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50586.1915A3EA--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 21:07:52 +0000
To: Shahram Davari <[e-mail]>
Cc: Shahram Davari <[e-mail]>, "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 22:06:27 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+dGhpcyBhIHZhc3QgdG9waWMgdGhhdCBjYW4gYmUgYW5zd2VyZWQgaW4gc2V2ZXJhbCB3YXlz
IC0gaG93ZXZlciBvbmUgc2hvcnQgcmVzcG9uc2UgY2FuIGJlIHdoeSAod2hlbiB5b3UgYXJlIG5v
dCBpbiBhbiBJUC9NUExTIGVudmlyb25tZW50KSBpcyB0aGVyZSBhbnkgcmF0aW9uYWxlIHRvIG1h
bmRhdGUgYW4gTVBMUyB0cmFuc3BvcnQgbmV0d29yayB0byBjYXJyeSBFdGhlcm5ldCBwYXlsb2Fk
IHdoaWxlIHRlY2huaXF1ZXMgZXhpc3QgdG8gYWNoaWV2ZSB0aGUgc2FtZSBsZXZlbCBvZiBjb250
cm9sIHVzaW5nIEdNUExTICgqKSB3aXRob3V0IHRoZSBidXJkZW4gb2YgaGF2aW5nIHRvIGNvbnNp
ZGVyIHRoZSBjb3N0IG9mIGFuIGFkZGl0aW9uYWwgSVAvTVBMUyBkYXRhIHBsYW5lIGJ5IHVzaW5n
IGRpcmVjdGx5IGFuIEV0aGVybmV0IGRhdGEgcGxhbmUgLSBvbmUgZXhhbXBsZSAoYW1vbmcgbWFu
eSkgaXMgdGhlIHBvc3NpYmlsaXR5IHRvIHVzZSB0aGUgTUFDIGxheWVyIGRpcmVjdGx5IChvdmVy
IGFuIEV0aGVybmV0IFBIWSBmb3IgaW5zdGFuY2UpIHdpdGhvdXQgaGF2aW5nIHRvIGNvbnNpZGVy
IGFuIEVUSC1vdmVyLVBXLW92ZXItTVBMUyBlbnZpcm9ubWVudCB3aGVyZSBhdCB0aGUgZW5kIHlv
dSB3aWxsIGhhdmUgdG8gY2FycnkgdGhlIE1QTFMgcGFja2V0cyBvdmVyIGFub3RoZXIgZGF0YSBs
aW5rIGxheWVyIHRoYXQgY291bGQgYmUgdGhlIEVUSCBNQUMgbGF5ZXIgaXRzZWxmID88L1A+PFA+
KCopIGkgc2hvdWQgc2F5IGV2ZW4gYmV0dGVyIGJlY2F1c2UgdGhlIEdNUExTIG1lY2hhbmlzbXMg
YW5kIGFkZGVkIHZhbHVlIGZvciBwYWNrZXQgKFBTQykgbmV0d29ya3MgYXJlIChzdGlsbCkgbm90
IHdpZGVseSBjb25zaWRlcmVkIGFzIHRoZSBkZS1mYWN0byBjb250cm9sIHBsYW5lIGZvciBzdWNo
IGVudmlyb25tZW50cyBldmVuIGlmIHdlIGhvcGUgdGhpcyB3aWxsIGJlIHRoZSBjYXNlIHdpdGgg
dGhlIChNUExTIHRvIEdNUExTKSBtaWdyYXRpb24gcGhhc2UgZm9yIFBTQyBuZXR3b3JrcyB0aGF0
IGlzIGdvaW5nIHRvIGJlIChob3BlZnVsbHkpIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBD
Q0FNUCBjaGFydGVyIC0gdGhpcyBzYWlkIHRoZSBjb250cm9sIHBsYW5lIGFzc29jaWF0ZWQgdG8g
UFcgaXMgc3RpbGwgcmVzdHJpY3RlZCB0byBMRFAgdGhlcmVmb3JlIGkgYW0gbm90IHN1cmUgdGhp
cyBpcyBldmVyIGdvaW5nIHRvIGFjaGlldmUgdGhlIHNhbWUgbGV2ZWwgb2YgY29udHJvbCBhbmQg
Y2FwYWJpbGl0aWVzIHRoYW4gdGhvc2UgY29uc2lkZXJlZCBpbiB0aGUgcHJlc2VudCBMMkxTUCBj
b250ZXh0PC9QPjxQPjxCUj48Rk9OVCBTSVpFPTI+PEI+U2hhaHJhbSBEYXZhcmkgJmx0O1NoYWhy
YW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5T
ZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4w
MS8yOC8yMDA1IDEyOjEyIFBTVDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05U
PiA8Rk9OVCBTSVpFPTI+U2hhaHJhbSBEYXZhcmkgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVy
cmEuY29tJmd0OywgRGltaXRyaSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTCwgRGF2
aWQgQWxsYW4gJmx0O2RhbGxhbkBub3J0ZWxuZXR3b3Jrcy5jb20mZ3Q7PC9GT05UPjxCUj4gPEZP
TlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPiZxdW90OydkcGFwYWRpbWl0cmlvdUBw
c2cuY29tJyZxdW90OyAmbHQ7ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSZndDssICZxdW90OydBZHJp
YW4gRmFycmVsJyZxdW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssIGNjYW1wQG9wcy5p
ZXRmLm9yZzwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJ
WkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPlJFOiBMYXllciAyIFN3aXRjaGluZyBD
YXBzIExTUHM8L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD5Tb3JyeSBEaW1pdHJpLDxCUj48QlI+
TGV0IG1lIGNvcnJlY3QgbXkgcHJldmlvdXMgZW1haWw6PEJSPjxCUj5XaGF0Jm5ic3A7aXMgdGhl
IGFwcGxpY2F0aW9uIGRyaXZpbmcmbmJzcDt0aGUgY2hhbmdlJm5ic3A7b2YgdGhlIEV0aGVybmV0
IHN3aXRjaCZuYnNwO2NvbnRyb2wtcGxhbmUgdG8gR01QTFMuJm5ic3A7IFdoeSBub3QganVzdCBk
byBFdGhlcm5ldCBvdmVyIE1QTFM/PEJSPjxCUj4tU2hhaHJhbTxCUj4tLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gb3duZXItY2NhbXBAb3BzLmlldGYub3JnIFttYWls
dG86b3duZXItY2NhbXBAb3BzLmlldGYub3JnXTxCPk9uIEJlaGFsZiBPZiA8L0I+U2hhaHJhbSBE
YXZhcmk8QlI+PEI+U2VudDo8L0I+IEZyaWRheSwgSmFudWFyeSAyOCwgMjAwNSAyOjUwIFBNPEJS
PjxCPlRvOjwvQj4gJ0RpbWl0cmkuUGFwYWRpbWl0cmlvdUBhbGNhdGVsLmJlJzsgRGF2aWQgQWxs
YW48QlI+PEI+Q2M6PC9CPiAnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSc7ICdBZHJpYW4gRmFycmVs
JzsgY2NhbXBAb3BzLmlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiBSRTogTGF5ZXIgMiBTd2l0
Y2hpbmcgQ2FwcyBMU1BzPEJSPjxCUj48QlI+RGltaXRyaSw8QlI+PEJSPldoYXQgdGhlIGFwcGxp
Y2F0aW9uIGRlcml2aW5nIGNoYW5naW5nIHRoZSBFdGhlcm5ldCBzd2l0Y2ggZGF0YS1wbGFuZSB0
byBHTVBMUy4mbmJzcDsgV2h5IG5vdCBkbyBFdGhlcm5ldCBvdmVyIE1QTFM/PEJSPjxCUj4tU2hh
aHJhbTxCUj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gRGltaXRy
aS5QYXBhZGltaXRyaW91QGFsY2F0ZWwuYmUgW21haWx0bzpEaW1pdHJpLlBhcGFkaW1pdHJpb3VA
YWxjYXRlbC5iZV08QlI+PEI+U2VudDo8L0I+IEZyaWRheSwgSmFudWFyeSAyOCwgMjAwNSAyOjE4
IFBNPEJSPjxCPlRvOjwvQj4gRGF2aWQgQWxsYW48QlI+PEI+Q2M6PC9CPiAnRGltaXRyaS5QYXBh
ZGltaXRyaW91QGFsY2F0ZWwuYmUnOyAnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSc7ICdBZHJpYW4g
RmFycmVsJzsgU2hhaHJhbSBEYXZhcmk7IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj48Qj5TdWJqZWN0
OjwvQj4gUkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj48QlI+PEJSPjxCUj48Rk9O
VCBTSVpFPTQ+ZGF2ZSAtIHNlZSBpbi1saW5lIDwvRk9OVD48QlI+PEJSPjxCPiZxdW90O0Rhdmlk
IEFsbGFuJnF1b3Q7ICZsdDtkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0OzwvQj48QlI+U2Vu
dCBieTogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPEJSPjAxLzI4LzIwMDUgMTM6NTQgRVNUPEJS
PjxCUj5Ubzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxD
QVRFTEBBTENBVEVMPEJSPmNjOjxGT05UIFNJWkU9ND4gPC9GT05UPiZxdW90OydkcGFwYWRpbWl0
cmlvdUBwc2cuY29tJyZxdW90OyAmbHQ7ZHBhcGFkaW1pdHJpb3VAcHNnLmNvbSZndDssICZxdW90
OydBZHJpYW4gRmFycmVsJyZxdW90OyAmbHQ7YWRyaWFuQG9sZGRvZy5jby51ayZndDssICZxdW90
OydTaGFocmFtIERhdmFyaScmcXVvdDsgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29t
Jmd0OywgY2NhbXBAb3BzLmlldGYub3JnPEJSPmJjYzo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+
U3ViamVjdDo8Rk9OVCBTSVpFPTQ+IDwvRk9OVD5SRTogTGF5ZXIgMiBTd2l0Y2hpbmcgQ2FwcyBM
U1BzPEJSPjxCUj48QlI+PEZPTlQgU0laRT00PkhpIERpbWl0cmk6PC9GT05UPjxGT05UIFNJWkU9
NT4gPC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00PiZndDsmbmJzcDsgb24mbmJzcDsgdGhlIG90
aGVyIHNpZGUsIHRoZSB1c2Ugb2YgdGhlIHRlcm0gJnF1b3Q7VkxBTiBsYWJlbCZxdW90OyBoYXMg
Y3JlYXRlZCBzb21lIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgY29uZnVzaW9uOyB0aGVy
ZWZvcmUsIGluIGEgbmV4dCByZWxlYXNlIGkgd2lsbCBzaW1wbHkgcmVmZXIgPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+Jmd0OyB0byBhICZxdW90O2xhYmVsJnF1b3Q7IDwvRk9OVD48QlI+PEZPTlQg
U0laRT00PiZndDsgb2YgMzIgYml0cyAodW5zdHJ1Y3R1cmVkKSBiZWNhdXNlIHRoZSBpbnRlbnRp
b24gd2FzIChhbmQgc3RpbGwgaXMpIHRvIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgZmlu
ZCBhbiBlYXN5IHdheSB0byBtYXAgdGhlIGNvbnRyb2wgb2YgdGhlIGV0aGVybmV0IGZyYW1lIDwv
Rk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgZmxvd3Mgb24gZWFjaCA8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9ND4mZ3Q7IGRldmljZSB0aGV5IHRyYXZlcnNlcyB3aXRob3V0IG1ha2luZyBhbnkgYXNz
dW1wdGlvbiBvbiBob3cgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyB0aGlzIGZsb3cgaXMg
PC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBwcm9jZXNzZWQgaW5zaWRlIGVhY2ggbm9kZSBh
dCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAobm90ZTogb24gbGFiZWwgPC9GT05UPjxCUj48Rk9OVCBT
SVpFPTQ+Jmd0OyB2YWx1ZXMsIFJGQyAzOTQ2IHRvb2sgYW4gZXF1aXZhbGVudCBhcHByb2FjaCAt
IGZvciBjaXJjdWl0cyAtIHdoZXJlIDwvRk9OVD48QlI+PEZPTlQgU0laRT00PiZndDsgc29uZXQv
c2RoIG11bHRpcGxleGluZyBzdHJ1Y3R1cmVzIGhhdmUgYmVlbiB1c2VkIHRvIGNyZWF0ZSB1bmlx
dWUgPC9GT05UPjxCUj48Rk9OVCBTSVpFPTQ+Jmd0OyBtdWx0aXBsZXggZW50cnkgbmFtZXMgaS5l
LiBsYWJlbHMgLSB0aGlzIGNvbmNlcHQgaXMgaGVyZSBhcHBsaWVkIGZvciA8L0ZPTlQ+PEJSPjxG
T05UIFNJWkU9ND4mZ3Q7ICZxdW90O3ZpcnR1YWwmcXVvdDsgY2lyY3VpdHMpLCBzbywgaWYgdGhl
IHdvcmtpbmcgZ3JvdXAgaXMgd2lsbGluZyB0byA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7
IGVudGVyIGludG8gYSA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IGRhdGEgcGxhbmUgb3Jp
ZW50ZWQgZGlzY3Vzc2lvbiB0byBjbGFyaWZ5IHRoZSBiZWhhdmlvdXIocykgb250byB3aGljaCA8
L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IHRoZSBwcmVzZW50IGFwcHJvYWNoIHdvdWxkIGJl
IHBvdGVudGlhbGx5IGFwcGxpY2FibGUgdGhpcyBpcyA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4m
Z3Q7IGZpbmUgd2l0aCA8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9ND4mZ3Q7IG1lIGFzIGxvbmcgYXMg
d2UgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwgbW90aXZhdGlvbnMgPC9GT05U
PjxCUj48QlI+PEZPTlQgU0laRT00PlNvIGlmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHkgdGhlcmUg
aXMgYW4gYWJzdHJhY3QgbGFiZWwgdGhhdCByZXByZXNlbnRzIGEgZmxvdyBhdCBhbiBpbnRlcm1l
ZGlhdGUgZGV2aWNlIGJ1dCB3aXRoIG1ha2luZyBubyByZXByZXNlbnRhdGlvbnMgYXMgdG8gaG93
IHRoZSBmbG93IHRyYW5zaXRzIHRoZSBkZXZpY2UuIEFzIHRoZSBhYnN0cmFjdCBsYWJlbCBpcyBu
b3QgdGllZCBkaXJlY3RseSB0byBhbnkgcmVhbCBpbXBsZW1lbnRhdGlvbiBidXQgaXMgbWVyZWx5
IGEgdXNlZnVsIGlkZW50aWZpZXIgdG8gYWxsb3cgdHdvIExTSHMgb2YgdGhlIExTUCB0byBiZSB0
aWVkIHRvZ2V0aGVyLCBTbyBpdCBpcyBub3QgYSBsYWJlbCBpbiB0aGUgc2Vuc2UgdGhhdCB0aGVy
ZSBpcyBub3QgYSBsb2dpY2FsIGRhdGFwbGFuZSBpZGVudGlmaWVyIGluIHRoZSBwYWNrZXQgZW5j
YXBzdWxhdGlvbiwgbm9yIGRvZXMgaXQgY29ycmVzcG9uZCB0byBhIHRpbWVzbG90IGV0Yy4gRG8g
SSBoYXZlIHRoaXMgcmlnaHQ/PC9GT05UPjxCUj48QlI+PEZPTlQgU0laRT00Pi0mZ3Q7IG1vcmUg
cHJlY2lzZWx5IHRoZSBkcmFmdCBkb2VzIG5vdCBtYW5kYXRlIGFueSBzcGVjaWZpYyByZXByZXNl
bnRhdGlvbiBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAoc28gdGhlIGxhc3Qgc3RhdGVtZW50IGdv
ZXMgYSBzdGVwIGJleW9uZCBteSBzdGF0ZW1lbnQpIC0gaW4gcGFydGljdWxhciB0aGlzIHJlcHJl
c2VudGF0aW9uIGRvZXMgbm90IGFzc3VtZSBhIG1vZGlmaWNhdGlvbiBvZiB0aGUgZXRoZXJuZXQg
ZnJhbWUgZm9ybWF0IC0gdGhpcyBmb2xsb3dzIHRoZSBhcHByb2FjaCBvZiBSRkMgMzQ3MSB3aGVy
ZSB0aGUgd2F2ZWxlbmd0aCBsYWJlbCBmb3IgaW5zdGFuY2UgaXMgc2ltcGx5IGEgMzItYml0IHZh
bHVlIHRoYXQgaXMgaW50ZXJwcmV0ZWQgbG9jYWxseSAoYWZ0ZXIgbmVnb3RpYXRpb24pIGJ1dCB5
ZXMgdGhpcyBhYnN0cmFjdGlvbiBkb2VzIG5vdCBtYW5kYXRlIGFuIGV4YWN0IDE6MSByZXByZXNl
bnRhdGlvbiB3aXRoIHRoZSBldGhlcm5ldCBkYXRhIHBsYW5lIChpbiBmYWN0IHRoZSBpbml0aWFs
IGRvY3VtZW50IHN1Z2dlc3RlZCBvbmUgc3VjaCByZXByZXNlbnRhdGlvbiBidXQgaXQgc2VlbXMg
dGhhdCB1c2luZyBzcGVjaWZpYyB0ZXJtcyBjcmVhdGVzIHNvbWUgY29uZnVzaW9uKTwvRk9OVD48
QlI+PEJSPjxCUj48Rk9OVCBTSVpFPTQ+RGF2ZTwvRk9OVD48Rk9OVCBTSVpFPTU+IDwvRk9OVD48
L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 20:12:51 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: Shahram Davari <[e-mail]>, "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 12:12:19 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50575.73D9B16A"

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

------_=_NextPart_001_01C50575.73D9B16A
Content-Type: text/plain;
	charset="iso-8859-1"

Sorry Dimitri,
 
Let me correct my previous email:
 
What is the application driving the change of the Ethernet switch control-plane to GMPLS.  Why not just do Ethernet over MPLS?
 
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: '[e-mail]'; David Allan
Cc: '[e-mail]'; 'Adrian Farrel'; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs


Dimitri,
 
What the application deriving changing the Ethernet switch data-plane to GMPLS.  Why not do Ethernet over MPLS?
 
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: '[e-mail]'; '[e-mail]'; 'Adrian Farrel'; Shahram Davari; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



dave - see in-line 

"David Allan" <[e-mail]>
Sent by: [e-mail]
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs




Hi Dimitri: 

>  on  the other side, the use of the term "VLAN label" has created some 
> confusion; therefore, in a next release i will simply refer 
> to a "label" 
> of 32 bits (unstructured) because the intention was (and still is) to 
> find an easy way to map the control of the ethernet frame 
> flows on each 
> device they traverses without making any assumption on how 
> this flow is 
> processed inside each node at the data plane level (note: on label 
> values, RFC 3946 took an equivalent approach - for circuits - where 
> sonet/sdh multiplexing structures have been used to create unique 
> multiplex entry names i.e. labels - this concept is here applied for 
> "virtual" circuits), so, if the working group is willing to 
> enter into a 
> data plane oriented discussion to clarify the behaviour(s) onto which 
> the present approach would be potentially applicable this is 
> fine with 
> me as long as we are within the scope of the initial motivations 

So if I understand correctly there is an abstract label that represents a flow at an intermediate device but with making no representations as to how the flow transits the device. As the abstract label is not tied directly to any real implementation but is merely a useful identifier to allow two LSHs of the LSP to be tied together, So it is not a label in the sense that there is not a logical dataplane identifier in the packet encapsulation, nor does it correspond to a timeslot etc. Do I have this right?


-> more precisely the draft does not mandate any specific representation at the data plane level (so the last statement goes a step beyond my statement) - in particular this representation does not assume a modification of the ethernet frame format - this follows the approach of RFC 3471 where the wavelength label for instance is simply a 32-bit value that is interpreted locally (after negotiation) but yes this abstraction does not mandate an exact 1:1 representation with the ethernet data plane (in fact the initial document suggested one such representation but it seems that using specific terms creates some confusion)


Dave 


------_=_NextPart_001_01C50575.73D9B16A
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff size=2>Sorry 
Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff size=2>Let me 
correct my previous email:</FONT></SPAN></DIV>
<DIV><SPAN class=122481020-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=122481020-28012005>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2>What&nbsp;<SPAN class=122481020-28012005>is </SPAN>the application 
driving&nbsp;<SPAN class=122481020-28012005>the </SPAN>chang<SPAN 
class=122481020-28012005>e</SPAN>&nbsp;<SPAN class=122481020-28012005>of 
</SPAN>the Ethernet switch&nbsp;<SPAN 
class=122481020-28012005>control</SPAN>-plane to GMPLS.&nbsp; Why not <SPAN 
class=122481020-28012005>just do </SPAN>Ethernet over MPLS?</FONT></SPAN></DIV>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=982584819-28012005><SPAN class=122481020-28012005><FONT 
face=Arial color=#0000ff size=2>-Shahram</FONT></SPAN></SPAN></DIV></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> [e-mail] 
  [mailto:[e-mail]]<B>On Behalf Of </B>Shahram 
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B> 
  '[e-mail]'; David Allan<BR><B>Cc:</B> 
  '[e-mail]'; 'Adrian Farrel'; 
  [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching Caps 
  LSPs<BR><BR></FONT></DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2>Dimitri,</FONT></SPAN></DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff size=2>What 
  the application deriving changing the Ethernet switch data-plane to 
  GMPLS.&nbsp; Why not do Ethernet over MPLS?</FONT></SPAN></DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
  size=2>-Shahram</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> 
    [e-mail] 
    [mailto:[e-mail]]<BR><B>Sent:</B> Friday, January 
    28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
    '[e-mail]'; '[e-mail]'; 'Adrian 
    Farrel'; Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: Layer 2 
    Switching Caps LSPs<BR><BR></FONT></DIV>
    <P>dave - see in-line <BR><BR><FONT size=2><B>"David Allan" 
    &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
    [e-mail]</FONT><BR><FONT size=2>01/28/2005 13:54 
    EST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Dimitri 
    PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=2>cc:</FONT> <FONT 
    size=2>"'[e-mail]'" &lt;[e-mail]&gt;, "'Adrian 
    Farrel'" &lt;[e-mail]&gt;, "'Shahram Davari'" 
    &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT 
    size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 
    Switching Caps LSPs</FONT><BR><BR><BR></P>
    <P>Hi Dimitri:<FONT size=4> </FONT><BR><FONT size=4></FONT><BR>&gt;&nbsp; 
    on&nbsp; the other side, the use of the term "VLAN label" has created some 
    <BR>&gt; confusion; therefore, in a next release i will simply refer 
    <BR>&gt; to a "label" <BR>&gt; of 32 bits (unstructured) because the 
    intention was (and still is) to <BR>&gt; find an easy way to map the control 
    of the ethernet frame <BR>&gt; flows on each <BR>&gt; device they traverses 
    without making any assumption on how <BR>&gt; this flow is <BR>&gt; 
    processed inside each node at the data plane level (note: on label <BR>&gt; 
    values, RFC 3946 took an equivalent approach - for circuits - where <BR>&gt; 
    sonet/sdh multiplexing structures have been used to create unique <BR>&gt; 
    multiplex entry names i.e. labels - this concept is here applied for 
    <BR>&gt; "virtual" circuits), so, if the working group is willing to 
    <BR>&gt; enter into a <BR>&gt; data plane oriented discussion to clarify the 
    behaviour(s) onto which <BR>&gt; the present approach would be potentially 
    applicable this is <BR>&gt; fine with <BR>&gt; me as long as we are within 
    the scope of the initial motivations <BR><BR>So if I understand correctly 
    there is an abstract label that represents a flow at an intermediate device 
    but with making no representations as to how the flow transits the device. 
    As the abstract label is not tied directly to any real implementation but is 
    merely a useful identifier to allow two LSHs of the LSP to be tied together, 
    So it is not a label in the sense that there is not a logical dataplane 
    identifier in the packet encapsulation, nor does it correspond to a timeslot 
    etc. Do I have this right?<BR></P>
    <P>-&gt; more precisely the draft does not mandate any specific 
    representation at the data plane level (so the last statement goes a step 
    beyond my statement) - in particular this representation does not assume a 
    modification of the ethernet frame format - this follows the approach of RFC 
    3471 where the wavelength label for instance is simply a 32-bit value that 
    is interpreted locally (after negotiation) but yes this abstraction does not 
    mandate an exact 1:1 representation with the ethernet data plane (in fact 
    the initial document suggested one such representation but it seems that 
    using specific terms creates some confusion)</P>
    <P><BR>Dave<FONT size=4> </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50575.73D9B16A--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 19:51:29 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, David Allan <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 11:50:27 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50572.67FF82FA"

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

------_=_NextPart_001_01C50572.67FF82FA
Content-Type: text/plain;
	charset="iso-8859-1"

Dimitri,
 
What the application deriving changing the Ethernet switch data-plane to GMPLS.  Why not do Ethernet over MPLS?
 
-Shahram

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: '[e-mail]'; '[e-mail]'; 'Adrian Farrel'; Shahram Davari; [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs



dave - see in-line 

"David Allan" <[e-mail]>
Sent by: [e-mail]
01/28/2005 13:54 EST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
bcc: 
Subject: RE: Layer 2 Switching Caps LSPs




Hi Dimitri: 

>  on  the other side, the use of the term "VLAN label" has created some 
> confusion; therefore, in a next release i will simply refer 
> to a "label" 
> of 32 bits (unstructured) because the intention was (and still is) to 
> find an easy way to map the control of the ethernet frame 
> flows on each 
> device they traverses without making any assumption on how 
> this flow is 
> processed inside each node at the data plane level (note: on label 
> values, RFC 3946 took an equivalent approach - for circuits - where 
> sonet/sdh multiplexing structures have been used to create unique 
> multiplex entry names i.e. labels - this concept is here applied for 
> "virtual" circuits), so, if the working group is willing to 
> enter into a 
> data plane oriented discussion to clarify the behaviour(s) onto which 
> the present approach would be potentially applicable this is 
> fine with 
> me as long as we are within the scope of the initial motivations 

So if I understand correctly there is an abstract label that represents a flow at an intermediate device but with making no representations as to how the flow transits the device. As the abstract label is not tied directly to any real implementation but is merely a useful identifier to allow two LSHs of the LSP to be tied together, So it is not a label in the sense that there is not a logical dataplane identifier in the packet encapsulation, nor does it correspond to a timeslot etc. Do I have this right?


-> more precisely the draft does not mandate any specific representation at the data plane level (so the last statement goes a step beyond my statement) - in particular this representation does not assume a modification of the ethernet frame format - this follows the approach of RFC 3471 where the wavelength label for instance is simply a 32-bit value that is interpreted locally (after negotiation) but yes this abstraction does not mandate an exact 1:1 representation with the ethernet data plane (in fact the initial document suggested one such representation but it seems that using specific terms creates some confusion)


Dave 


------_=_NextPart_001_01C50572.67FF82FA
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2>Dimitri,</FONT></SPAN></DIV>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff size=2>What 
the application deriving changing the Ethernet switch data-plane to GMPLS.&nbsp; 
Why not do Ethernet over MPLS?</FONT></SPAN></DIV>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=982584819-28012005><FONT face=Arial color=#0000ff 
size=2>-Shahram</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> 
  [e-mail] 
  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, January 28, 
  2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
  '[e-mail]'; '[e-mail]'; 'Adrian Farrel'; 
  Shahram Davari; [e-mail]<BR><B>Subject:</B> RE: Layer 2 Switching 
  Caps LSPs<BR><BR></FONT></DIV>
  <P>dave - see in-line <BR><BR><FONT size=2><B>"David Allan" 
  &lt;[e-mail]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [e-mail]</FONT><BR><FONT size=2>01/28/2005 13:54 
  EST</FONT><BR><BR><FONT size=2>To:</FONT> <FONT size=2>Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL</FONT><BR><FONT size=2>cc:</FONT> <FONT 
  size=2>"'[e-mail]'" &lt;[e-mail]&gt;, "'Adrian 
  Farrel'" &lt;[e-mail]&gt;, "'Shahram Davari'" 
  &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT 
  size=2>bcc:</FONT> <BR><FONT size=2>Subject:</FONT> <FONT size=2>RE: Layer 2 
  Switching Caps LSPs</FONT><BR><BR><BR></P>
  <P>Hi Dimitri:<FONT size=4> </FONT><BR><FONT size=4></FONT><BR>&gt;&nbsp; 
  on&nbsp; the other side, the use of the term "VLAN label" has created some 
  <BR>&gt; confusion; therefore, in a next release i will simply refer <BR>&gt; 
  to a "label" <BR>&gt; of 32 bits (unstructured) because the intention was (and 
  still is) to <BR>&gt; find an easy way to map the control of the ethernet 
  frame <BR>&gt; flows on each <BR>&gt; device they traverses without making any 
  assumption on how <BR>&gt; this flow is <BR>&gt; processed inside each node at 
  the data plane level (note: on label <BR>&gt; values, RFC 3946 took an 
  equivalent approach - for circuits - where <BR>&gt; sonet/sdh multiplexing 
  structures have been used to create unique <BR>&gt; multiplex entry names i.e. 
  labels - this concept is here applied for <BR>&gt; "virtual" circuits), so, if 
  the working group is willing to <BR>&gt; enter into a <BR>&gt; data plane 
  oriented discussion to clarify the behaviour(s) onto which <BR>&gt; the 
  present approach would be potentially applicable this is <BR>&gt; fine with 
  <BR>&gt; me as long as we are within the scope of the initial motivations 
  <BR><BR>So if I understand correctly there is an abstract label that 
  represents a flow at an intermediate device but with making no representations 
  as to how the flow transits the device. As the abstract label is not tied 
  directly to any real implementation but is merely a useful identifier to allow 
  two LSHs of the LSP to be tied together, So it is not a label in the sense 
  that there is not a logical dataplane identifier in the packet encapsulation, 
  nor does it correspond to a timeslot etc. Do I have this right?<BR></P>
  <P>-&gt; more precisely the draft does not mandate any specific representation 
  at the data plane level (so the last statement goes a step beyond my 
  statement) - in particular this representation does not assume a modification 
  of the ethernet frame format - this follows the approach of RFC 3471 where the 
  wavelength label for instance is simply a 32-bit value that is interpreted 
  locally (after negotiation) but yes this abstraction does not mandate an exact 
  1:1 representation with the ethernet data plane (in fact the initial document 
  suggested one such representation but it seems that using specific terms 
  creates some confusion)</P>
  <P><BR>Dave<FONT size=4> </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C50572.67FF82FA--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 19:31:26 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 14:30:39 -0500

>> So if I understand correctly there is an abstract label that represents a
flow at an 
>> intermediate device but with making no representations as to how the flow
transits the 
>> device. As the abstract label is not tied directly to any real
implementation but is merely 
>> a useful identifier to allow two LSHs of the LSP to be tied together, So
it is not a label 
>> in the sense that there is not a logical dataplane identifier in the
packet encapsulation, 
>> nor does it correspond to a timeslot etc. Do I have this right?

-> more precisely the draft does not mandate any specific representation at
the data plane 
> level (so the last statement goes a step beyond my statement) - in
particular this 
> representation does not assume a modification of the ethernet frame format
- this follows the 
> approach of RFC 3471 where the wavelength label for instance is simply a
32-bit value that is 
> interpreted locally (after negotiation) but yes this abstraction does not
mandate an exact 
> 1:1 representation with the ethernet data plane (in fact the initial
document suggested one 
> such representation but it seems that using specific terms creates some
confusion)

I think this is where we ended up talking past each other a lot last time
around. To me such an abstact construct is more logically akin to a "name"
or "LSP application" which in general terms is the FEC (in general terms,
not LDP specific). And for OAM purposes (for example) is an easier concept
to follow than a label that has no actual data plane instantiation....it is
easier to test consistency when there is a level of indirection between the
LSP setup and the dataplane implementation if the LSP has a globally unique
name....rather than a chain of locally administered abstract values...

IMO the abstract 32 bit value would offer superior clarity to using a VLAN
tag value. IMO a name would be even better...

rgds
Dave
 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 19:18:31 +0000
To: "David Allan" <[e-mail]>
Cc: "'[e-mail]'"	 <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 20:17:44 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+ZGF2ZSAtIHNlZSBpbi1saW5lIDxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0Rhdmlk
IEFsbGFuJnF1b3Q7ICZsdDtkYWxsYW5Abm9ydGVsbmV0d29ya3MuY29tJmd0OzwvQj48L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+
PEJSPjxGT05UIFNJWkU9Mj4wMS8yOC8yMDA1IDEzOjU0IEVTVDwvRk9OVD48QlI+PEJSPiA8Rk9O
VCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBBRElNSVRSSU9VL0JF
L0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8L0ZPTlQ+IDxGT05U
IFNJWkU9Mj4mcXVvdDsnZHBhcGFkaW1pdHJpb3VAcHNnLmNvbScmcXVvdDsgJmx0O2RwYXBhZGlt
aXRyaW91QHBzZy5jb20mZ3Q7LCAmcXVvdDsnQWRyaWFuIEZhcnJlbCcmcXVvdDsgJmx0O2Fkcmlh
bkBvbGRkb2cuY28udWsmZ3Q7LCAmcXVvdDsnU2hhaHJhbSBEYXZhcmknJnF1b3Q7ICZsdDtTaGFo
cmFtX0RhdmFyaUBwbWMtc2llcnJhLmNvbSZndDssIGNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48
QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0Ojwv
Rk9OVD4gPEZPTlQgU0laRT0yPlJFOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8L0ZPTlQ+
PEJSPiA8QlI+PEJSPjwvUD48UD5IaSBEaW1pdHJpOjxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj48
Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+Jmd0OyZuYnNwOyBvbiZuYnNwOyB0aGUgb3RoZXIgc2lk
ZSwgdGhlIHVzZSBvZiB0aGUgdGVybSAmcXVvdDtWTEFOIGxhYmVsJnF1b3Q7IGhhcyBjcmVhdGVk
IHNvbWUgPEJSPiZndDsgY29uZnVzaW9uOyB0aGVyZWZvcmUsIGluIGEgbmV4dCByZWxlYXNlIGkg
d2lsbCBzaW1wbHkgcmVmZXIgPEJSPiZndDsgdG8gYSAmcXVvdDtsYWJlbCZxdW90OyA8QlI+Jmd0
OyBvZiAzMiBiaXRzICh1bnN0cnVjdHVyZWQpIGJlY2F1c2UgdGhlIGludGVudGlvbiB3YXMgKGFu
ZCBzdGlsbCBpcykgdG8gPEJSPiZndDsgZmluZCBhbiBlYXN5IHdheSB0byBtYXAgdGhlIGNvbnRy
b2wgb2YgdGhlIGV0aGVybmV0IGZyYW1lIDxCUj4mZ3Q7IGZsb3dzIG9uIGVhY2ggPEJSPiZndDsg
ZGV2aWNlIHRoZXkgdHJhdmVyc2VzIHdpdGhvdXQgbWFraW5nIGFueSBhc3N1bXB0aW9uIG9uIGhv
dyA8QlI+Jmd0OyB0aGlzIGZsb3cgaXMgPEJSPiZndDsgcHJvY2Vzc2VkIGluc2lkZSBlYWNoIG5v
ZGUgYXQgdGhlIGRhdGEgcGxhbmUgbGV2ZWwgKG5vdGU6IG9uIGxhYmVsIDxCUj4mZ3Q7IHZhbHVl
cywgUkZDIDM5NDYgdG9vayBhbiBlcXVpdmFsZW50IGFwcHJvYWNoIC0gZm9yIGNpcmN1aXRzIC0g
d2hlcmUgPEJSPiZndDsgc29uZXQvc2RoIG11bHRpcGxleGluZyBzdHJ1Y3R1cmVzIGhhdmUgYmVl
biB1c2VkIHRvIGNyZWF0ZSB1bmlxdWUgPEJSPiZndDsgbXVsdGlwbGV4IGVudHJ5IG5hbWVzIGku
ZS4gbGFiZWxzIC0gdGhpcyBjb25jZXB0IGlzIGhlcmUgYXBwbGllZCBmb3IgPEJSPiZndDsgJnF1
b3Q7dmlydHVhbCZxdW90OyBjaXJjdWl0cyksIHNvLCBpZiB0aGUgd29ya2luZyBncm91cCBpcyB3
aWxsaW5nIHRvIDxCUj4mZ3Q7IGVudGVyIGludG8gYSA8QlI+Jmd0OyBkYXRhIHBsYW5lIG9yaWVu
dGVkIGRpc2N1c3Npb24gdG8gY2xhcmlmeSB0aGUgYmVoYXZpb3VyKHMpIG9udG8gd2hpY2ggPEJS
PiZndDsgdGhlIHByZXNlbnQgYXBwcm9hY2ggd291bGQgYmUgcG90ZW50aWFsbHkgYXBwbGljYWJs
ZSB0aGlzIGlzIDxCUj4mZ3Q7IGZpbmUgd2l0aCA8QlI+Jmd0OyBtZSBhcyBsb25nIGFzIHdlIGFy
ZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBpbml0aWFsIG1vdGl2YXRpb25zIDxCUj48QlI+U28g
aWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSB0aGVyZSBpcyBhbiBhYnN0cmFjdCBsYWJlbCB0aGF0
IHJlcHJlc2VudHMgYSBmbG93IGF0IGFuIGludGVybWVkaWF0ZSBkZXZpY2UgYnV0IHdpdGggbWFr
aW5nIG5vIHJlcHJlc2VudGF0aW9ucyBhcyB0byBob3cgdGhlIGZsb3cgdHJhbnNpdHMgdGhlIGRl
dmljZS4gQXMgdGhlIGFic3RyYWN0IGxhYmVsIGlzIG5vdCB0aWVkIGRpcmVjdGx5IHRvIGFueSBy
ZWFsIGltcGxlbWVudGF0aW9uIGJ1dCBpcyBtZXJlbHkgYSB1c2VmdWwgaWRlbnRpZmllciB0byBh
bGxvdyB0d28gTFNIcyBvZiB0aGUgTFNQIHRvIGJlIHRpZWQgdG9nZXRoZXIsIFNvIGl0IGlzIG5v
dCBhIGxhYmVsIGluIHRoZSBzZW5zZSB0aGF0IHRoZXJlIGlzIG5vdCBhIGxvZ2ljYWwgZGF0YXBs
YW5lIGlkZW50aWZpZXIgaW4gdGhlIHBhY2tldCBlbmNhcHN1bGF0aW9uLCBub3IgZG9lcyBpdCBj
b3JyZXNwb25kIHRvIGEgdGltZXNsb3QgZXRjLiBEbyBJIGhhdmUgdGhpcyByaWdodD88QlI+PC9Q
PjxQPi0mZ3Q7IG1vcmUgcHJlY2lzZWx5IHRoZSBkcmFmdCBkb2VzIG5vdCBtYW5kYXRlIGFueSBz
cGVjaWZpYyByZXByZXNlbnRhdGlvbiBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAoc28gdGhlIGxh
c3Qgc3RhdGVtZW50IGdvZXMgYSBzdGVwIGJleW9uZCBteSBzdGF0ZW1lbnQpIC0gaW4gcGFydGlj
dWxhciB0aGlzIHJlcHJlc2VudGF0aW9uIGRvZXMgbm90IGFzc3VtZSBhIG1vZGlmaWNhdGlvbiBv
ZiB0aGUgZXRoZXJuZXQgZnJhbWUgZm9ybWF0IC0gdGhpcyBmb2xsb3dzIHRoZSBhcHByb2FjaCBv
ZiBSRkMgMzQ3MSB3aGVyZSB0aGUgd2F2ZWxlbmd0aCBsYWJlbCBmb3IgaW5zdGFuY2UgaXMgc2lt
cGx5IGEgMzItYml0IHZhbHVlIHRoYXQgaXMgaW50ZXJwcmV0ZWQgbG9jYWxseSAoYWZ0ZXIgbmVn
b3RpYXRpb24pIGJ1dCB5ZXMgdGhpcyBhYnN0cmFjdGlvbiBkb2VzIG5vdCBtYW5kYXRlIGFuIGV4
YWN0IDE6MSByZXByZXNlbnRhdGlvbiB3aXRoIHRoZSBldGhlcm5ldCBkYXRhIHBsYW5lIChpbiBm
YWN0IHRoZSBpbml0aWFsIGRvY3VtZW50IHN1Z2dlc3RlZCBvbmUgc3VjaCByZXByZXNlbnRhdGlv
biBidXQgaXQgc2VlbXMgdGhhdCB1c2luZyBzcGVjaWZpYyB0ZXJtcyBjcmVhdGVzIHNvbWUgY29u
ZnVzaW9uKTwvUD48UD48QlI+RGF2ZTxGT05UIFNJWkU9ND4gPC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 18:55:48 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 13:54:59 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5056A.DE03E0F3"

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

------_=_NextPart_001_01C5056A.DE03E0F3
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Dimitri:
 
>  on  the other side, the use of the term "VLAN label" has created some 
> confusion; therefore, in a next release i will simply refer 
> to a "label" 
> of 32 bits (unstructured) because the intention was (and still is) to 
> find an easy way to map the control of the ethernet frame 
> flows on each 
> device they traverses without making any assumption on how 
> this flow is 
> processed inside each node at the data plane level (note: on label 
> values, RFC 3946 took an equivalent approach - for circuits - where 
> sonet/sdh multiplexing structures have been used to create unique 
> multiplex entry names i.e. labels - this concept is here applied for 
> "virtual" circuits), so, if the working group is willing to 
> enter into a 
> data plane oriented discussion to clarify the behaviour(s) onto which 
> the present approach would be potentially applicable this is 
> fine with 
> me as long as we are within the scope of the initial motivations 

So if I understand correctly there is an abstract label that represents a
flow at an intermediate device but with making no representations as to how
the flow transits the device. As the abstract label is not tied directly to
any real implementation but is merely a useful identifier to allow two LSHs
of the LSP to be tied together, So it is not a label in the sense that there
is not a logical dataplane identifier in the packet encapsulation, nor does
it correspond to a timeslot etc. Do I have this right?

Dave

------_=_NextPart_001_01C5056A.DE03E0F3
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 =
5.5.2658.2">
<TITLE>RE: Layer 2 Switching Caps LSPs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dimitri:</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; on&nbsp; the other side, the use of the =
term &quot;VLAN label&quot; has created some </FONT>
<BR><FONT SIZE=3D2>&gt; confusion; therefore, in a next release i will =
simply refer </FONT>
<BR><FONT SIZE=3D2>&gt; to a &quot;label&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; of 32 bits (unstructured) because the intention =
was (and still is) to </FONT>
<BR><FONT SIZE=3D2>&gt; find an easy way to map the control of the =
ethernet frame </FONT>
<BR><FONT SIZE=3D2>&gt; flows on each </FONT>
<BR><FONT SIZE=3D2>&gt; device they traverses without making any =
assumption on how </FONT>
<BR><FONT SIZE=3D2>&gt; this flow is </FONT>
<BR><FONT SIZE=3D2>&gt; processed inside each node at the data plane =
level (note: on label </FONT>
<BR><FONT SIZE=3D2>&gt; values, RFC 3946 took an equivalent approach - =
for circuits - where </FONT>
<BR><FONT SIZE=3D2>&gt; sonet/sdh multiplexing structures have been =
used to create unique </FONT>
<BR><FONT SIZE=3D2>&gt; multiplex entry names i.e. labels - this =
concept is here applied for </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;virtual&quot; circuits), so, if the =
working group is willing to </FONT>
<BR><FONT SIZE=3D2>&gt; enter into a </FONT>
<BR><FONT SIZE=3D2>&gt; data plane oriented discussion to clarify the =
behaviour(s) onto which </FONT>
<BR><FONT SIZE=3D2>&gt; the present approach would be potentially =
applicable this is </FONT>
<BR><FONT SIZE=3D2>&gt; fine with </FONT>
<BR><FONT SIZE=3D2>&gt; me as long as we are within the scope of the =
initial motivations </FONT>
</P>

<P><FONT SIZE=3D2>So if I understand correctly there is an abstract =
label that represents a flow at an intermediate device but with making =
no representations as to how the flow transits the device. As the =
abstract label is not tied directly to any real implementation but is =
merely a useful identifier to allow two LSHs of the LSP to be tied =
together, So it is not a label in the sense that there is not a logical =
dataplane identifier in the packet encapsulation, nor does it =
correspond to a timeslot etc. Do I have this right?</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5056A.DE03E0F3--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 18:41:07 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 13:39:42 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50568.BACEA88B"

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

------_=_NextPart_001_01C50568.BACEA88B
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Adrian:
> 
> Is there any difference (from the point of view of the 
> network) between a VLAN with just two sites, and an LSP that 
> uses the (same along the whole
> path) VLAN tag to route data?

If by two sites you mean a link between two NEs, yes there is a difference.

If by two sites you mean a very simple VLAN in the context of a larger
network that may have many other VLANs, I beleive the answer is also yes.

My understanding (and I welcome correction) is that currently any specified
intermediate device that queues and steers traffic on the basis of an
Ethernet VLAN tag is by definition a bridge and it will do P2P and MP2P fan
in exclusively on the basis of VLAN tag, and only inspects the mac address
when there is a choice of more than one output port. 

Further that as specified bridges do not generally provide unique treatment
per VLAN tag, as the number of spanning trees permitted does not correspond
to the entire VLAN range. 

There are also OAM implications etc. associated with such a device being an
Ethernet device. It would be desirable that such a device implemented MIP
(maintenance intermediate point) functionality.

cheers
Dave

> 
> Clearly there is a difference in hardware with respect to the 
> way that the hardware is programmed from the control plane.)
> 
> Adrian
> ----- Original Message ----- 
> From: "David Allan" <[e-mail]>
> To: "'Adrian Farrel'" <[e-mail]>; "'Shahram 
> Davari'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, January 27, 2005 9:37 PM
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> > Hi Adrian:
> >
> > Your suggestion is in a way reasonable but with the caveat that in 
> > IEEE terms, a bridging topology is currently all VLANs 
> (802.1Q single
> spanning
> > tree) or partitioned into specific ranges (I believe 64 in 802.1s
> although I
> > do not claim to be an expert).
> >
> > If the PEs were to implement a bridge function and we were 
> using GMPLS
> to
> > interconnect them, then the control plane should be 
> identifying either
> all
> > VLANs (single spanning tree, which I beleive the draft covers by
> referring
> > simply to Ethernet port) or a VLAN range to be associated 
> with the LSP 
> > consistent with 802.1s if it is to operate to interconnect bridges
> defined
> > by the IEEE...
> >
> > I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
> would
> > go outside the boundary of what is currently defined...so alignment 
> > with 802.1s IMO would be a minimum requirement if we are to 
> consider 
> > carrying VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> > > Hi,
> > >
> > > The authors of the draft might like to clarify for the 
> list exactly 
> > > what data plane operations they are suggesting. To me it seems 
> > > possible that the draft is proposing VLAN ID *swapping*. But an 
> > > alternative is that the VLAN ID is used as a label, but that the 
> > > same label is used for the full length of the LSP.
> > >
> > > Adrian
> >
> >
> >
> 
> 
> 

------_=_NextPart_001_01C50568.BACEA88B
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 =
5.5.2658.2">
<TITLE>RE: Layer 2 Switching Caps LSPs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Adrian:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Is there any difference (from the point of view =
of the </FONT>
<BR><FONT SIZE=3D2>&gt; network) between a VLAN with just two sites, =
and an LSP that </FONT>
<BR><FONT SIZE=3D2>&gt; uses the (same along the whole</FONT>
<BR><FONT SIZE=3D2>&gt; path) VLAN tag to route data?</FONT>
</P>

<P><FONT SIZE=3D2>If by two sites you mean a link between two NEs, yes =
there is a difference.</FONT>
</P>

<P><FONT SIZE=3D2>If by two sites you mean a very simple VLAN in the =
context of a larger network that may have many other VLANs, I beleive =
the answer is also yes.</FONT></P>

<P><FONT SIZE=3D2>My understanding (and I welcome correction) is that =
currently any specified intermediate device that queues and steers =
traffic on the basis of an Ethernet VLAN tag is by definition a bridge =
and it will do P2P and MP2P fan in exclusively on the basis of VLAN =
tag, and only inspects the mac address when there is a choice of more =
than one output port. </FONT></P>

<P><FONT SIZE=3D2>Further that as specified bridges do not generally =
provide unique treatment per VLAN tag, as the number of spanning trees =
permitted does not correspond to the entire VLAN range. </FONT></P>

<P><FONT SIZE=3D2>There are also OAM implications etc. associated with =
such a device being an Ethernet device. It would be desirable that such =
a device implemented MIP (maintenance intermediate point) =
functionality.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
<BR><FONT SIZE=3D2>Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Clearly there is a difference in hardware with =
respect to the </FONT>
<BR><FONT SIZE=3D2>&gt; way that the hardware is programmed from the =
control plane.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Adrian</FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message ----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;David Allan&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;'Adrian Farrel'&quot; =
&lt;[e-mail]&gt;; &quot;'Shahram </FONT>
<BR><FONT SIZE=3D2>&gt; Davari'&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 27, 2005 9:37 PM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Layer 2 Switching Caps LSPs</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi Adrian:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Your suggestion is in a way reasonable but =
with the caveat that in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; IEEE terms, a bridging topology is =
currently all VLANs </FONT>
<BR><FONT SIZE=3D2>&gt; (802.1Q single</FONT>
<BR><FONT SIZE=3D2>&gt; spanning</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; tree) or partitioned into specific ranges =
(I believe 64 in 802.1s</FONT>
<BR><FONT SIZE=3D2>&gt; although I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; do not claim to be an expert).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If the PEs were to implement a bridge =
function and we were </FONT>
<BR><FONT SIZE=3D2>&gt; using GMPLS</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; interconnect them, then the control plane =
should be </FONT>
<BR><FONT SIZE=3D2>&gt; identifying either</FONT>
<BR><FONT SIZE=3D2>&gt; all</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; VLANs (single spanning tree, which I =
beleive the draft covers by</FONT>
<BR><FONT SIZE=3D2>&gt; referring</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; simply to Ethernet port) or a VLAN range =
to be associated </FONT>
<BR><FONT SIZE=3D2>&gt; with the LSP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; consistent with 802.1s if it is to operate =
to interconnect bridges</FONT>
<BR><FONT SIZE=3D2>&gt; defined</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; by the IEEE...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I suspect assuming any other behavior =
(e.g. LSP for single VLAN tag)</FONT>
<BR><FONT SIZE=3D2>&gt; would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; go outside the boundary of what is =
currently defined...so alignment </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with 802.1s IMO would be a minimum =
requirement if we are to </FONT>
<BR><FONT SIZE=3D2>&gt; consider </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; carrying VLAN information in GMPLS =
signalling....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cheers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; You wrote....</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The authors of the draft might like =
to clarify for the </FONT>
<BR><FONT SIZE=3D2>&gt; list exactly </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; what data plane operations they are =
suggesting. To me it seems </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; possible that the draft is proposing =
VLAN ID *swapping*. But an </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; alternative is that the VLAN ID is =
used as a label, but that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; same label is used for the full =
length of the LSP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Adrian</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50568.BACEA88B--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 17:27:46 +0000
To: "Adrian Farrel" <[e-mail]>
Cc: <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: Re: New WG draft [Was: Fw: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt]
Date: Fri, 28 Jan 2005 18:26:36 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+YWRyaWFuLCA8L1A+PFA+bykgdGhlIHNlbnRlbmNlICZxdW90O1RoZSBzaWduYWxpbmcgcHJv
Y2VkdXJlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcmUgYXBwbGljYWJsZSB0byBib3Ro
IHBhY2tldCBMU1BzIChSU1ZQLVRFKSBhbmQgbm9uLXBhY2tldCBMU1BzIHRoYXQgdXNlIFJTVlAt
VEUgR01QTFMgZXh0ZW5zaW9ucyBhcyBkZXNjcmliZWQgaW4gW1JTVlAtR01QTFNdJnF1b3Q7IGlz
IGFtYmlndW91cywgR01QTFMgUlNWUC1URSBjb3ZlcnMgcGFja2V0IExTUHM8L1A+PFA+bykgc2Vj
dGlvbiA2IGlzIGEgYml0IGRpZmZpY3VsdCB0byBwYXJzZSBhcyBpIHJlYWQgaXQgRlJSIHdob2x5
IHRha2VuIGludG8gYWNjb3VudCBmb3IgbXVsdGktZG9tYWluIExTUCBzaWduYWxpbmcgaG93ZXZl
ciBwYXJhZ3JhcGggNi4yIGludHJvZHVjZXMgYSByZXF1aXJlbWVudCBvbiBhIG1lY2hhbmlzbSBp
dCBkb2VzIG5vdCBjb3ZlciAoaS5lLiBpdCBpbXBvc2VzIGEgY29uc3RyYWludCBvbiBHTVBMUyBM
U1AgcmVjb3ZlcnkgbWVjaGFuaXNtcykgLSBzbyBpcyBpdCB0aGUgcmlnaHQgcGxhY2UgdG8gaW50
cm9kdWNlIHN1Y2ggcmVxdWlyZW1lbnQgPyAtIG5vdyB0aGUgbW9yZSBiYXNpYyBpc3N1ZSBpcyB3
aHkgdGhlc2UgdHdvIG1vZGVzIGhhdmUgZGlmZmVyZW50IHByZWNlZGVuY2UgbGV2ZWwgaW4gdGhl
IGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCA/IC0gaSB3b3VsZCBsaWtlIGFsc28gdG8gcmVjYXAg
dGhhdCB0aGUgQ0NBTVAgV0cgaXMgZGV2ZWxvcGluZyBhIG1ldGhvZCByZWZlcnJlZCB0byBhcyBz
ZWdtZW50IHJlY292ZXJ5IHdoaWNoIGlzIGFsc28gYXBwbGljYWJsZSBpbiB0aGUgcHJlc2VudCBj
b250ZXh0ICh3aHkgaXMgdGhpcyBub3QgdGFrZW4gaW50byBhY2NvdW50KSA/PC9QPjxQPm8pIGEg
dGhpcmQgcG9pbnQgY29uY2VybnMgdGhlIHJlbGV2YW5jZSBpbiByZS1kZXRhaWxpbmcgcGFydCBv
ZiB0aGUgYmFzZSBMU1AgcmUtb3B0aW1pemF0aW9uIGFzIHBhcnQgb2YgdGhpcyBkb2N1bWVudCAo
YXMgaXQgaXMgYWxyZWFkeSBwYXJ0IG9mIHRoZSByZS1vcHRpbWl6YXRpb24gZG9jdW1lbnQgLSB0
aGF0IHNob3VsZCB0YWNrbGUgdGhlIGlzc3VlIG9mIG5vbi1kaXNydXB0aXZlIHJlLW9wdGltaXph
dGlvbnMgZm9yIGNpcmN1aXQgTFNQcyBzdWNoIGFzIFRETSBhbmQgTFNDKSBhbmQgbm90IGZvY3Vz
IG9uIHRoZSBtdWx0aS1kb21haW4gc3BlY2lmaWNzIC0gZXhhbXBsZSB0YWNrbGluZyBtdWx0aXBs
ZSBkb21haW4gcmUtb3B0aW1pemF0aW9ucyBhdCBhIHRpbWUgLSA8L1A+PFA+aW1obyAtIGFkZHJl
c3NpbmcgdGhlc2UgcG9pbnRzIHNob3VsZCBub3QgYmxvY2sgcHJvZ3Jlc3Mgb2YgdGhpcyBkb2N1
bWVudDxCUj48QlI+PEZPTlQgU0laRT0yPjxCPiZxdW90O0FkcmlhbiBGYXJyZWwmcXVvdDsgJmx0
O2FkcmlhbkBvbGRkb2cuY28udWsmZ3Q7PC9CPjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQg
Ynk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjAxLzI4
LzIwMDUgMTI6NTIgR01UPC9GT05UPjxCUj48Rk9OVCBTSVpFPTI+UGxlYXNlIHJlc3BvbmQgdG8g
JnF1b3Q7QWRyaWFuIEZhcnJlbCZxdW90OzwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86
PC9GT05UPiA8Rk9OVCBTSVpFPTI+Jmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L0ZPTlQ+PEJS
PiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5iY2M6PC9GT05UPiA8
QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0yPk5ldyBXRyBkcmFm
dCBbV2FzOiBGdzogSS1EIEFDVElPTjpkcmFmdC1heXlhbmdhci1jY2FtcC1pbnRlci1kb21haW4t
cnN2cC10ZS0wMi50eHRdPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPkhpLDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5BZnRlciBkaXNjdXNzaW9ucyBvbiB0aGUgbGlzdCwgQXJ0aGkgYW5kIEpQIGhhdmUg
c3BsaXQgdGhlIGludGVyZG9tYWluPEJSPnNpZ25hbGluZyBkcmFmdCBpbnRvIHR3by4gVGhlIGZp
cnN0ICh0aGlzIGRyYWZ0KSBkZXNjcmliZXMgdGhlIG9wdGlvbnMgZm9yPEJSPmludGVyZG9tYWlu
IHNpZ25hbGluZy4gVGhlIHNlY29uZCAoY29taW5nIGFueSBtb21lbnQpIGlzIHNwZWNpZmljIHRv
PEJSPnN0aXRjaGluZy48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll
ciI+SSB0aGluayB3ZSBoYWQgYWdyZWVtZW50IG9uIHRoZSBjb250ZW50IG9mIHRoZSBvcmlnaW5h
bCBkcmFmdCwgYW5kPEJSPmFncmVlbWVudCB0byBtYWtlIFdHIGRyYWZ0cyBvbmNlIHRoZSB3b3Jr
IHdhcyBzcGxpdC48QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
VGhpcyBlbWFpbCBpcyB0byBnaXZlIHlvdSBhIGJyaWVmIGNoYW5jZSB0byBvYmplY3QuIENvbW1l
bnRzIGJlZm9yZSA3dGg8QlI+RmVicnVhcnkgcGxlYXNlLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZB
Q0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5DaGVlcnMsPEJSPkFkcmlhbjxCUj48L0ZPTlQ+PEJSPjxG
T05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t
PEJSPkZyb206ICZsdDtJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcmZ3Q7PEJSPlRvOiAmbHQ7aS1k
LWFubm91bmNlQGlldGYub3JnJmd0OzxCUj5TZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAw
NSA4OjUzIFBNPEJSPlN1YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQtYXl5YW5nYXItY2NhbXAtaW50
ZXItZG9tYWluLXJzdnAtdGUtMDIudHh0PEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj4mZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm
cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxCUj5kaXJlY3Rvcmllcy48QlI+Jmd0OzxC
Uj4mZ3Q7PEJSPiZndDsgVGl0bGUgOiBJbnRlciBkb21haW4gTVBMUyBUcmFmZmljIEVuZ2luZWVy
aW5nIC0gUlNWUC1URSBleHRlbnNpb25zPEJSPiZndDsgQXV0aG9yKHMpIDogQS4gQXl5YW5nYXIs
IEouIFZhc3NldXI8QlI+Jmd0OyBGaWxlbmFtZSA6IGRyYWZ0LWF5eWFuZ2FyLWNjYW1wLWludGVy
LWRvbWFpbi1yc3ZwLXRlLTAyLnR4dDxCUj4mZ3Q7IFBhZ2VzIDogMTc8QlI+Jmd0OyBEYXRlIDog
MjAwNS0xLTI3PEJSPiZndDs8QlI+Jmd0OyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBleHRlbnNp
b25zIHRvIEdlbmVyYWxpemVkIE11bHRpLVByb3RvY29sIExhYmVsPEJSPiZndDsgU3dpdGNoaW5n
IChHTVBMUykgUmVzb3VyY2UgUmVzZXJWYXRpb24gUHJvdG9jb2wgLSBUcmFmZmljIEVuZ2luZWVy
aW5nPEJSPiZndDsgKFJTVlAtVEUpIHNpZ25hbGluZyByZXF1aXJlZCB0byBzdXBwb3J0IG1lY2hh
bmlzbXMgZm9yIHRoZSBlc3RhYmxpc2htZW50PEJSPiZndDsgYW5kIG1haW50ZW5hbmNlIG9mIEdN
UExTIFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBMYWJlbCBTd2l0Y2hlZCBQYXRoczxCUj4mZ3Q7
IChMU1BzKSwgYm90aCBwYWNrZXQgYW5kIG5vbi1wYWNrZXQsIHRoYXQgdHJhdmVyc2UgbXVsdGlw
bGUgZG9tYWlucy4gRm9yPEJSPiZndDsgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCwgYSBk
b21haW4gaXMgY29uc2lkZXJlZCB0byBiZSBhbnk8QlI+Jmd0OyBjb2xsZWN0aW9uIG9mIG5ldHdv
cmsgZWxlbWVudHMgd2l0aGluIGEgY29tbW9uIHJlYWxtIG9mIGFkZHJlc3Mgc3BhY2Ugb3I8QlI+
Jmd0OyBwYXRoIGNvbXB1dGF0aW9uIHJlc3BvbnNpYmlsaXR5LiBFeGFtcGxlcyBvZiBzdWNoIGRv
bWFpbnMgaW5jbHVkZTxCUj4mZ3Q7IEF1dG9ub21vdXMgU3lzdGVtcywgSUdQIGFyZWFzIGFuZCBH
TVBMUyBvdmVybGF5IG5ldHdvcmtzLjxCUj4mZ3Q7PEJSPiZndDsgQSBVUkwgZm9yIHRoaXMgSW50
ZXJuZXQtRHJhZnQgaXM6PEJSPiZndDs8QlI+PEEgSFJFRj1odHRwOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1heXlhbmdhci1jY2FtcC1pbnRlci1kb21haW4tcnN2cC10ZS0w
Mi50eHQ+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXl5YW5nYXIt
Y2NhbXAtaW50ZXItZG9tYWluLXJzdnAtdGUtMDIudHh0PC9BPjxCUj4mZ3Q7PEJSPiZndDsgVG8g
cmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1l
c3NhZ2UgdG88QlI+Jmd0OyBpLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3
b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5IG9mPEJSPnRoZSBtZXNzYWdlLjxCUj4mZ3Q7IFlv
dSBjYW4gYWxzbyB2aXNpdCA8QSBIUkVGPWh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL0ktRC1hbm5vdW5jZT5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9JLUQtYW5ub3VuY2U8L0E+PEJSPiZndDsgdG8gY2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNl
dHRpbmdzLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g
YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhlPEJSPnVzZXJuYW1lPEJS
PiZndDsgJnF1b3Q7YW5vbnltb3VzJnF1b3Q7IGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWls
IGFkZHJlc3MuIEFmdGVyIGxvZ2dpbmcgaW4sPEJSPiZndDsgdHlwZSAmcXVvdDtjZCBpbnRlcm5l
dC1kcmFmdHMmcXVvdDsgYW5kIHRoZW48QlI+Jmd0OyAmcXVvdDtnZXQgZHJhZnQtYXl5YW5nYXIt
Y2NhbXAtaW50ZXItZG9tYWluLXJzdnAtdGUtMDIudHh0JnF1b3Q7LjxCUj4mZ3Q7PEJSPiZndDsg
QSBsaXN0IG9mIEludGVybmV0LURyYWZ0cyBkaXJlY3RvcmllcyBjYW4gYmUgZm91bmQgaW48QlI+
Jmd0OyA8QSBIUkVGPWh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw+aHR0cDovL3d3dy5p
ZXRmLm9yZy9zaGFkb3cuaHRtbDwvQT48QlI+Jmd0OyBvciA8QSBIUkVGPWZ0cDovL2Z0cC5pZXRm
Lm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk
b3ctc2l0ZXMudHh0PC9BPjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBJbnRlcm5ldC1EcmFmdHMg
Y2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLjxCUj4mZ3Q7PEJSPiZndDsgU2VuZCBhIG1l
c3NhZ2UgdG86PEJSPiZndDsgbWFpbHNlcnZAaWV0Zi5vcmcuPEJSPiZndDsgSW4gdGhlIGJvZHkg
dHlwZTo8QlI+Jmd0OyAmcXVvdDtGSUxFPEJSPi9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYXl5YW5n
YXItY2NhbXAtaW50ZXItZG9tYWluLXJzdnAtdGUtMDIudHh0JnF1b3Q7LjxCUj4mZ3Q7PEJSPiZn
dDsgTk9URTogVGhlIG1haWwgc2VydmVyIGF0IGlldGYub3JnIGNhbiByZXR1cm4gdGhlIGRvY3Vt
ZW50IGluPEJSPiZndDsgTUlNRS1lbmNvZGVkIGZvcm0gYnkgdXNpbmcgdGhlICZxdW90O21wYWNr
JnF1b3Q7IHV0aWxpdHkuICZuYnNwO1RvIHVzZSB0aGlzPEJSPiZndDsgZmVhdHVyZSwgaW5zZXJ0
IHRoZSBjb21tYW5kICZxdW90O0VOQ09ESU5HIG1pbWUmcXVvdDsgYmVmb3JlIHRoZSAmcXVvdDtG
SUxFJnF1b3Q7PEJSPiZndDsgY29tbWFuZC4gJm5ic3A7VG8gZGVjb2RlIHRoZSByZXNwb25zZShz
KSwgeW91IHdpbGwgbmVlZCAmcXVvdDttdW5wYWNrJnF1b3Q7IG9yPEJSPiZndDsgYSBNSU1FLWNv
bXBsaWFudCBtYWlsIHJlYWRlci4gJm5ic3A7RGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwg
cmVhZGVyczxCUj4mZ3Q7IGV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdo
ZW4gZGVhbGluZyB3aXRoPEJSPiZndDsgJnF1b3Q7bXVsdGlwYXJ0JnF1b3Q7IE1JTUUgbWVzc2Fn
ZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdDxCUj4mZ3Q7IHVwIGludG8g
bXVsdGlwbGUgbWVzc2FnZXMpLCBzbyBjaGVjayB5b3VyIGxvY2FsIGRvY3VtZW50YXRpb24gb248
QlI+Jmd0OyBob3cgdG8gbWFuaXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy48QlI+Jmd0OzxCUj4mZ3Q7
PEJSPiZndDsgQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBs
aWFudCBtYWlsIHJlYWRlcjxCUj4mZ3Q7IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkg
cmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlPEJSPiZndDsgSW50ZXJuZXQtRHJhZnQu
PEJSPiZndDs8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPEJSPi0tLS0tLTxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxCUj4mZ3Q7IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8QlI+Jmd0
OyBJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8QlI+Jmd0OyA8QSBIUkVGPWh0dHBzOi8vd3d3MS5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZT5odHRwczovL3d3dzEuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L0E+PEJSPiZndDs8QlI+PC9GT05UPjwvUD4=



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 16:42:41 +0000
To: Shahram Davari <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, [e-mail], "'[e-mail]'"	 <[e-mail]>
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 17:41:46 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+c2hhcmFtLCB0aGUgZHJhZnQgZG9lcyBub3QgcHJvcG9zZSBhIHNwZWNpZmljIGRhdGEgcGxh
bmUgc3dpdGNoaW5nIHByb2Nlc3NpbmcsIGJ1dCBhbGxvd3MgZGlzdGluY3Rpb24gb2YgYSBtb2Rl
IHdoZXJlIHRoZSB3aG9sZSBmbG93IHRyYXZlcnNpbmcgYW4gaW50ZXJmYWNlIChwb3J0IG1vZGUp
IGlzIHJldHJpZXZlZCBhdCB0aGUgb3V0Z29pbmcgaW50ZXJmYWNlIGZyb20gYSBtb2RlIGFsbG93
aW5nIHRyYWNraW5nIG9mIG11bHRpcGxlIGZsb3dzIHRyYXZlcnNpbmcgdGhlIHNhbWUgaW50ZXJm
YWNlIGFuZCB0aGUgbW9zdCBvYnZpb3VzIG9uZSB3YXMgdGhlIHVzZSBvZiB0aGUgVkxBTiBJRCB2
YWx1ZSBhcyBpdCBpbXBsaWNpdGx5IGRldGVybWluZXMgdGhlIG1hcHBpbmcgd2l0aCB0aGUgZGF0
YSBwbGFuZSAtIGJ1dCBhcyBpIHNhaWQgY2xhcmlmaWNhdGlvbnMgYXJlIHRvIGJlIGFkZGVkIGhl
cmUgYmVjYXVzZSB0aGlzIHRlcm0gZGlkIGdlbmVyYXRlIHNvbWUgY29uZnVzaW9uIC0gbm90ZSBh
bHNvIHRoYXQgdGhpcyBkcmFmdCBkb2VzIG5vdCBkaXNjdXNzIGFueSBzcGVjaWZpYyBldGhlcm5l
dCBmcmFtZSBwcm9jZXNzaW5nPEJSPjxCUj48Rk9OVCBTSVpFPTI+PEI+U2hhaHJhbSBEYXZhcmkg
Jmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9Mj4wMS8yOC8yMDA1IDA4OjA3IFBTVDwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+
VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+JnF1b3Q7J0FkcmlhbiBGYXJyZWwnJnF1b3Q7ICZsdDth
ZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgY2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj4gPEZP
TlQgU0laRT0yPmNjOjwvRk9OVD4gPEZPTlQgU0laRT0yPkRpbWl0cmkgUEFQQURJTUlUUklPVS9C
RS9BTENBVEVMQEFMQ0FURUw8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJS
PiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SRTogTGF5ZXIgMiBT
d2l0Y2hpbmcgQ2FwcyBMU1BzPC9GT05UPjxCUj4gPEJSPjxCUj48L1A+PFA+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPkRpbWl0cmksPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9u
b3NwYWNlLENvdXJpZXIiPkNvdWxkIHlvdSBwbGVhc2UgY2xhcmlmeSB0aGlzIHF1ZXN0aW9uLjxC
Uj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGFua3MsPEJSPlNo
YWhyYW08QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7IEZyb206IEFkcmlhbiBGYXJyZWwgW21h
aWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrXTxCUj4mZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5
IDI3LCAyMDA1IDM6MzAgUE08QlI+Jmd0OyBUbzogU2hhaHJhbSBEYXZhcmk7IGNjYW1wQG9wcy5p
ZXRmLm9yZzxCUj4mZ3Q7IFN1YmplY3Q6IFJlOiBMYXllciAyIFN3aXRjaGluZyBDYXBzIExTUHM8
QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDsgSGksPEJSPiZndDs8QlI+Jmd0OyBUaGUgYXV0aG9ycyBv
ZiB0aGUgZHJhZnQgbWlnaHQgbGlrZSB0byBjbGFyaWZ5IGZvciB0aGUgbGlzdDxCUj4mZ3Q7IGV4
YWN0bHkgd2hhdDxCUj4mZ3Q7IGRhdGEgcGxhbmUgb3BlcmF0aW9ucyB0aGV5IGFyZSBzdWdnZXN0
aW5nLiBUbyBtZSBpdCBzZWVtczxCUj4mZ3Q7IHBvc3NpYmxlIHRoYXQ8QlI+Jmd0OyB0aGUgZHJh
ZnQgaXMgcHJvcG9zaW5nIFZMQU4gSUQgKnN3YXBwaW5nKi4gQnV0IGFuIGFsdGVybmF0aXZlPEJS
PiZndDsgaXMgdGhhdCB0aGU8QlI+Jmd0OyBWTEFOIElEIGlzIHVzZWQgYXMgYSBsYWJlbCwgYnV0
IHRoYXQgdGhlIHNhbWUgbGFiZWwgaXMgdXNlZDxCUj4mZ3Q7IGZvciB0aGUgZnVsbDxCUj4mZ3Q7
IGxlbmd0aCBvZiB0aGUgTFNQLjxCUj4mZ3Q7PEJSPiZndDsgQWRyaWFuPEJSPiZndDs8QlI+Jmd0
OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPEJSPiZndDsgRnJvbTogJnF1b3Q7U2hhaHJh
bSBEYXZhcmkmcXVvdDsgJmx0O1NoYWhyYW1fRGF2YXJpQHBtYy1zaWVycmEuY29tJmd0OzxCUj4m
Z3Q7IFRvOiAmcXVvdDsnQWRyaWFuIEZhcnJlbCcmcXVvdDsgJmx0O2FkcmlhbkBvbGRkb2cuY28u
dWsmZ3Q7ICZsdDtjY2FtcEBvcHMuaWV0Zi5vcmcmZ3Q7PEJSPiZndDsgU2VudDogVHVlc2RheSwg
SmFudWFyeSAyNSwgMjAwNSA5OjI1IFBNPEJSPiZndDsgU3ViamVjdDogUkU6IExheWVyIDIgU3dp
dGNoaW5nIENhcHMgTFNQczxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyAmZ3Q7IEhpLDxCUj4mZ3Q7
ICZndDs8QlI+Jmd0OyAmZ3Q7IFRoZSBvbmx5IGlzc3VlIHRoYXQgSSBoYXZlIGlzIHdpdGggVkxB
TiBzd2l0Y2hpbmcuIFNpbmNlPEJSPiZndDsgVkxBTiBzd2l0Y2hpbmc8QlI+Jmd0OyAmZ3Q7IGlz
IG5vdCBhIHN0YW5kYXJkIDgwMi4xUSBiZWhhdmlvciwgaXQgY2FuJ3QgYmUgdXNlZCB3aXRoIGV4
aXN0aW5nPEJSPiZndDsgRXRoZXJuZXQ8QlI+Jmd0OyAmZ3Q7IGhhcmR3YXJlLiBUaGVyZWZvcmUg
dGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgaXMgbm90IGxpbWl0ZWQgdG88QlI+Jmd0OyBjb250cm9s
LXBsYW5lLDxCUj4mZ3Q7ICZndDsgYW5kIHJlcXVpcmVzIG5ldyBkYXRhLXBsYW5lIHRoYXQgaXMg
bm90IGRlZmluZWQgaW4gSUVFRSB5ZXQuPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgSWYgdGhl
IFZMQU4gc3dpdGNoaW5nIGlzIHJlbW92ZWQgZnJvbSB0aGUgZHJhZnQsIEkgc3VwcG9ydDxCUj4m
Z3Q7IGFjY2VwdGluZyBpdDxCUj4mZ3Q7IGFzPEJSPiZndDsgJmd0OyBhIFdHIGRyYWZ0LjxCUj4m
Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFlvdXJzLDxCUj4mZ3Q7ICZndDsgLVNoYWhyYW08QlI+Jmd0
OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZn
dDsgJmd0OyAmZ3Q7IEZyb206IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVy
LWNjYW1wQG9wcy5pZXRmLm9yZ11PbjxCUj4mZ3Q7ICZndDsgJmd0OyBCZWhhbGYgT2YgQWRyaWFu
IEZhcnJlbDxCUj4mZ3Q7ICZndDsgJmd0OyBTZW50OiBTdW5kYXksIEphbnVhcnkgMjMsIDIwMDUg
Njo0NiBBTTxCUj4mZ3Q7ICZndDsgJmd0OyBUbzogY2NhbXBAb3BzLmlldGYub3JnPEJSPiZndDsg
Jmd0OyAmZ3Q7IFN1YmplY3Q6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj4mZ3Q7ICZn
dDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBBbGwsPEJSPiZndDsg
Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFRoZXJlIGlzIGEgZHJhZnQ8QlI+Jmd0OyAmZ3Q7
ICZndDsgKGRyYWZ0LXBhcGFkaW1pdHJpb3UtY2NhbXAtZ21wbHMtbDJzYy1sc3AtMDMudHh0KSB0
aGF0IHdlPEJSPiZndDsgJmd0OyAmZ3Q7IGhhdmUgZGlzY3Vzc2VkIGF0IHNldmVyYWwgb2YgdGhl
IG1vcmUgcmVjZW50IENDQU1QPEJSPiZndDsgbWVldGluZ3MsIGFuZCBoYXZlPEJSPiZndDsgJmd0
OyAmZ3Q7IGRlY2lkZWQgdGhhdCB0aGUgc3ViamVjdCBpcyB3aXRoaW4gc2NvcGUgZm9yIG91ciBj
aGFydGVyLjxCUj4mZ3Q7ICZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJmd0OyBUaGUgcXVlc3Rpb25z
IHdlIGhhdmUgZmFjZWQgaGF2ZSBiZWVuOjxCUj4mZ3Q7ICZndDsgJmd0OyAtIGlzIHRoZSBwcm9i
bGVtIHdlbGwgZW5vdWdoIGFydGljdWxhdGVkPzxCUj4mZ3Q7ICZndDsgJmd0OyAtIGlzIHRoaXMg
dGhlIHNvbHV0aW9uIHRoYXQgdGhlIFdHIHdhbnRzIHRvIHB1cnN1ZT88QlI+Jmd0OyAmZ3Q7ICZn
dDsgLSBpcyB0aGVyZSBhIGhpZ2ggZW5vdWdoIGxldmVsIG9mIGludGVyZXN0IGluIHRoaXMgd29y
az88QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZndDsgSWYgdGhlIGFuc3dlciB0byBh
bGwgdGhyZWUgcXVlc3Rpb25zIGlzICZxdW90O3llcyZxdW90OyB0aGVuIHdlIGNhbjxCUj4mZ3Q7
ICZndDsgJmd0OyBhZG9wdCB0aGUgZHJhZnQ8QlI+Jmd0OyAmZ3Q7ICZndDsgYXMgYSBXRyBkb2N1
bWVudCBhbmQgbW92ZSBmb3J3YXJkcy48QlI+Jmd0OyAmZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZn
dDsgTm90ZTogSSB0aGluayB0aGVyZSBhcmUgYSBsYXJnZSBudW1iZXIgb2YgbWlub3IgaXNzdWVz
IHRvPEJSPiZndDsgJmd0OyAmZ3Q7IGNsZWFyIHVwIHdpdGg8QlI+Jmd0OyAmZ3Q7ICZndDsgdGhp
cyBkcmFmdCwgYnV0IGhvcGVmdWxseSB0aGlzIGlzIG9ydGhvZ29uYWwgdG8gd2hldGhlciB3ZTxC
Uj4mZ3Q7ICZndDsgJmd0OyBtYWtlIHRoaXMgYSBXRzxCUj4mZ3Q7ICZndDsgJmd0OyBkcmFmdCBv
ciBub3QuPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8QlI+Jmd0
OyAmZ3Q7ICZndDsgQWRyaWFuPEJSPiZndDsgJmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmZ3Q7PEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PC9GT05UPjxCUj48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+Jmd0OyA8L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 16:08:07 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, [e-mail]
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 08:07:27 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Dimitri,

Could you please clarify this question.

Thanks,
Shahram

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Thursday, January 27, 2005 3:30 PM
> To: Shahram Davari; [e-mail]
> Subject: Re: Layer 2 Switching Caps LSPs
> 
> 
> Hi,
> 
> The authors of the draft might like to clarify for the list 
> exactly what
> data plane operations they are suggesting. To me it seems 
> possible that
> the draft is proposing VLAN ID *swapping*. But an alternative 
> is that the
> VLAN ID is used as a label, but that the same label is used 
> for the full
> length of the LSP.
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Shahram Davari" <[e-mail]>
> To: "'Adrian Farrel'" <[e-mail]>; <[e-mail]>
> Sent: Tuesday, January 25, 2005 9:25 PM
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> > Hi,
> >
> > The only issue that I have is with VLAN switching. Since 
> VLAN switching
> > is not a standard 802.1Q behavior, it can't be used with existing
> Ethernet
> > hardware. Therefore the scope of this draft is not limited to
> control-plane,
> > and requires new data-plane that is not defined in IEEE yet.
> >
> > If the VLAN switching is removed from the draft, I support 
> accepting it
> as
> > a WG draft.
> >
> > Yours,
> > -Shahram
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Sunday, January 23, 2005 6:46 AM
> > > To: [e-mail]
> > > Subject: Layer 2 Switching Caps LSPs
> > >
> > >
> > > All,
> > >
> > > There is a draft
> > > (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
> > > have discussed at several of the more recent CCAMP 
> meetings, and have
> > > decided that the subject is within scope for our charter.
> > >
> > > The questions we have faced have been:
> > > - is the problem well enough articulated?
> > > - is this the solution that the WG wants to pursue?
> > > - is there a high enough level of interest in this work?
> > >
> > > If the answer to all three questions is "yes" then we can
> > > adopt the draft
> > > as a WG document and move forwards.
> > >
> > > Note: I think there are a large number of minor issues to
> > > clear up with
> > > this draft, but hopefully this is orthogonal to whether we
> > > make this a WG
> > > draft or not.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
> >
> >
> >
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 16:08:00 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, David Allan <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 08:06:30 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

What do you mean by just two sites?

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Friday, January 28, 2005 7:15 AM
> To: David Allan; Shahram Davari
> Cc: [e-mail]
> Subject: Re: Layer 2 Switching Caps LSPs
> 
> 
> Thanks Dave,
> 
> Just one point...
> 
> Is there any difference (from the point of view of the 
> network) between a
> VLAN with just two sites, and an LSP that uses the (same 
> along the whole
> path) VLAN tag to route data?
> 
> Clearly there is a difference in hardware with respect to the 
> way that the
> hardware is programmed from the control plane.)
> 
> Adrian
> ----- Original Message ----- 
> From: "David Allan" <[e-mail]>
> To: "'Adrian Farrel'" <[e-mail]>; "'Shahram Davari'"
> <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, January 27, 2005 9:37 PM
> Subject: RE: Layer 2 Switching Caps LSPs
> 
> 
> > Hi Adrian:
> >
> > Your suggestion is in a way reasonable but with the caveat 
> that in IEEE
> > terms, a bridging topology is currently all VLANs (802.1Q single
> spanning
> > tree) or partitioned into specific ranges (I believe 64 in 802.1s
> although I
> > do not claim to be an expert).
> >
> > If the PEs were to implement a bridge function and we were 
> using GMPLS
> to
> > interconnect them, then the control plane should be 
> identifying either
> all
> > VLANs (single spanning tree, which I beleive the draft covers by
> referring
> > simply to Ethernet port) or a VLAN range to be associated 
> with the LSP
> > consistent with 802.1s if it is to operate to interconnect bridges
> defined
> > by the IEEE...
> >
> > I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
> would
> > go outside the boundary of what is currently defined...so 
> alignment with
> > 802.1s IMO would be a minimum requirement if we are to 
> consider carrying
> > VLAN information in GMPLS signalling....
> >
> > cheers
> > Dave
> >
> > You wrote....
> > > Hi,
> > >
> > > The authors of the draft might like to clarify for the list
> > > exactly what data plane operations they are suggesting. To me
> > > it seems possible that the draft is proposing VLAN ID
> > > *swapping*. But an alternative is that the VLAN ID is used as
> > > a label, but that the same label is used for the full length
> > > of the LSP.
> > >
> > > Adrian
> >
> >
> >
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 15:49:04 +0000
To: "David Allan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 16:48:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+ZGF2ZSwgJm5ic3A7dGhlIHJlc3BvbnNlIHRvIHlvdXIgbGFzdCBxdWVzdGlvbiAoYW5kIHRo
aXMgd2FzIGFsc28gcGFydCBvZiB0aGUgZGlzY3Vzc2lvbiB0aHJlYWQpIGlzIHRoZSBuZWdhdGl2
ZSAtIG1vcmVvdmVyIGkgd291bGQgbGlrZSB0byByZW1lbWJlciB5b3UgdGhhdCB0aGUgRkVDIGNv
bmNlcHRzIGluIHRoZSBwcmVzZW50IGNvbnRleHQgaXMgbm90IHRoZSBvbmUgeW91IGltcGxpY2l0
bHkgYXNzdW1lIGFzIHdlIGFyZSBpbiBhIFJTVlAtVEUgY29udGV4dCBub3QgYW4gTERQIG9uZTwv
UD48UD5zZWUgaW4tbGluZTwvUD48UD48QlI+Jmd0OyBkYXZlIC0gdGhlcmUgd2FzIGEgbGVuZ3Ro
eSBvZmYtbGluZSBkaXNjdXNzaW9uIHN1Z2dlc3RlZCBieSA8QlI+Jmd0OyB0aGUgY2hhaXJzIDxC
Uj4mZ3Q7IGludGVuZGVkIHRvIGV4cGxhaW4geW91IHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgYW5k
IGl0cyA8QlI+Jmd0OyByZWxhdGlvc2hpcCB3aXRoIDxCUj4mZ3Q7IHRoZSBldGhlcm5ldCBkYXRh
IHBsYW5lIChhZnRlciB0aGUgcXVlc3Rpb24geW91IHJhaXNlZCBkdXJpbmcgdGhlIGYyZiA8QlI+
Jmd0OyBtZWV0aW5nKSAtIHRoaXMgaGFzIGJlZW4gZG9uZSBhbmQgd2UgaGF2ZSBleHBsYWluZWQg
KHZpYSBhIGxlbmd0aHkgPEJSPiZndDsgZXhjaGFuZ2Ugb2YgZS1tYWlscykgdGhhdCB0aGlzIGRv
Y3VtZW50IGFuZCBzbyB0aGUgdXNlIG9mIGdtcGxzIHRvIDxCUj4mZ3Q7IGNvbnRyb2wgZXRoZXJu
ZXQgZnJhbWUgZmxvd3MsIGlzIG5vdCB0YXJnZXRpbmcgY29udHJvbCBvZiBicmlkZ2VkIDxCUj4m
Z3Q7IGV0aGVybmV0IGVudmlyb25tZW50cyA8QlI+PEJSPlllcywgSSBoYXZlIGFyY2hpdmVkIHRo
YXQgZGlzY3Vzc2lvbiwgY29uc3VtZXMgYSByZWFvbnNhYmxlIGFtb3VudCBvZiBteSBkaXNrIHNw
YWNlIDstKTxGT05UIFNJWkU9ND4gPC9GT05UPjxCUj48L1A+PFA+W2RwXSBidXQgd2FzIGFwcGFy
ZXRubHkgbm90IHN1ZmZpY2llbnQgOy0pPC9QPjxQPjxCUj4tIGlmIHRoaXMgaXMgbm90IGNsZWFy
IGZyb20gdGhlIGN1cnJlbnQgPEJSPiZndDsgZG9jdW1lbnQgPEJSPiZndDsgaW50cm9kdWN0aW9u
IHdlIHdvdWxkIGhhdmUgYWxzbyB0byB3b3JrIG9uIHRoaXMgcGFydCBvZiB0aGUgPEJSPiZndDsg
ZG9jdW1lbnQgLSA8QlI+PEJSPlllcyBJIGRvIGJlbGVpdmUgdGhlIGRvY3VtZW50IG5lZWRzIHdv
cmsgdG8gY2xhcmlmeSBtYW55IG9mIHRoZSBzb3VyY2VzIG9mIGNvbmZ1c2lvbiB3ZSBkaXNjdXNz
ZWQsIG15IHN1Z2dlc3Rpb24gaXMgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQ8QlI+PEJSPiZn
dDsgdGhlcmVmb3JlLCB0aGUgYmVsb3cgcmVmZXJlbmNlIHRvIE1TVFAgaXMgbm90IGluIHRoZSBj
dXJyZW50IDxCUj4mZ3Q7IHNjb3BlOyA8QlI+PEJSPkkgdGhpbmsgdGhlIHF1ZXN0aW9uIGlzIHdo
YXQgaGFzIHV0aWxpdHkgcmVsYXRpdmUgdG8gZXhpc3Rpbmcgc3RhbmRhcmRzLCBhYmlsaXR5IHRv
IGRlZmluZSBhbiBldGhlcm5ldCBGRUMgYXMgZWl0aGVyIGEgcG9ydCAoU2luZ2xlIHNwYW5uaW5n
IHRyZWUgdG9wb2xvZ3kpIG9yIE1TVFAgaW5zdGFuY2UgKG11bHRpcGxlIHNwYW5uaW5nIHRyZWVz
KSBzbyB0aGF0IHRoZSBHTVBMUyBzaWduYWxsZWQgdG9wb2xvZ3kgY2FuIGJlIHJlc29sdmVkIHRv
IHNvbXRoaW5nIEV0aGVybmV0IHVuZGVyc3RhbmRzIGhhcyB1dGlsaXR5LjxCUj48L1A+PFA+W2Rw
XSB0aGUgbm90aW9uIG9mIEZFQyBpcyBvZGQgaW4gdGhlIHByZXNlbnQgY29udGV4dCAtd2UgaGF2
ZSBsZW5ndGhpbHkgY29uc3VtZWQgdGhpcyBkaXNjdXNzaW9uIC0gPC9QPjxQPjxCUj4mZ3Q7IG9u
IDxCUj4mZ3Q7IHRoZSBvdGhlciBzaWRlLCB0aGUgdXNlIG9mIHRoZSB0ZXJtICZxdW90O1ZMQU4g
bGFiZWwmcXVvdDsgaGFzIGNyZWF0ZWQgc29tZSA8QlI+Jmd0OyBjb25mdXNpb247IHRoZXJlZm9y
ZSwgaW4gYSBuZXh0IHJlbGVhc2UgaSB3aWxsIHNpbXBseSByZWZlciA8QlI+Jmd0OyB0byBhICZx
dW90O2xhYmVsJnF1b3Q7IDxCUj4mZ3Q7IG9mIDMyIGJpdHMgKHVuc3RydWN0dXJlZCkgYmVjYXVz
ZSB0aGUgaW50ZW50aW9uIHdhcyAoYW5kIHN0aWxsIGlzKSB0byA8QlI+Jmd0OyBmaW5kIGFuIGVh
c3kgd2F5IHRvIG1hcCB0aGUgY29udHJvbCBvZiB0aGUgZXRoZXJuZXQgZnJhbWUgPEJSPiZndDsg
Zmxvd3Mgb24gZWFjaCA8QlI+Jmd0OyBkZXZpY2UgdGhleSB0cmF2ZXJzZXMgd2l0aG91dCBtYWtp
bmcgYW55IGFzc3VtcHRpb24gb24gaG93IDxCUj4mZ3Q7IHRoaXMgZmxvdyBpcyA8QlI+Jmd0OyBw
cm9jZXNzZWQgaW5zaWRlIGVhY2ggbm9kZSBhdCB0aGUgZGF0YSBwbGFuZSBsZXZlbCAobm90ZTog
b24gbGFiZWwgPEJSPiZndDsgdmFsdWVzLCBSRkMgMzk0NiB0b29rIGFuIGVxdWl2YWxlbnQgYXBw
cm9hY2ggLSBmb3IgY2lyY3VpdHMgLSB3aGVyZSA8QlI+Jmd0OyBzb25ldC9zZGggbXVsdGlwbGV4
aW5nIHN0cnVjdHVyZXMgaGF2ZSBiZWVuIHVzZWQgdG8gY3JlYXRlIHVuaXF1ZSA8QlI+Jmd0OyBt
dWx0aXBsZXggZW50cnkgbmFtZXMgaS5lLiBsYWJlbHMgLSB0aGlzIGNvbmNlcHQgaXMgaGVyZSBh
cHBsaWVkIGZvciA8QlI+Jmd0OyAmcXVvdDt2aXJ0dWFsJnF1b3Q7IGNpcmN1aXRzKSwgc28sIGlm
IHRoZSB3b3JraW5nIGdyb3VwIGlzIHdpbGxpbmcgdG8gPEJSPiZndDsgZW50ZXIgaW50byBhIDxC
Uj4mZ3Q7IGRhdGEgcGxhbmUgb3JpZW50ZWQgZGlzY3Vzc2lvbiB0byBjbGFyaWZ5IHRoZSBiZWhh
dmlvdXIocykgb250byB3aGljaCA8QlI+Jmd0OyB0aGUgcHJlc2VudCBhcHByb2FjaCB3b3VsZCBi
ZSBwb3RlbnRpYWxseSBhcHBsaWNhYmxlIHRoaXMgaXMgPEJSPiZndDsgZmluZSB3aXRoIDxCUj4m
Z3Q7IG1lIGFzIGxvbmcgYXMgd2UgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIGluaXRpYWwg
bW90aXZhdGlvbnM8Rk9OVCBTSVpFPTQ+IDwvRk9OVD48QlI+PEJSPlllcywgaWYgd2UgYXJlIGRp
c2N1c3NpbmcgbGFiZWxzIGFuZCBub3QgRkVDcyBhbmQgYSBsYWJlbCBpcyByZXF1aXJlZCB0byBk
aXNjcmltaW5hdGUgdGhlIGV4c2l0aW5nIGZsb3cgSU1PIGl0IHNob3VsZCBiZSBhbiBNUExTIGxh
YmVsLiBUaGlzIHB1dHMgdXMgYmFjayB0b3dhcmRzIERlYm9yYWgncyBhbmFsb2d5IHRoYXQgdGhp
cyBpcyBQVyBzaWduYWxsaW5nIChhIGxhIGRyeSBtYXJ0aW5pLi4ubXkgaW50ZXJwcmV0YXRpb24p
LCBpZiBzbyBoYXZlbid0IHdlIGFscmVhZHkgc3BlY2lmaWVkIHRoZSBjb250cm9sIHBsYW5lIGlu
IGFub3RoZXIgV0c/PEJSPjwvUD48UD5bZHBdIHNlZSBhYm92ZTxCUj5EYXZlPEZPTlQgU0laRT00
PiA8L0ZPTlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 15:39:51 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 10:38:01 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5054F.5993343D"

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

------_=_NextPart_001_01C5054F.5993343D
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi Dimitri

> dave - there was a lengthy off-line discussion suggested by 
> the chairs 
> intended to explain you the scope of the draft and its 
> relatioship with 
> the ethernet data plane (after the question you raised during the f2f 
> meeting) - this has been done and we have explained (via a lengthy 
> exchange of e-mails) that this document and so the use of gmpls to 
> control ethernet frame flows, is not targeting control of bridged 
> ethernet environments 

Yes, I have archived that discussion, consumes a reaonsable amount of my
disk space ;-)

- if this is not clear from the current 
> document 
> introduction we would have also to work on this part of the 
> document - 

Yes I do beleive the document needs work to clarify many of the sources of
confusion we discussed, my suggestion is an applicability statement


> therefore, the below reference to MSTP is not in the current 
> scope; 

I think the question is what has utility relative to existing standards,
ability to define an ethernet FEC as either a port (Single spanning tree
topology) or MSTP instance (multiple spanning trees) so that the GMPLS
signalled topology can be resolved to somthing Ethernet understands has
utility.


> on 
> the other side, the use of the term "VLAN label" has created some 
> confusion; therefore, in a next release i will simply refer 
> to a "label" 
> of 32 bits (unstructured) because the intention was (and still is) to 
> find an easy way to map the control of the ethernet frame 
> flows on each 
> device they traverses without making any assumption on how 
> this flow is 
> processed inside each node at the data plane level (note: on label 
> values, RFC 3946 took an equivalent approach - for circuits - where 
> sonet/sdh multiplexing structures have been used to create unique 
> multiplex entry names i.e. labels - this concept is here applied for 
> "virtual" circuits), so, if the working group is willing to 
> enter into a 
> data plane oriented discussion to clarify the behaviour(s) onto which 
> the present approach would be potentially applicable this is 
> fine with 
> me as long as we are within the scope of the initial motivations

Yes, if we are discussing labels and not FECs and a label is required to
discriminate the exsiting flow IMO it should be an MPLS label. This puts us
back towards Deborah's analogy that this is PW signalling (a la dry
martini...my interpretation), if so haven't we already specified the control
plane in another WG?

Dave


------_=_NextPart_001_01C5054F.5993343D
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 =
5.5.2658.2">
<TITLE>RE: Layer 2 Switching Caps LSPs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Dimitri</FONT>
</P>

<P><FONT SIZE=3D2>&gt; dave - there was a lengthy off-line discussion =
suggested by </FONT>
<BR><FONT SIZE=3D2>&gt; the chairs </FONT>
<BR><FONT SIZE=3D2>&gt; intended to explain you the scope of the draft =
and its </FONT>
<BR><FONT SIZE=3D2>&gt; relatioship with </FONT>
<BR><FONT SIZE=3D2>&gt; the ethernet data plane (after the question you =
raised during the f2f </FONT>
<BR><FONT SIZE=3D2>&gt; meeting) - this has been done and we have =
explained (via a lengthy </FONT>
<BR><FONT SIZE=3D2>&gt; exchange of e-mails) that this document and so =
the use of gmpls to </FONT>
<BR><FONT SIZE=3D2>&gt; control ethernet frame flows, is not targeting =
control of bridged </FONT>
<BR><FONT SIZE=3D2>&gt; ethernet environments </FONT>
</P>

<P><FONT SIZE=3D2>Yes, I have archived that discussion, consumes a =
reaonsable amount of my disk space ;-)</FONT>
</P>

<P><FONT SIZE=3D2>- if this is not clear from the current </FONT>
<BR><FONT SIZE=3D2>&gt; document </FONT>
<BR><FONT SIZE=3D2>&gt; introduction we would have also to work on this =
part of the </FONT>
<BR><FONT SIZE=3D2>&gt; document - </FONT>
</P>

<P><FONT SIZE=3D2>Yes I do beleive the document needs work to clarify =
many of the sources of confusion we discussed, my suggestion is an =
applicability statement</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; therefore, the below reference to MSTP is not in =
the current </FONT>
<BR><FONT SIZE=3D2>&gt; scope; </FONT>
</P>

<P><FONT SIZE=3D2>I think the question is what has utility relative to =
existing standards, ability to define an ethernet FEC as either a port =
(Single spanning tree topology) or MSTP instance (multiple spanning =
trees) so that the GMPLS signalled topology can be resolved to somthing =
Ethernet understands has utility.</FONT></P>
<BR>

<P><FONT SIZE=3D2>&gt; on </FONT>
<BR><FONT SIZE=3D2>&gt; the other side, the use of the term &quot;VLAN =
label&quot; has created some </FONT>
<BR><FONT SIZE=3D2>&gt; confusion; therefore, in a next release i will =
simply refer </FONT>
<BR><FONT SIZE=3D2>&gt; to a &quot;label&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; of 32 bits (unstructured) because the intention =
was (and still is) to </FONT>
<BR><FONT SIZE=3D2>&gt; find an easy way to map the control of the =
ethernet frame </FONT>
<BR><FONT SIZE=3D2>&gt; flows on each </FONT>
<BR><FONT SIZE=3D2>&gt; device they traverses without making any =
assumption on how </FONT>
<BR><FONT SIZE=3D2>&gt; this flow is </FONT>
<BR><FONT SIZE=3D2>&gt; processed inside each node at the data plane =
level (note: on label </FONT>
<BR><FONT SIZE=3D2>&gt; values, RFC 3946 took an equivalent approach - =
for circuits - where </FONT>
<BR><FONT SIZE=3D2>&gt; sonet/sdh multiplexing structures have been =
used to create unique </FONT>
<BR><FONT SIZE=3D2>&gt; multiplex entry names i.e. labels - this =
concept is here applied for </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;virtual&quot; circuits), so, if the =
working group is willing to </FONT>
<BR><FONT SIZE=3D2>&gt; enter into a </FONT>
<BR><FONT SIZE=3D2>&gt; data plane oriented discussion to clarify the =
behaviour(s) onto which </FONT>
<BR><FONT SIZE=3D2>&gt; the present approach would be potentially =
applicable this is </FONT>
<BR><FONT SIZE=3D2>&gt; fine with </FONT>
<BR><FONT SIZE=3D2>&gt; me as long as we are within the scope of the =
initial motivations</FONT>
</P>

<P><FONT SIZE=3D2>Yes, if we are discussing labels and not FECs and a =
label is required to discriminate the exsiting flow IMO it should be an =
MPLS label. This puts us back towards Deborah's analogy that this is PW =
signalling (a la dry martini...my interpretation), if so haven't we =
already specified the control plane in another WG?</FONT></P>

<P><FONT SIZE=3D2>Dave</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5054F.5993343D--



Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 14:59:33 +0000
Message-ID: <030c01c50549$f108bb80$cacb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: New WG draft [Was: Fw: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt]
Date: Fri, 28 Jan 2005 12:52:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

After discussions on the list, Arthi and JP have split the interdomain
signaling draft into two. The first (this draft) describes the options for
interdomain signaling. The second (coming any moment) is specific to
stitching.

I think we had agreement on the content of the original draft, and
agreement to make WG drafts once the work was split.

This email is to give you a brief chance to object. Comments before 7th
February please.

Cheers,
Adrian

----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Thursday, January 27, 2005 8:53 PM
Subject: I-D ACTION:draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt


> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
> Title : Inter domain MPLS Traffic Engineering - RSVP-TE extensions
> Author(s) : A. Ayyangar, J. Vasseur
> Filename : draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
> Pages : 17
> Date : 2005-1-27
>
> This document describes extensions to Generalized Multi-Protocol Label
> Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering
> (RSVP-TE) signaling required to support mechanisms for the establishment
> and maintenance of GMPLS Traffic Engineering (TE) Label Switched Paths
> (LSPs), both packet and non-packet, that traverse multiple domains. For
> the purpose of this document, a domain is considered to be any
> collection of network elements within a common realm of address space or
> path computation responsibility. Examples of such domains include
> Autonomous Systems, IGP areas and GMPLS overlay networks.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] 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-ayyangar-ccamp-inter-domain-rsvp-te-02.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:
> [e-mail].
> In the body type:
> "FILE
/internet-drafts/draft-ayyangar-ccamp-inter-domain-rsvp-te-02.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.
>


--------------------------------------------------------------------------
------


> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>




Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 12:20:19 +0000
Message-ID: <020801c50533$9466c040$cacb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "David Allan" <[e-mail]>, "'Shahram Davari'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 12:15:26 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks Dave,

Just one point...

Is there any difference (from the point of view of the network) between a
VLAN with just two sites, and an LSP that uses the (same along the whole
path) VLAN tag to route data?

Clearly there is a difference in hardware with respect to the way that the
hardware is programmed from the control plane.)

Adrian
----- Original Message ----- 
From: "David Allan" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>; "'Shahram Davari'"
<[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 27, 2005 9:37 PM
Subject: RE: Layer 2 Switching Caps LSPs


> Hi Adrian:
>
> Your suggestion is in a way reasonable but with the caveat that in IEEE
> terms, a bridging topology is currently all VLANs (802.1Q single
spanning
> tree) or partitioned into specific ranges (I believe 64 in 802.1s
although I
> do not claim to be an expert).
>
> If the PEs were to implement a bridge function and we were using GMPLS
to
> interconnect them, then the control plane should be identifying either
all
> VLANs (single spanning tree, which I beleive the draft covers by
referring
> simply to Ethernet port) or a VLAN range to be associated with the LSP
> consistent with 802.1s if it is to operate to interconnect bridges
defined
> by the IEEE...
>
> I suspect assuming any other behavior (e.g. LSP for single VLAN tag)
would
> go outside the boundary of what is currently defined...so alignment with
> 802.1s IMO would be a minimum requirement if we are to consider carrying
> VLAN information in GMPLS signalling....
>
> cheers
> Dave
>
> You wrote....
> > Hi,
> >
> > The authors of the draft might like to clarify for the list
> > exactly what data plane operations they are suggesting. To me
> > it seems possible that the draft is proposing VLAN ID
> > *swapping*. But an alternative is that the VLAN ID is used as
> > a label, but that the same label is used for the full length
> > of the LSP.
> >
> > Adrian
>
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 28 Jan 2005 00:36:22 +0000
Message-ID: <[e-mail]>
Date: Fri, 28 Jan 2005 01:35:03 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: David Allan <[e-mail]>
CC: 'Adrian Farrel' <[e-mail]>,  'Shahram Davari' <[e-mail]>, [e-mail]
Subject: Re: Layer 2 Switching Caps LSPs
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

dave - there was a lengthy off-line discussion suggested by the chairs 
intended to explain you the scope of the draft and its relatioship with 
the ethernet data plane (after the question you raised during the f2f 
meeting) - this has been done and we have explained (via a lengthy 
exchange of e-mails) that this document and so the use of gmpls to 
control ethernet frame flows, is not targeting control of bridged 
ethernet environments - if this is not clear from the current document 
introduction we would have also to work on this part of the document - 
therefore, the below reference to MSTP is not in the current scope; on 
the other side, the use of the term "VLAN label" has created some 
confusion; therefore, in a next release i will simply refer to a "label" 
of 32 bits (unstructured) because the intention was (and still is) to 
find an easy way to map the control of the ethernet frame flows on each 
device they traverses without making any assumption on how this flow is 
processed inside each node at the data plane level (note: on label 
values, RFC 3946 took an equivalent approach - for circuits - where 
sonet/sdh multiplexing structures have been used to create unique 
multiplex entry names i.e. labels - this concept is here applied for 
"virtual" circuits), so, if the working group is willing to enter into a 
data plane oriented discussion to clarify the behaviour(s) onto which 
the present approach would be potentially applicable this is fine with 
me as long as we are within the scope of the initial motivations

thanks,
- dimitri.

David Allan wrote:
> Hi Adrian:
> 
> Your suggestion is in a way reasonable but with the caveat that in IEEE
> terms, a bridging topology is currently all VLANs (802.1Q single spanning
> tree) or partitioned into specific ranges (I believe 64 in 802.1s although I
> do not claim to be an expert). 
> 
> If the PEs were to implement a bridge function and we were using GMPLS to
> interconnect them, then the control plane should be identifying either all
> VLANs (single spanning tree, which I beleive the draft covers by referring
> simply to Ethernet port) or a VLAN range to be associated with the LSP
> consistent with 802.1s if it is to operate to interconnect bridges defined
> by the IEEE...
> 
> I suspect assuming any other behavior (e.g. LSP for single VLAN tag) would
> go outside the boundary of what is currently defined...so alignment with
> 802.1s IMO would be a minimum requirement if we are to consider carrying
> VLAN information in GMPLS signalling....
> 
> cheers
> Dave
> 
> You wrote....
> 
>>Hi,
>>
>>The authors of the draft might like to clarify for the list 
>>exactly what data plane operations they are suggesting. To me 
>>it seems possible that the draft is proposing VLAN ID 
>>*swapping*. But an alternative is that the VLAN ID is used as 
>>a label, but that the same label is used for the full length 
>>of the LSP.
>>
>>Adrian
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 27 Jan 2005 21:38:08 +0000
Message-ID: <[e-mail]>
From: "David Allan" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "'Shahram Davari'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Thu, 27 Jan 2005 16:37:34 -0500

Hi Adrian:

Your suggestion is in a way reasonable but with the caveat that in IEEE
terms, a bridging topology is currently all VLANs (802.1Q single spanning
tree) or partitioned into specific ranges (I believe 64 in 802.1s although I
do not claim to be an expert). 

If the PEs were to implement a bridge function and we were using GMPLS to
interconnect them, then the control plane should be identifying either all
VLANs (single spanning tree, which I beleive the draft covers by referring
simply to Ethernet port) or a VLAN range to be associated with the LSP
consistent with 802.1s if it is to operate to interconnect bridges defined
by the IEEE...

I suspect assuming any other behavior (e.g. LSP for single VLAN tag) would
go outside the boundary of what is currently defined...so alignment with
802.1s IMO would be a minimum requirement if we are to consider carrying
VLAN information in GMPLS signalling....

cheers
Dave

You wrote....
> Hi,
> 
> The authors of the draft might like to clarify for the list 
> exactly what data plane operations they are suggesting. To me 
> it seems possible that the draft is proposing VLAN ID 
> *swapping*. But an alternative is that the VLAN ID is used as 
> a label, but that the same label is used for the full length 
> of the LSP.
> 
> Adrian



Envelope-to: [e-mail]
Delivery-date: Thu, 27 Jan 2005 21:18:14 +0000
Message-ID: <01e801c504b5$66c9cca0$cacb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Shahram Davari" <[e-mail]>, <[e-mail]>
Subject: Re: Layer 2 Switching Caps LSPs
Date: Thu, 27 Jan 2005 20:30:20 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The authors of the draft might like to clarify for the list exactly what
data plane operations they are suggesting. To me it seems possible that
the draft is proposing VLAN ID *swapping*. But an alternative is that the
VLAN ID is used as a label, but that the same label is used for the full
length of the LSP.

Adrian

----- Original Message ----- 
From: "Shahram Davari" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>; <[e-mail]>
Sent: Tuesday, January 25, 2005 9:25 PM
Subject: RE: Layer 2 Switching Caps LSPs


> Hi,
>
> The only issue that I have is with VLAN switching. Since VLAN switching
> is not a standard 802.1Q behavior, it can't be used with existing
Ethernet
> hardware. Therefore the scope of this draft is not limited to
control-plane,
> and requires new data-plane that is not defined in IEEE yet.
>
> If the VLAN switching is removed from the draft, I support accepting it
as
> a WG draft.
>
> Yours,
> -Shahram
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]On
> > Behalf Of Adrian Farrel
> > Sent: Sunday, January 23, 2005 6:46 AM
> > To: [e-mail]
> > Subject: Layer 2 Switching Caps LSPs
> >
> >
> > All,
> >
> > There is a draft
> > (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
> > have discussed at several of the more recent CCAMP meetings, and have
> > decided that the subject is within scope for our charter.
> >
> > The questions we have faced have been:
> > - is the problem well enough articulated?
> > - is this the solution that the WG wants to pursue?
> > - is there a high enough level of interest in this work?
> >
> > If the answer to all three questions is "yes" then we can
> > adopt the draft
> > as a WG document and move forwards.
> >
> > Note: I think there are a large number of minor issues to
> > clear up with
> > this draft, but hopefully this is orthogonal to whether we
> > make this a WG
> > draft or not.
> >
> > Thanks,
> > Adrian
> >
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 26 Jan 2005 09:32:04 +0000
From: [e-mail]
Subject: Re: Layer 2 Switching Caps LSPs
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 26 Jan 2005 10:31:03 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Adrian,


For me the answer is affirmative to all three questions. However, it might
be appropriate to expand on the motivations after the introduction in terms
of protocol fit as the current version only provides a functional fit.


Regards,
Bart.



-------- Original Message --------
Subject: Layer 2 Switching Caps LSPs
Date: Sun, 23 Jan 2005 11:46:16 -0000
From: Adrian Farrel <[e-mail]>
To: <[e-mail]>

All,

There is a draft (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
have discussed at several of the more recent CCAMP meetings, and have
decided that the subject is within scope for our charter.

The questions we have faced have been:
- is the problem well enough articulated?
- is this the solution that the WG wants to pursue?
- is there a high enough level of interest in this work?

If the answer to all three questions is "yes" then we can adopt the draft
as a WG document and move forwards.

Note: I think there are a large number of minor issues to clear up with
this draft, but hopefully this is orthogonal to whether we make this a WG
draft or not.

Thanks,
Adrian



.









Envelope-to: [e-mail]
Delivery-date: Wed, 26 Jan 2005 07:52:31 +0000
Thread-Topic: Layer 2 Switching Caps LSPs
Thread-Index: AcUDe76uniGje8UfQzi9mv9zfxBtOg==
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
Content-Transfer-Encoding: 7bit
From: =?ks_c_5601-1987?B?wbbA58f8?= <[e-mail]>
To: <[e-mail]>
Cc: 
Bcc: 
Subject: RE: Layer 2 Switching Caps LSPs
Date: Wed, 26 Jan 2005 16:50:46 +0900
Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCC9w726xdu8s7DoxsAsILTjtOc=?=
Message-ID: <50ca001c5037b$beb0b680$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_50CA1_01C503C7.2E985E80"
Content-class: urn:content-classes:message

This is a multi-part message in MIME format.

------=_NextPart_000_50CA1_01C503C7.2E985E80
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64


------=_NextPart_000_50CA1_01C503C7.2E985E80
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy
Ij4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN
QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT4mbmJz
cDs8P3htbDpuYW1lc3BhY2UgcHJlZml4ID0gbyBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQt
Y29tOm9mZmljZTpvZmZpY2UiIC8+PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs
YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1V
Uz48Rk9OVCBmYWNlPbnZxcE+RGVhciBhbGwsPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZP
TlQgZmFjZT252cXBPiZuYnNwOzxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+
PEZPTlQgZmFjZT252cXBPkkgbW9zdCB3ZWxjb21lIHRoZSBkZWNpc2lvbiB0aGF0IHRoZSBzdWJq
ZWN0IGRlYWx0IGluIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5Q
YXBhZGltaXRyaW91PC9GT05UPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULUZB
TUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2NpaS1mb250LWZhbWlseTogudnFwSI+oa88
L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+cyBkcmFmdCBpcyB3aXRoaW4g
dGhlIHNjb3BlIG9mIENDQU1QIGNoYXJ0ZXIuPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N
c29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZP
TlQgZmFjZT252cXBPiZuYnNwOzxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+
PEZPTlQgZmFjZT252cXBPlJlZ2FyZGluZyB0aGUgaXNzdWUgb2YgVkxBTiBzd2l0Y2hpbmcsIHRo
aXMgaXMgY2xlYXJseSBub3QgdGhlIGZlYXR1cmU8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPbnZxcE+ZGVmaW5lZCBpbiBJRUVFIDgwMi4xUS4gSG93ZXZlciwgSSBkbyBub3Qg
dGhpbmsgSUVURiBzaG91bGQgPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwg
c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT25
2cXBPndhaXQgdW50aWwgSUVFRSBkZWZpbmUgbmV3IGFyY2hpdGVjdHVyZS4gSSBhbSB3b25kZXJp
bmc8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAw
Y20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+aWYgdGhlIHNjb3Bl
IG9mIENDQU1QIHdvcmsgZXhjbHVkZSBhbnkgdGVjaG5vbG9neSByZXF1aXJpbmc8L0ZPTlQ+PC9T
UEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+
PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+bW9kaWZpY2F0aW9uIG9uIGxlZ2FjeSBo
YXJkd2FyZSBzdHJ1Y3R1cmUuIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9
udnFwT4mbmJzcDs8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9y
bWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZh
Y2U9udnFwT5JZiBpdCBpcyBub3QsIGNvbnNpZGVyaW5nIGluZHVzdHJ5IG5lZWRzIG9uIGhpZ2gt
cGVyZm9ybWFuY2U8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i
TUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+RXRo
ZXJuZXQgc3dpdGNoLCBJIHRoaW5rIGl0IGlzIGRlc2lyYWJsZSB0aGUgc2NvcGUgb2Ygd29yayA8
L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20g
MGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+aW5jbHVkZSBib3RoIGNv
bnRyb2wgcGxhbmUgYW5kIGRhdGEgcGxhbmUuIEhvd2V2ZXIsIEkgYWxzbyA8L0ZPTlQ+PC9TUEFO
PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ
QU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+c3RyZXNzIHRoYXQgdGhlIGV4dGVudCBvZiB3
b3JrIG11c3QgYmUgZGlzY3Vzc2VkIGFuZCBkZWZpbmVkIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO
LVVTPjxGT05UIGZhY2U9udnFwT5pbiBhIHNlcGFyYXRlIHJlcXVpcmVtZW50IGRvY3VtZW50IHBy
aW9yIHRvIGFyY2hpdGVjdHVyYWwgd29yay48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z
b05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9O
VCBmYWNlPbnZxcE+Jm5ic3A7PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPbnZxcE+SSByYWlzZWQgdGhpcyBpc3N1ZSBpbiA8L0ZPTlQ+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFu
Zz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvZHJhZnQtamFpaHl1bmctY2NhbXAtbGVzcmVxdWlyZW1lbnQtMDAudHh0LDwvRk9OVD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT53aXRoIHNvbWUgZGlzY3Vzc2lvbiBvbiBv
dGhlciBjYW5kaWRhdGUgdGVjaG5vbG9naWVzLiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPbnZxcE+VW5mb3J0dW5hdGVseSwgSSBkaWRuPC9GT05UPjwvU1BBTj48U1BBTiBs
YW5nPUVOLVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1hc2Np
aS1mb250LWZhbWlseTogudnFwSI+oa88L1NQQU4+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNl
PbnZxcE+dCBnZXQgZW5vdWdoIHJlc3BvbnNlIG9uIHRoZSBwcm9wb3NhbCA8L0ZPTlQ+PC9TUEFO
PjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQ
QU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+dG8gZGF0ZS4gRGVmaW5pdGVseSwgdGhlcmUg
YXJlIG90aGVyIHRlY2hub2xvZ2llcyB3ZSBjYW4gPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz
cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+
PEZPTlQgZmFjZT252cXBPmNvbnNpZGVyIGZvciBMMlNDIGludGVyZmFjZS4gSSBob3BlIHBlb3Bs
ZSBwYXkgYXR0ZW50aW9uIDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0
eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnF
wT5vbiB0aGUgZHJhZnQgYW5kIGFsc28gZHJhZnQtamFpaHl1bmctY2NhbXAtbGVzZnJhbWV3b3Jr
LTAwLnR4dDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT4mbmJzcDs8
bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN
QVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5SZWdh
cmRpbmcgUGFwYWRpbWl0cmlvdTwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYXNjaWktZm9udC1mYW1pbHk6ILnZ
xcEiPqGvPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPnMgcHJvcG9zYWws
IEkgaGF2ZSBzb21lIGRvdWJ0cyBvbiA8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05v
cm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBm
YWNlPbnZxcE+Y29tcGF0aWJpbGl0eSBpc3N1ZS4gSSB0aGluayBpdCBtYXkgbm90IGJlIHVzZWQg
d2l0aCBFdGhlcm5ldDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl
PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5z
d2l0Y2hlcyBhbGxvY2F0aW5nIFZJRCBmb3IgZGlmZmVyZW50IHB1cnBvc2UuIEkgYW0gd29uZGVy
aW5nPC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog
MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPmhvdyBWTEFOIGlu
Zm9ybWF0aW9uIG9mIGN1c3RvbWVyIG5ldHdvcmsgY2FuIGJlIGRlbGl2ZXJlZDwvRk9OVD48L1NQ
QU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48
U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5hY3Jvc3MgcHJvdmlkZXIgbmV0d29yay4g
PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNt
IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPiZuYnNwOzxvOnA+PC9v
OnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjog
MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPk90aGVyIHBvaW50
IHRvIGNvbW1lbnQgaXMsIHBlcnNvbmFsbHkgSSB0aGluayBpdCBpcyBkZXNpcmFibGUgdG88L0ZP
TlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt
IDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+Zm9jdXMganVzdCBvbiBFdGhl
cm5ldCBpbnRlcmZhY2UuIFRoZSBkcmFmdCBpcyB0b28gaGVhdnk8L0ZPTlQ+PC9TUEFOPjwvUD4N
CjxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFu
Zz1FTi1VUz48Rk9OVCBmYWNlPbnZxcE+Y29tcGFyZWQgdG8gb3RoZXIgRXRoZXJuZXQgY29udHJv
bCBwcm90b2NvbHMgc3VjaCBhcyBNU1RQLjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv
Tm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05U
IGZhY2U9udnFwT5JbiBmYWN0LCBSU1ZQIGFuZCBJUCByb3V0aW5nIHByb3RvY29scyBhcmUgYWxs
IGhlYXZ5IHRvIEV0aGVybmV0LjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFs
IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9
udnFwT5XaHkgc2hvdWxkIElTUHMgcHJvdmlkaW5nIGp1c3QgbWV0cm8tRXRoZXJuZXQgc2Vydmlj
ZSBtdXN0IDwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJH
SU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVTPjxGT05UIGZhY2U9udnFwT5rbm93IGFs
bCB0aGUgdW5uZWNlc3Nhcnkgb3B0aW9ucyBkZXZpc2VkIGZvciBURE0gYW5kIEFUTT8gPC9GT05U
PjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw
cHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPiZuYnNwOzxvOnA+PC9vOnA+PC9G
T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBj
bSAwcHQiPjxTUEFOIGxhbmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPkkgdGhpbmsgaXQgd2lsbCBi
ZSBoZWxwZnVsIHRvIGluZHVzdHJ5IGlmIENDQU1QIHdvcmsgb24gPC9GT05UPjwvU1BBTj48L1A+
DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh
bmc9RU4tVVM+PEZPTlQgZmFjZT252cXBPmRlZGljYXRlZCwgbGlnaHR3ZWlnaHQgc3BlY2lmaWNh
dGlvbiBmb3IgRXRoZXJuZXQgb25seSBuZXR3b3JrLjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh
c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLVVT
PjxGT05UIGZhY2U9udnFwT4mbmJzcDs8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAg
Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO
LVVTPjxGT05UIGZhY2U9udnFwT5UaGFuayB5b3U8L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNz
PU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1VUz48
Rk9OVCBmYWNlPbnZxcE+Jm5ic3A7PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNs
YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1V
Uz48Rk9OVCBmYWNlPbnZxcE+SmFpaHl1bmcgQ2hvPC9GT05UPjwvU1BBTj48L1A+PC9ESVY+DQo8
RElWPiZuYnNwOzwvRElWPg0KPERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM
WTogsby4siI+DQo8RElWPg0KPERJViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM
WTogsby4siI+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5FVFJJLCBLb3JlYTwvRElWPg0KPERJ
Vj5waG9uZSA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDA0MikgODYwLTU1
MTQ8L0RJVj4NCjxESVY+b3ZlcnNlYTogKzgyLTQyLTg2MC01NTE0PC9ESVY+DQo8RElWPmZheDom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsrODIt
NDItODYxLTU1NTAmbmJzcDs8L0RJVj48L0RJVj48L0RJVj48L0RJVj48L0RJVj4NCjxESVYgc3R5
bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ILG8uLIiPiZuYnNwOzwvRElWPg0KPERJ
ViBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogsby4siI+DQo8RElWPjxCUj4t
LS0tLb/4ursguN69w8H2LS0tLS08QlI+PEI+urizvSC757b3OjwvQj4gIlNoYWhyYW0gRGF2YXJp
IiAmbHQ7U2hhaHJhbV9EYXZhcmlAcG1jLXNpZXJyYS5jb20mZ3Q7PEJSPjxCPrq4s70gs6/CpTo8
L0I+IDIwMDUtMDEtMjYgv8DA/CA2OjI1OjM2PEJSPjxCPrnetMIgu+e29zo8L0I+ICInQWRyaWFu
IEZhcnJlbCciICZsdDthZHJpYW5Ab2xkZG9nLmNvLnVrJmd0OywgImNjYW1wQG9wcy5pZXRmLm9y
ZyIgJmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8QlI+PEI+wvzBtjo8L0I+IDxCUj48Qj7Bprjx
OjwvQj4gUkU6IExheWVyIDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj48QlI+PC9ESVY+DQo8RElW
PjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+PEJSPg0KPFA+PEZPTlQg
c2l6ZT0yPkhpLDxCUj48QlI+VGhlIG9ubHkgaXNzdWUgdGhhdCBJIGhhdmUgaXMgd2l0aCBWTEFO
IHN3aXRjaGluZy4gU2luY2UgVkxBTiBzd2l0Y2hpbmc8QlI+aXMgbm90IGEgc3RhbmRhcmQgODAy
LjFRIGJlaGF2aW9yLCBpdCBjYW4ndCBiZSB1c2VkIHdpdGggZXhpc3RpbmcgRXRoZXJuZXQ8QlI+
aGFyZHdhcmUuIFRoZXJlZm9yZSB0aGUgc2NvcGUgb2YgdGhpcyBkcmFmdCBpcyBub3QgbGltaXRl
ZCB0byBjb250cm9sLXBsYW5lLDxCUj5hbmQgcmVxdWlyZXMgbmV3IGRhdGEtcGxhbmUgdGhhdCBp
cyBub3QgZGVmaW5lZCBpbiBJRUVFIHlldC48QlI+PEJSPklmIHRoZSBWTEFOIHN3aXRjaGluZyBp
cyByZW1vdmVkIGZyb20gdGhlIGRyYWZ0LCBJIHN1cHBvcnQgYWNjZXB0aW5nIGl0IGFzPEJSPmEg
V0cgZHJhZnQuPEJSPjxCUj5Zb3Vycyw8QlI+LVNoYWhyYW08QlI+PEJSPiZndDsgLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmcg
WzxBIGhyZWY9Im1haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+
bWFpbHRvOm93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZzwvQT5dT248QlI+Jmd0OyBCZWhhbGYgT2Yg
QWRyaWFuIEZhcnJlbDxCUj4mZ3Q7IFNlbnQ6IFN1bmRheSwgSmFudWFyeSAyMywgMjAwNSA2OjQ2
IEFNPEJSPiZndDsgVG86IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj4mZ3Q7IFN1YmplY3Q6IExheWVy
IDIgU3dpdGNoaW5nIENhcHMgTFNQczxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBBbGwsPEJSPiZn
dDs8QlI+Jmd0OyBUaGVyZSBpcyBhIGRyYWZ0PEJSPiZndDsgKGRyYWZ0LXBhcGFkaW1pdHJpb3Ut
Y2NhbXAtZ21wbHMtbDJzYy1sc3AtMDMudHh0KSB0aGF0IHdlPEJSPiZndDsgaGF2ZSBkaXNjdXNz
ZWQgYXQgc2V2ZXJhbCBvZiB0aGUgbW9yZSByZWNlbnQgQ0NBTVAgbWVldGluZ3MsIGFuZCBoYXZl
PEJSPiZndDsgZGVjaWRlZCB0aGF0IHRoZSBzdWJqZWN0IGlzIHdpdGhpbiBzY29wZSBmb3Igb3Vy
IGNoYXJ0ZXIuPEJSPiZndDs8QlI+Jmd0OyBUaGUgcXVlc3Rpb25zIHdlIGhhdmUgZmFjZWQgaGF2
ZSBiZWVuOjxCUj4mZ3Q7IC0gaXMgdGhlIHByb2JsZW0gd2VsbCBlbm91Z2ggYXJ0aWN1bGF0ZWQ/
PEJSPiZndDsgLSBpcyB0aGlzIHRoZSBzb2x1dGlvbiB0aGF0IHRoZSBXRyB3YW50cyB0byBwdXJz
dWU/PEJSPiZndDsgLSBpcyB0aGVyZSBhIGhpZ2ggZW5vdWdoIGxldmVsIG9mIGludGVyZXN0IGlu
IHRoaXMgd29yaz88QlI+Jmd0OzxCUj4mZ3Q7IElmIHRoZSBhbnN3ZXIgdG8gYWxsIHRocmVlIHF1
ZXN0aW9ucyBpcyAieWVzIiB0aGVuIHdlIGNhbjxCUj4mZ3Q7IGFkb3B0IHRoZSBkcmFmdDxCUj4m
Z3Q7IGFzIGEgV0cgZG9jdW1lbnQgYW5kIG1vdmUgZm9yd2FyZHMuPEJSPiZndDs8QlI+Jmd0OyBO
b3RlOiBJIHRoaW5rIHRoZXJlIGFyZSBhIGxhcmdlIG51bWJlciBvZiBtaW5vciBpc3N1ZXMgdG88
QlI+Jmd0OyBjbGVhciB1cCB3aXRoPEJSPiZndDsgdGhpcyBkcmFmdCwgYnV0IGhvcGVmdWxseSB0
aGlzIGlzIG9ydGhvZ29uYWwgdG8gd2hldGhlciB3ZTxCUj4mZ3Q7IG1ha2UgdGhpcyBhIFdHPEJS
PiZndDsgZHJhZnQgb3Igbm90LjxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzLDxCUj4mZ3Q7IEFkcmlh
bjxCUj4mZ3Q7PEJSPiZndDs8QlI+PEJSPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+PGltZyBzdHls
ZT0iZGlzcGxheTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmku
cmUua3IvRXh0ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5h
bWU9Y2NhbXAlNDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPWphaWh5dW5nQGV0cmkucmUua3ImbWVz
c2FnZWlkPSUzQzZhZmYxZTY3LTM5ZDAtNGJjZC04MGQyLTc0ZjI0N2Q0OWJjM0BldHJpLnJlLmty
JTNFIj4=

------=_NextPart_000_50CA1_01C503C7.2E985E80--



Envelope-to: [e-mail]
Delivery-date: Tue, 25 Jan 2005 21:26:56 +0000
Message-ID: <[e-mail]_nt.nt.pmc-sierra.bc.ca>
From: Shahram Davari <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, [e-mail]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Tue, 25 Jan 2005 13:25:36 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi,

The only issue that I have is with VLAN switching. Since VLAN switching
is not a standard 802.1Q behavior, it can't be used with existing Ethernet
hardware. Therefore the scope of this draft is not limited to control-plane,
and requires new data-plane that is not defined in IEEE yet.

If the VLAN switching is removed from the draft, I support accepting it as
a WG draft.

Yours,
-Shahram

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Adrian Farrel
> Sent: Sunday, January 23, 2005 6:46 AM
> To: [e-mail]
> Subject: Layer 2 Switching Caps LSPs
> 
> 
> All,
> 
> There is a draft 
> (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
> have discussed at several of the more recent CCAMP meetings, and have
> decided that the subject is within scope for our charter.
> 
> The questions we have faced have been:
> - is the problem well enough articulated?
> - is this the solution that the WG wants to pursue?
> - is there a high enough level of interest in this work?
> 
> If the answer to all three questions is "yes" then we can 
> adopt the draft
> as a WG document and move forwards.
> 
> Note: I think there are a large number of minor issues to 
> clear up with
> this draft, but hopefully this is orthogonal to whether we 
> make this a WG
> draft or not.
> 
> Thanks,
> Adrian
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 25 Jan 2005 19:36:39 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/alternative; boundary=Apple-Mail-6--474593510
Message-Id: <[e-mail]>
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 25 Jan 2005 14:33:45 -0500
To: "Adrian Farrel" <[e-mail]>

--Apple-Mail-6--474593510
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

Hi Adrian,

Agreed comments have been removed - See in line,

On Jan 14, 2005, at 6:43 AM, Adrian Farrel wrote:

> It seems to me that this draft is applicable to a strict ERO where one=20=

> of the hops is a non-specific abstract node such as an AS number. This=20=

> is made clear in section 2, but the Abstract and Introduction (yeah,=20=

> and also the title and draft name) do not adequately expose this fact.=20=

> But, further, the Introduction talks only about reoptimization without=20=

> any mention of loose hops or abstract nodes. Thus the draft is=20
> schizoid to the third degree - is this loose path reoptimization,=20
> reoptimization of loose and non-specific abstract nodes, or general=20
> reoptimization? The draft needs to be consistent and clear.
>
>
>

Agree, the following definition has been adopted throughout the=20
document: "A loosely routed LSP is defined as an LSP that follows a=20
path that contains at least one loose hop or a strict (abstract node)=20
hop"

I guess that the document title can remain unchanged considering that a=20=

loose path also includes the case of a path where at least one hop is=20
an abstract node.

> =A0
> The title contains acronyms which need to be spelled out (MPLS and=20
> LSP).
>
>
>
> =A0

Added

> The Abstract is too long. Need it about half the length. You can move=20=

> some of the material into the introduction which is currently rather=20=

> short (shorter than the abstract!) Same comment about acronyms (MPLS,=20=

> GMPLS, TE, LSP, ERO) - make sure they are expanded for their first=20
> usage.
>
>
>
> =A0

ok, sections expanded, others shortened ... overall same length ;-)

> Section 2 states that an=A0ERO expansion is=A0either up to the next =
loose=20
> hop or to the destination. But, in fact, the ERO expansion may also be=20=

> any partial fragment towards either of these targets (including next=20=

> hop resolution). I suggest re-wording this paragraph to list (as=20
> bullets) what an ERO might contain, and in a separate list, what the=20=

> computation might produce.
>
>
>

We listed in this paragraph the most usual case of ERO expansion. If=20
you're ok with this, elaborating further on ERO expansion is out of the=20=

scope of this document.

> In section 4.1 you add a note about the selection of component links=20=

> from within a bundle. While this is true, it is unclear why you pick=20=

> this case out but don't describe the selection of alternate resources=20=

> (e.g. lambdas). This is associated to the new error values defined in=20=

> section 4.2. How would you report a component link going oos? How=20
> would you report a link resource (e.g. a lambda) going oos? If you use=20=

> "local link maintenance required" won't the computing node believe=20
> that the whole link is unusable?

Indeed, this is why the node in charge of this link going oos should=20
make the appropriate local decision on whether to report it, should an=20=

equivalent link not be found.

> If your answer here is that the recomputation will ignore the error=20
> value and will perform a recomputation based on the new TED (see=20
> [GR-SHUT]) then why do you need to distinguish between link=20
> maintenance required and node maintenance required? If you actually=20
> need to report the component link or resource as a separate quantity,=20=

> I suggest you refer to the crankback draft.
>
>
>
> =A0
> Section 4.1
>
>
>
> I'm not comfortable with the Session Attributes toggling like this.=20
> This type of function is what the Admin Status object was invented=20
> for.
>
>
>
> =A0
> Section 5.3.1
>
>
>
> =A0=A0 This
>
>
>
> =A0=A0 bit is then cleared in subsequent RSVP path messages sent=20
> downstream.
>
>
>
> This implies that a Path refresh *never* carries this bit set (which=20=

> makes it a trigger when it comes after a Path with the bit set).
>
>
>
> Thus we may lose the request (either through a lost Path message, or=20=

> through a refresh catching up with a trigger Path message).=A0I think =
we=20
> discussed this before. You need to make it clear in the draft that=20
> these requests can be lost.
>
>
>
> I think it is also worth considering how to prevent the toggling off=20=

> of the bit from appearing as a trigger message.
>
>
>

Case of a lost path message: in order to cover this case, *the*=20
solution consists of using reliable messaging as defined in RFC2961=20
(note that any change in a Path message objects would indeed not be=20
detected if the Path is lost, this applies to any other LSP attribute).=20=

Note also, that resending the same Path message N times (which is an=20
option that we did investigate) would not really solved the issue since=20=

the Path message would be resent after a delay which is dependent of=20
the refresh period (which can itself be very long). Then this causes=20
race condition with the reoptimization timer running on the head-end=20
LSR which may lead to undesirable conditions. Thus, a Path message may=20=

indeed be lost and the solution consists of using reliable messaging,=20
should the operator consider the lost of such Path message be=20
unacceptable. I will add some text there. thanks.

> =A0
> In section 5.3.2
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 - The link (sub-code=3D7) or the node =
(sub-code=3D8) MUST be
>
>
>
>  =A0=A0=A0=A0=A0=A0=A0 locally registered for further reference (the =
TE database must
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 be updated)
>
>
>
> What does "the TE database must be updated" mean? Are you saying that=20=

> the TED is now built from information flooded by the IGP *and* by=20
> information fed back from signaling? If so (and I don't approve!) then=20=

> you must define what happens when you receive a new LSA for the=20
> specific link that contradicts the information signaled. There is a=20
> strong argument that says that *the* method we use for building the=20
> TED is IGP flooding - if this mechanism doesn't provide you with the=20=

> information you need, then you should propose extensions to the IGP,=20=

> not hook the information onto signaling.
>
>
>

Let me sightly disagree here. I'm fine to not mention this since this=20
may be implementation specific. That said, I do think that this is=20
highly desirable (in combination with timer-based mechanism) so as to=20
speed convergence. Typically, upon receiving a PathErr message it does=20=

make sense to first update your TED or the head-end will keep trying=20
the same path until an LSA/LSP get received. In many networks, such=20
optimization is definitely required to speed up the TE LSP rerouting.=20
Note that such behavior is implemented in commercial product.

> OTOH it may be that all you mean is that the Session state should be=20=

> updated to indicate the link or node that is being shut down so that=20=

> later recomputation can avoid this link. In this case, I suggest you=20=

> refer to the CCAMP crankback draft.
>
>
>

Still such update may be beneficial to other TE LSP and is orthogonal=20
to the use of crankback ?

> =A0
> In section 5.3.2
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 - ... Note that in the case of TE LSP
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 spanning multiple administrative domains, it may =
be desirable
>
>
>
>  =A0=A0=A0=A0=A0=A0=A0 for the boundary LSR to modify the RSVP =
PathError message and
>
>
>
> =A0=A0=A0=A0=A0=A0=A0 insert its own address for confidentiality =
reason.
>
>
>
> Yes. Good point, but doesn't the error code also need to change?=20
> Otherwise it will appear that the border node is the node being taken=20=

> oos.
>
>
>

If you agree with this argument I would vote for keeping the same error=20=

code since this would not change the action taken by the head-end.

> =A0
> Section 5.3.3. suggests the use of a timer. You must, therefore,=20
> suggest a default time value. I suspect that you want to suggest some=20=

> basic multiple of the path computation time or of the IGP refresh=20
> period.
>
>

Right, good point. Default of 5s has been suggested (not really=20
correlated to the path computation time or the IGP refresh period since=20=

it relates more to the number of LSPs and level of network "dynamicity"=20=

which includes a number of parameters).

>
> =A0
> Section 6
>
>
>
> Need to describe the processing by an LSR that does not understand the=20=

> new flag (rather than understand it but not support it). note that you=20=

> cannot define the behavior of legacy LSRs in this draft, so you must=20=

> reference behavior defined in some other document.
>
>
>
> Ditto the new error code.
>
>
>

Unfortunately I do not think that RFC3209 specifies the behavior of a=20
node receiving a SESSION ATTRIBUTE flag that it does not understand ...=20=

An implementation should then just ignore such flag if it does not=20
understand it.

> =A0
> Section 7
>
>
>
> This technique has implications for the trust model between domains.=20=

> In particular, one domain may cause another to perform additional=20
> (excess or unnecessary) work simply to ease its own task or for=20
> malicious reasons. Similarly, a headend domain might choose to ignore=20=

> the requests for re-optimization issued by another domain. I think you=20=

> need to point out that the peering agreements between domains need to=20=

> include a definition of how this technique is supported.
>
>

Agree Adrian and this is in line with the Inter-area req doc. Will add=20=

some text:

"Furthermore, a head-end LSR may decide to ignore explicit notification=20=

coming from a mid-point residing in another domain. Similarly, an LSR=20
may decide to ignore (or accept but up to a pre-defined rate) path=20
re-evaluation requests originated by a head-end LSR of another domain.=20=

"

thanks.

>
> Question...
>
>
>
> =A0
>
>
>
>
>
> How does the process of unsolicited notification (of a potential=20
> better path rather than of a link going oos) avoid thrashing races? As=20=

> a very simple example, consider the following n/w.
>
>
>
> =A0
> <-A1->=A0<--A0-> <-A2->
>
>
>
> A-----B=A0=A0=A0=A0=A0=A0 C-----D
>
>
>
> =A0=A0=A0 =A0 |=A0=A0=A0=A0=A0=A0 |
>
>
>
> =A0=A0=A0 =A0 |=A0=A0=A0=A0=A0=A0 |
>
>
>
> E-----F---G---H-----I
>
>
>
> =A0
> Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and=20
> {E,F(L),C(L),D} producing paths ABFGHI and EFGHCD.
>
>
>
> =A0
> Now install a *low* bandwidth link BC capable of carrying either but=20=

> not both LSPs. Both B and F will notice that the LSPs entering A0=20
> through them can be re-optimized and will report the fact to A and E=20=

> respectively.

note that if the link is a "low" bw link, it is unlikely that B and F=20
will report a better path but yes that could happen depending on the=20
IGP links costs indeed.

> Both A and E will attempt mb4b, but (of course) only one will succeed.=20=

> In a small network, this is not a big deal, but in a large network=20
> with a lot of LSPs this is clearly a waste of processing and will=20
> cause a degree of network thrash maybe only in the control plane, but=20=

> maybe in the data plane if a lower priority LSP is re-routed first. In=20=

> fact, this scenario can cause significant disruption in the data plane=20=

> as the re-routed LSP will be preempted and could have been=20
> successfully left in its original place.
>
>

Indeed, but this is no different that any other reoptimization scenario=20=

in a single area. If for example, a link is restored within an area=20
that could offer a potentially more optimal path to a large number of=20
TE LSPs, there could be race conditions indeed. This is usually sorted=20=

out by using jittered reoptimization at the head-end.

>
> =A0
> It seems that a considerably sophisticated policy is required for any=20=

> domain, but particularly core domains like A0. In effect, the=A0domain=20=

> needs to evaluate the new link by examining all LSPs in the system and=20=

> selecting which one(s) should be re-optimized. This type of processing=20=

> is non-trivial and uses information stores that are not generally=20
> available (i.e. LSP maps).
>
>
>
>
>
>
> =A0
> Thus I would suggest removing the unsolicited notification of=20
> reoptimization opportunities (while retaining the unsolicited=20
> notification of links going oos) or requiring that the policy be=20
> timer-based not event triggered.
>
>
>
>

We would definitely prefer to keep this mode. Implementation could just=20=

activate the function for *some* sensitive LSP + combined with with=20
jittered reoptimization but such notification is desirable to quickly=20
take advantage of a newly restored link.

NOTE that link dampening (IGP) can also be used here; this had been=20
discussed in the FRR document.

Thanks for your comments !

JP.

> =A0
> =A0
> Adrian
>
>
>
 =20
  =20=

--Apple-Mail-6--474593510
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1

Hi Adrian,


Agreed comments have been removed - See in line,


On Jan 14, 2005, at 6:43 AM, Adrian Farrel wrote:


<excerpt><fixed><smaller><smaller><x-tad-smaller>It seems to me that
this draft is applicable to a strict ERO where one of the hops is a
non-specific abstract node such as an AS number. This is made clear in
section 2, but the Abstract and Introduction (yeah, and also the title
and draft name) do not adequately expose this fact. But, further, the
Introduction talks only about reoptimization without any mention of
loose hops or abstract nodes. Thus the draft is schizoid to the third
degree - is this loose path reoptimization, reoptimization of loose
and non-specific abstract nodes, or general reoptimization? The draft
needs to be consistent and =
clear.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Agree, the following definition has been adopted throughout the
document: "<italic>A loosely routed LSP is defined as an LSP that
follows a path that contains at least one loose hop or a strict
(abstract node) hop"</italic>


I guess that the document title can remain unchanged considering that
a loose path also includes the case of a path where at least one hop
is an abstract node.


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>The title contains acronyms
which need to be spelled out (MPLS and =
LSP).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

</excerpt>

Added


<excerpt><fixed><smaller><smaller><x-tad-smaller>The Abstract is too
long. Need it about half the length. You can move some of the material
into the introduction which is currently rather short (shorter than
the abstract!) Same comment about acronyms (MPLS, GMPLS, TE, LSP, ERO)
- make sure they are expanded for their first =
usage.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

</excerpt>

ok, sections expanded, others shortened ... overall same length ;-)


<excerpt><fixed><smaller><smaller><x-tad-smaller>Section 2 states that
an=A0ERO expansion is=A0either up to the next loose hop or to the
destination. But, in fact, the ERO expansion may also be any partial
fragment towards either of these targets (including next hop
resolution). I suggest re-wording this paragraph to list (as bullets)
what an ERO might contain, and in a separate list, what the
computation might =
produce.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

We listed in this paragraph the most usual case of ERO expansion. If
you're ok with this, elaborating further on ERO expansion is out of
the scope of this document.


<excerpt><fixed><smaller><smaller><x-tad-smaller>In section 4.1 you
add a note about the selection of component links from within a
bundle. While this is true, it is unclear why you pick this case out
but don't describe the selection of alternate resources (e.g.
lambdas). This is associated to the new error values defined in
section 4.2. How would you report a component link going oos? How
would you report a link resource (e.g. a lambda) going oos? If you use
"local link maintenance required" won't the computing node believe
that the whole link is unusable?=20

</x-tad-smaller></smaller></smaller></fixed></excerpt>

Indeed, this is why the node in charge of this link going oos should
make the appropriate local decision on whether to report it, should an
equivalent link not be found.=20


<excerpt><fixed><smaller><smaller><x-tad-smaller>If your answer here
is that the recomputation will ignore the error value and will perform
a recomputation based on the new TED (see [GR-SHUT]) then why do you
need to distinguish between link maintenance required and node
maintenance required? If you actually need to report the component
link or resource as a separate quantity, I suggest you refer to the
crankback =
draft.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

<fixed><smaller><smaller><x-tad-smaller>Section =
4.1</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>I'm not comfortable with the
Session Attributes toggling like this. This type of function is what
the Admin Status object was invented =
for.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

<fixed><smaller><smaller><x-tad-smaller>Section =
5.3.1</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0 This =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0 bit is then cleared in
subsequent RSVP path messages sent =
downstream.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>=





<fixed><smaller><smaller><x-tad-smaller>This implies that a Path
refresh *never* carries this bit set (which makes it a trigger when it
comes after a Path with the bit =
set).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>Thus we may lose the request
(either through a lost Path message, or through a refresh catching up
with a trigger Path message).=A0I think we discussed this before. You
need to make it clear in the draft that these requests can be =
lost.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>I think it is also worth
considering how to prevent the toggling off of the bit from appearing
as a trigger =
message.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Case of a lost path message: in order to cover this case, *the*
solution consists of using reliable messaging as defined in RFC2961
(note that any change in a Path message objects would indeed not be
detected if the Path is lost, this applies to any other LSP
attribute). Note also, that resending the same Path message N times
(which is an option that we did investigate) would not really solved
the issue since the Path message would be resent after a delay which
is dependent of the refresh period (which can itself be very long).
Then this causes race condition with the reoptimization timer running
on the head-end LSR which may lead to undesirable conditions. Thus, a
Path message may indeed be lost and the solution consists of using
reliable messaging, should the operator consider the lost of such Path
message be unacceptable. I will add some text there. thanks.=20


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>In section =
5.3.2</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0 - The link
(sub-code=3D7) or the node (sub-code=3D8) MUST be =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller> =A0=A0=A0=A0=A0=A0=A0 locally =
registered
for further reference (the TE database must =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0 be =
updated)</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>What does "the TE database
must be updated" mean? Are you saying that the TED is now built from
information flooded by the IGP *and* by information fed back from
signaling? If so (and I don't approve!) then you must define what
happens when you receive a new LSA for the specific link that
contradicts the information signaled. There is a strong argument that
says that *the* method we use for building the TED is IGP flooding -
if this mechanism doesn't provide you with the information you need,
then you should propose extensions to the IGP, not hook the
information onto =
signaling.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Let me sightly disagree here. I'm fine to not mention this since this
may be implementation specific. That said, I do think that this is
highly desirable (in combination with timer-based mechanism) so as to
speed convergence. Typically, upon receiving a PathErr message it does
make sense to first update your TED or the head-end will keep trying
the same path until an LSA/LSP get received. In many networks, such
optimization is definitely required to speed up the TE LSP rerouting.
Note that such behavior is implemented in commercial product.=20


<excerpt><fixed><smaller><smaller><x-tad-smaller>OTOH it may be that
all you mean is that the Session state should be updated to indicate
the link or node that is being shut down so that later recomputation
can avoid this link. In this case, I suggest you refer to the CCAMP
crankback =
draft.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Still such update may be beneficial to other TE LSP and is orthogonal
to the use of crankback ?


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>In section =
5.3.2</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0 - ... Note =
that in the
case of TE LSP =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0 spanning =
multiple
administrative domains, it may be =
desirable</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller> =A0=A0=A0=A0=A0=A0=A0 for the =
boundary LSR
to modify the RSVP PathError message and =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0=A0=A0=A0=A0 insert its =
own address
for confidentiality reason. =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>Yes. Good point, but doesn't
the error code also need to change? Otherwise it will appear that the
border node is the node being taken =
oos.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

If you agree with this argument I would vote for keeping the same
error code since this would not change the action taken by the
head-end.


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>Section 5.3.3. suggests the
use of a timer. You must, therefore, suggest a default time value. I
suspect that you want to suggest some basic multiple of the path
computation time or of the IGP refresh =
period.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Right, good point. Default of 5s has been suggested (not really
correlated to the path computation time or the IGP refresh period
since it relates more to the number of LSPs and level of network
"dynamicity" which includes a number of parameters).


<excerpt>

=A0

<fixed><smaller><smaller><x-tad-smaller>Section =
6</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>Need to describe the
processing by an LSR that does not understand the new flag (rather
than understand it but not support it). note that you cannot define
the behavior of legacy LSRs in this draft, so you must reference
behavior defined in some other =
document.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>Ditto the new error =
code.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




</excerpt>

Unfortunately I do not think that RFC3209 specifies the behavior of a
node receiving a SESSION ATTRIBUTE flag that it does not understand
... An implementation should then just ignore such flag if it does not
understand it.


<excerpt>=A0

<fixed><smaller><smaller><x-tad-smaller>Section =
7</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>This technique has
implications for the trust model between domains. In particular, one
domain may cause another to perform additional (excess or unnecessary)
work simply to ease its own task or for malicious reasons. Similarly,
a headend domain might choose to ignore the requests for
re-optimization issued by another domain. I think you need to point
out that the peering agreements between domains need to include a
definition of how this technique is =
supported.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Agree Adrian and this is in line with the Inter-area req doc. Will add
some text:


<italic>"Furthermore, a head-end LSR may decide to ignore explicit
notification coming from a mid-point residing in another domain.
Similarly, an LSR may decide to ignore (or accept but up to a
pre-defined rate) path re-evaluation requests originated by a head-end
LSR of another domain. "

</italic>

thanks.


<excerpt>

=
<fixed><smaller><smaller><x-tad-smaller>Question...</x-tad-smaller></small=
er></smaller></fixed></excerpt><excerpt>




=
<fixed><smaller><smaller><x-tad-smaller>=A0</x-tad-smaller></smaller></sma=
ller></fixed></excerpt><excerpt>






<fixed><smaller><smaller><x-tad-smaller>How does the process of
unsolicited notification (of a potential better path rather than of a
link going oos) avoid thrashing races? As a very simple example,
consider the following =
n/w.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

<fixed><smaller><smaller><x-tad-smaller><<-A1->=A0<<--A0-> =
<<-A2-></x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>A-----B=A0=A0=A0=A0=A0=A0 =
C-----D</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0 =A0 |=A0=A0=A0=A0=A0=A0 =
|</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller>=A0=A0=A0 =A0 |=A0=A0=A0=A0=A0=A0 =
|</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=
<fixed><smaller><smaller><x-tad-smaller>E-----F---G---H-----I</x-tad-small=
er></smaller></smaller></fixed></excerpt><excerpt>




=A0

<fixed><smaller><smaller><x-tad-smaller>Set up two LSPs AI and ED
using EROs {A,B(L),H(L),I} and {E,F(L),C(L),D} producing paths ABFGHI
and =
EFGHCD.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




=A0

<fixed><smaller><smaller><x-tad-smaller>Now install a *low* bandwidth
link BC capable of carrying either but not both LSPs. Both B and F
will notice that the LSPs entering A0 through them can be re-optimized
and will report the fact to A and E respectively.=20

</x-tad-smaller></smaller></smaller></fixed></excerpt>

note that if the link is a "low" bw link, it is unlikely that B and F
will report a better path but yes that could happen depending on the
IGP links costs indeed.


<excerpt><fixed><smaller><smaller><x-tad-smaller>Both A and E will
attempt mb4b, but (of course) only one will succeed. In a small
network, this is not a big deal, but in a large network with a lot of
LSPs this is clearly a waste of processing and will cause a degree of
network thrash maybe only in the control plane, but maybe in the data
plane if a lower priority LSP is re-routed first. In fact, this
scenario can cause significant disruption in the data plane as the
re-routed LSP will be preempted and could have been successfully left
in its original =
place.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



</excerpt>

Indeed, but this is no different that any other reoptimization
scenario in a single area. If for example, a link is restored within
an area that could offer a potentially more optimal path to a large
number of TE LSPs, there could be race conditions indeed. This is
usually sorted out by using jittered reoptimization at the head-end.


<excerpt>

=A0

<fixed><smaller><smaller><x-tad-smaller>It seems that a considerably
sophisticated policy is required for any domain, but particularly core
domains like A0. In effect, the=A0domain needs to evaluate the new link
by examining all LSPs in the system and selecting which one(s) should
be re-optimized. This type of processing is non-trivial and uses
information stores that are not generally available (i.e. LSP =
maps).</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>




<fixed><smaller><smaller><x-tad-smaller> =
</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>



=A0

<fixed><smaller><smaller><x-tad-smaller>Thus I would suggest removing
the unsolicited notification of reoptimization opportunities (while
retaining the unsolicited notification of links going oos) or
requiring that the policy be timer-based not event =
triggered.</x-tad-smaller></smaller></smaller></fixed></excerpt><excerpt>





</excerpt>

We would definitely prefer to keep this mode. Implementation could
just activate the function for *some* sensitive LSP + combined with
with jittered reoptimization but such notification is desirable to
quickly take advantage of a newly restored link.


NOTE that link dampening (IGP) can also be used here; this had been
discussed in the FRR document.


Thanks for your comments !


JP.


<excerpt>=A0

=A0

=
<fixed><smaller><smaller><x-tad-smaller>Adrian</x-tad-smaller></smaller></=
smaller></fixed></excerpt><excerpt>




</excerpt>  =20=

--Apple-Mail-6--474593510--



Envelope-to: [e-mail]
Delivery-date: Tue, 25 Jan 2005 19:36:29 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 25 Jan 2005 14:34:06 -0500
To: "Adrian Farrel" <[e-mail]>

Hi Adrian,

On Jan 21, 2005, at 6:37 AM, Adrian Farrel wrote:

> OK,
>
> This concludes the WG last call on this draft.
>
> Authors/editors: you got comments from four people, some of them fairly
> detailed. I think there is probably a fair bit of work to do.
>
> As guardians of this draft on behalf of the working group, I'd like to  
> ask
> that you track all of the comments and record either the agreed  
> discussion
> that means that no action is required, or the agreed resolution and  
> change
> to the draft.
>

sure, new rev incorporating comments will be posted soon.

Thanks.

JP.

> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, January 05, 2005 6:40 PM
> Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
>
>
>> This email starts a two week last call on
>>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt 
> -00.txt
>>
>> Please send your comments to the list or to the chairs by noon GMT on
> 20th
>> January 2005.
>>
>> Thanks,
>> Adrian and Kireeti
>>
>>
>>
>>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 24 Jan 2005 09:39:36 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: Adrian Farrel <[e-mail]>, [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:39:08 -0500
To: Arthi Ayyangar <[e-mail]>

Hi Arthi,

On Jan 20, 2005, at 2:51 PM, Arthi Ayyangar wrote:

> Adrian, all,
>
> Just a few comments on this draft.
>
> Section 2 and elsewhere: there are repeated statements & notes as to  
> "CSPF
> or any other PCE-based path computation method"
> --> I don't think it is relevant to this document whether the path
> computation is local or remote or done by a PCE or not. IMO, it would  
> be
> enough to just say "path computation".
>

This was for the sake of illustration but I agree of course. Text  
updated, thanks.

> Paragraph 4 in Section 3, Section 4.2, and 2nd and 3rd paragraphs in  
> 5.3.2
> ----> This draft not only refers to another draft (and it is *not* a
> normative reference) draft-ali-ccamp-mpls-graceful-shutdown-00.txt, but
> also seems to introduce error codes and subcodes (subcode 7 & 8) which  
> are
> actually relevant to GR-SHUTDOWN draft rather than this document. IMO,  
> if
> graceful-shutdown procedures need new error codes/subcodes, they must  
> be
> introduced in the graceful-shutdown draft and not in this  
> re-optimization
> draft. Otherwise, what is the point of having the other draft if the
> codes are being standardized here ?

Agree, ref to GR-SHUTDOWN has been removed and draft GR-SHUTDOWN will  
be updated accordingly.

Thanks for your comments.

JP.

>
> thanks,
> -arthi
>
> So the
>> This email starts a two week last call on
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path- 
>> reopt-00.txt
>>
>> Please send your comments to the list or to the chairs by noon GMT on  
>> 20th
>> January 2005.
>>
>> Thanks,
>> Adrian and Kireeti
>>
>>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 24 Jan 2005 09:32:18 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: multipart/alternative; boundary=Apple-Mail-144--597084343
Message-Id: <[e-mail]>
Cc: [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:32:14 -0500
To: "Stephen Shew" <[e-mail]>

--Apple-Mail-144--597084343
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed

Hi Stephen,

On Jan 6, 2005, at 12:18 PM, Stephen Shew wrote:

> I have read <draft-ietf-ccamp-loose-path-reopt-00.txt> and have some=20=

> questions and comments.
>
> 1. The actual reoptimization procedure is not specified as this is=20
> done via the make before break method or some other way.=A0 Only the=20=

> triggers to cause reoptimization are specified.=A0 Is this correct?
>

Correct (reference to "Make before Break" as defined in RFC3209 has=20
been added).

> 2. In mid-point explict notification mode where a link or node is=20
> specified, I am unsure what link is being referred to.=A0 Because this=20=

> is an LSP, it is either the link upstream to to the mid-point node or=20=

> the one downstream.=A0 Is there some RSVP convention that =
distinguishes=20
> this?=A0 I think it is downstream but don't know for sure.
>

Downstream link traversed by the TE LSP indeed.

> 3. Again in mid-point explict notification mode it is not clear what=20=

> is meant by "the TE database must be updated".=A0 Does it mean that =
the=20
> link or node is removed from the local TE database so that the first=20=

> upstream node that expands the ERO can compute around the link/node?=A0

No since no such reroute by intermediate node is proposed here as the=20
mechanism is entirely targeted for head-end reoptimization. The point=20
here is just for a node to update its TED so as to take into account=20
the notification of the link that will be removed for maintenance,=20
should further path computation be required. Note that such procedure=20
is usually followed by current implementations in other contexts.

>  If so, then it is necessary to indicate what the link and node are=20
> for the non-packet LSP case.=A0 That is, I am assuming that the RSVP=20=

> signaling process (control) is separated from the bearer plane (e.g.,=20=

> a SONET cross connect).=A0 It is the identity of the control "node" =
that=20
> is put into the PathErr whereas the bearer "node" has a different=20
> identity.
>
> To do this, I would suggest that the IF_ID ERROR_SPEC object (from=20
> [RFC3473]) and all of the TLVs it may contain including from=20
> draft-ietf-ccamp-crankback-03.txt be added to the PathErr message=20
> when=A0 Error sub-codes 7&8 are used.=A0 This will enable the actual =
link=20
> to be known.=A0 In the case of node, Type 8 (NODE_ID) would identify =
the=20
> bearer node.
>
> For security reasons, if the LSP spans domains, the OSPF_AREA or=20
> AUTONOMOUS_SYSTEM TLVs could be used when error subcode 8 is passed=20
> upstream.
>
> 4. In the same context as point 3, does the head-end LSR do anything=20=

> to its TE database based on the link or node Error sub-codes?
>

As in the previous case: note of course that the Head-end would not=20
update its TED in the context of inter-area/AS TE if the link/node to=20
be maintained does not reside in the head-end area.

Thanks for your comments.

JP.

> > -----Original Message-----
> > From: [e-mail]
>  > [mailto:[e-mail]] On Behalf Of Adrian Farrel
> > Sent: Wednesday, January 05, 2005 13:41
> > To: [e-mail]
> > Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
> >
> >
> > This email starts a two week last call on
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat
> > h-reopt-00.txt
> >
> > Please send your comments to the list or to the chairs by
> > noon GMT on 20th January 2005.
> >
> > Thanks,
> > Adrian and Kireeti

--Apple-Mail-144--597084343
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1

Hi Stephen,


On Jan 6, 2005, at 12:18 PM, Stephen Shew wrote:


<excerpt><smaller><x-tad-smaller>I have read
<<draft-ietf-ccamp-loose-path-reopt-00.txt> and have some questions
and comments.</x-tad-smaller></smaller></excerpt><excerpt>=20


<smaller><x-tad-smaller>1. The actual reoptimization procedure is not
specified as this is done via the make before break method or some
other way.=A0 Only the triggers to cause reoptimization are specified.=A0
Is this correct?</x-tad-smaller></smaller></excerpt><excerpt>


</excerpt>

Correct (reference to "Make before Break" as defined in RFC3209 has
been added).


<excerpt><smaller><x-tad-smaller>2. In mid-point explict notification
mode where a link or node is specified, I am unsure what link is being
referred to.=A0 Because this is an LSP, it is either the link upstream
to to the mid-point node or the one downstream.=A0 Is there some RSVP
convention that distinguishes this?=A0 I think it is downstream but
don't know for sure.</x-tad-smaller></smaller></excerpt><excerpt>


</excerpt>

Downstream link traversed by the TE LSP indeed.


<excerpt><smaller><x-tad-smaller>3. Again in mid-point explict
notification mode it is not clear what is meant by "the TE database
must be updated".=A0 Does it mean that the link or node is removed from
the local TE database so that the first upstream node that expands the
ERO can compute around the link/node?=A0

</x-tad-smaller></smaller></excerpt>

No since no such reroute by intermediate node is proposed here as the
mechanism is entirely targeted for head-end reoptimization. The point
here is just for a node to update its TED so as to take into account
the notification of the link that will be removed for maintenance,
should further path computation be required. Note that such procedure
is usually followed by current implementations in other contexts.


<excerpt><smaller><x-tad-smaller> If so, then it is necessary to
indicate what the link and node are for the non-packet LSP case.=A0 That
is, I am assuming that the RSVP signaling process (control) is
separated from the bearer plane (e.g., a SONET cross connect).=A0 It is
the identity of the control "node" that is put into the PathErr
whereas the bearer "node" has a different =
identity.</x-tad-smaller></smaller></excerpt><excerpt>


<smaller><x-tad-smaller>To do this, I would suggest that the IF_ID
ERROR_SPEC object (from [RFC3473]) and all of the TLVs it may contain
including from draft-ietf-ccamp-crankback-03.txt be added to the
PathErr message when=A0 Error sub-codes 7&8 are used.=A0 This will =
enable
the actual link to be known.=A0 In the case of node, Type 8 (NODE_ID)
would identify the bearer =
node.</x-tad-smaller></smaller></excerpt><excerpt>


<smaller><x-tad-smaller>For security reasons, if the LSP spans
domains, the OSPF_AREA or AUTONOMOUS_SYSTEM TLVs could be used when
error subcode 8 is passed =
upstream.</x-tad-smaller></smaller></excerpt><excerpt>


<smaller><x-tad-smaller>4. In the same context as point 3, does the
head-end LSR do anything to its TE database based on the link or node
Error sub-codes?</x-tad-smaller></smaller></excerpt><excerpt>


</excerpt>

As in the previous case: note of course that the Head-end would not
update its TED in the context of inter-area/AS TE if the link/node to
be maintained does not reside in the head-end area.


Thanks for your comments.


JP.


<excerpt><smaller><x-tad-smaller>> -----Original
Message-----</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> From:
[e-mail]</x-tad-smaller></smaller></excerpt><excerpt>=20

 <smaller><x-tad-smaller>>
=
[</x-tad-smaller><color><param>0000,0000,EEEE</param><x-tad-smaller>mailto=
:[e-mail]</x-tad-smaller></color><x-tad-smaller>]
On Behalf Of Adrian
Farrel</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> Sent: Wednesday, January 05, 2005
13:41</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> To:
[e-mail]</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> Subject: Working Group Last Call
=
draft-ietf-ccamp-loose-path-reopt-</x-tad-smaller></smaller></excerpt><exc=
erpt>=20

<smaller><x-tad-smaller>> </x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>> </x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>> This email starts a two week last call on =
</x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>>
=
</x-tad-smaller><color><param>0000,0000,EEEE</param><x-tad-smaller>http://=
www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat</x-tad-smaller></c=
olor></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>>
h-reopt-00.txt</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> </x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>> Please send your comments to the list or to
the chairs by </x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>> noon GMT on 20th January
2005.</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> </x-tad-smaller></smaller></excerpt><excerpt>

<smaller><x-tad-smaller>>
Thanks,</x-tad-smaller></smaller></excerpt><excerpt>=20

<smaller><x-tad-smaller>> Adrian and
Kireeti</x-tad-smaller></smaller></excerpt><excerpt>=20

</excerpt>=

--Apple-Mail-144--597084343--



Envelope-to: [e-mail]
Delivery-date: Mon, 24 Jan 2005 09:24:22 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: quoted-printable
Cc: Adrian Farrel <[e-mail]>, [e-mail]
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:22:45 -0500
To: [e-mail], [e-mail]

Hi Dimitri,

Thanks for your comments - see in line, (removed comments are the ones =20=

that we agree on and which will be incorporated in the next revision).

On Jan 6, 2005, at 6:15 AM, dimitri papadimitriou wrote:

> 3. i do not see the relationship of including the following paragraph =20=

> (in the following paragraph " There is another scenario whereby =20
> notifying the head-end of the existence of a better path is desirable: =
=20
> if the current path is about the fail due to some (link or node) =20
> required maintenance (see also [GR-SHUT]).") within the context of =20
> this document as non-time sensitive mechanism is targeted here while =20=

> the referenced document targets time-sensititve mechanism (existing =20=

> LSPs are about to fail and not existing LSP can be re-optimized due to =
=20
> the existence of additional resource) however this point triggers to =20=

> me the following question in case of link/node down for maintenance =20=

> reasons what gives the guarantee that the head-end will respond on =20
> time before the maintenance operation is performed
>

the point here is simply that a better path is not restricted to the =20
situation where a lower cost path is found but also when the path is =20
about to be invalidated due to maintenance. No assumption is made on =20
action triggered on the Head-end LSR. (that said, reference has been =20
removed).
>
> 5. section 5.3.1 to which LSR (intermediate vs head-end) the first LSR =
=20
> mentioned refers to "At this point, the LSR MAY decide to clear the =20=

> =F4Path re-evaluation request=F6 bit of the SESSION-ATTRIBUTE object =
in =20
> subsequent RSVP Path messages sent downstream:" and what "subsequent" =20=

> refers to in the present context
>

"The LSR" refers to the LSR performing the path re-evaluation and =20
"subsequent" refers to the Path messages used to refresh the states =20
downstream for the TE LSP. Text added. =09

> 7. section 5.3.2. " In this case, the mid-point LSR where the
>    local maintenance must be performed is responsible for sending an
>    RSVP PathError message with Error code 25 and Error sub-code=3D7 or =
8
>    depending on the affected network element (link or node)." my =20
> reading of all previous content was that in such a case the mid-point =20=

> LSR is not the local maintenance point is realized - inline with what =20=

> follows down this paragraph -
>

You're right, the text was ambiguous ... and has been changed for =20
"There are other circumstances whereby any mid-point LSR MAY send an =20
RSVP PathError message with the objective for the TE LSP to be rerouted =20=

by its head-end LSR: when a link or a node will go down for local =20
maintenance reasons. In this case, the LSR where a local maintenance =20
must be performed is responsible for sending an RSVP PathError message =20=

with Error code 25 and Error sub-code=3D7 or 8 depending on the affected =
=20
network element (link or node). "

> some edits
>

Fixed.

Thanks for your comments.

JP.

> thanks,
> - dimitri
>
> Adrian Farrel wrote:
>
>> This email starts a two week last call on
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-=20
>> reopt-00.txt
>> Please send your comments to the list or to the chairs by noon GMT on =
=20
>> 20th
>> January 2005.
>> Thanks,
>> Adrian and Kireeti
>> .
>



Envelope-to: [e-mail]
Delivery-date: Sun, 23 Jan 2005 17:54:24 +0000
Message-ID: <008a01c50174$67e76820$d2cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Layer 2 Switching Caps LSPs
Date: Sun, 23 Jan 2005 11:46:16 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

There is a draft (draft-papadimitriou-ccamp-gmpls-l2sc-lsp-03.txt) that we
have discussed at several of the more recent CCAMP meetings, and have
decided that the subject is within scope for our charter.

The questions we have faced have been:
- is the problem well enough articulated?
- is this the solution that the WG wants to pursue?
- is there a high enough level of interest in this work?

If the answer to all three questions is "yes" then we can adopt the draft
as a WG document and move forwards.

Note: I think there are a large number of minor issues to clear up with
this draft, but hopefully this is orthogonal to whether we make this a WG
draft or not.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 21 Jan 2005 23:08:24 +0000
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: <[e-mail]>
From: JP Vasseur <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 21 Jan 2005 18:06:29 -0500
To: "Adrian Farrel" <[e-mail]>

Hi Adrian,

On Jan 21, 2005, at 6:37 AM, Adrian Farrel wrote:

> OK,
>
> This concludes the WG last call on this draft.
>
> Authors/editors: you got comments from four people, some of them fairly
> detailed. I think there is probably a fair bit of work to do.
>
> As guardians of this draft on behalf of the working group, I'd like to  
> ask
> that you track all of the comments and record either the agreed  
> discussion
> that means that no action is required, or the agreed resolution and  
> change
> to the draft.
>

Sure, will be done shortly.

Cheers

JP.

> Thanks,
> Adrian
> ----- Original Message -----
> From: "Adrian Farrel" <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, January 05, 2005 6:40 PM
> Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
>
>
>> This email starts a two week last call on
>>
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt 
> -00.txt
>>
>> Please send your comments to the list or to the chairs by noon GMT on
> 20th
>> January 2005.
>>
>> Thanks,
>> Adrian and Kireeti
>>
>>
>>
>>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 21 Jan 2005 12:25:39 +0000
Message-ID: <005c01c4ffb4$448e9e50$76cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>, "Brungard, Deborah A, ALABS" <[e-mail]>, "Dimitri Papadimitriou" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Draft ready for ADs : draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Fri, 21 Jan 2005 11:52:38 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Alex,

This draft has passed through WG last call and has been updated to my
satisfaction. (Note that I am a co-author.)

Please can you start the AD review process ready to take the draft to the
IESG.

Cheers,

Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 21 Jan 2005 12:25:34 +0000
Message-ID: <005901c4ffb4$3f664680$76cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 21 Jan 2005 11:37:43 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK,

This concludes the WG last call on this draft.

Authors/editors: you got comments from four people, some of them fairly
detailed. I think there is probably a fair bit of work to do.

As guardians of this draft on behalf of the working group, I'd like to ask
that you track all of the comments and record either the agreed discussion
that means that no action is required, or the agreed resolution and change
to the draft.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 05, 2005 6:40 PM
Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-


> This email starts a two week last call on
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt
>
> Please send your comments to the list or to the chairs by noon GMT on
20th
> January 2005.
>
> Thanks,
> Adrian and Kireeti
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 20 Jan 2005 19:53:51 +0000
Date: Thu, 20 Jan 2005 11:51:23 -0800 (PST)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Adrian, all,

Just a few comments on this draft.

Section 2 and elsewhere: there are repeated statements & notes as to "CSPF
or any other PCE-based path computation method"
--> I don't think it is relevant to this document whether the path
computation is local or remote or done by a PCE or not. IMO, it would be
enough to just say "path computation".

Paragraph 4 in Section 3, Section 4.2, and 2nd and 3rd paragraphs in 5.3.2
----> This draft not only refers to another draft (and it is *not* a
normative reference) draft-ali-ccamp-mpls-graceful-shutdown-00.txt, but
also seems to introduce error codes and subcodes (subcode 7 & 8) which are
actually relevant to GR-SHUTDOWN draft rather than this document. IMO, if
graceful-shutdown procedures need new error codes/subcodes, they must be
introduced in the graceful-shutdown draft and not in this re-optimization
draft. Otherwise, what is the point of having the other draft if the
codes are being standardized here ?

thanks,
-arthi

So the
> This email starts a two week last call on
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt
>
> Please send your comments to the list or to the chairs by noon GMT on 20th
> January 2005.
>
> Thanks,
> Adrian and Kireeti
>
>



Envelope-to: [e-mail]
Delivery-date: Mon, 17 Jan 2005 21:08:00 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g709-09.txt
Date: Mon, 17 Jan 2005 16:05:50 -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		: Generalized MPLS (GMPLS) Signaling Extensions for 
			  G.709 Optical Transport Networks Control
	Author(s)	: D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-g709-09.txt
	Pages		: 22
	Date		: 2005-1-17
	
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN
developments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-gmpls-g709-09.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-09.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-g709-09.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Mon, 17 Jan 2005 03:34:50 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Bill Fenner <[e-mail]>, Scott Bradner <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Response to Liaison Concerning the Comparison of LMP and ASON Discovery
Date: Sun, 16 Jan 2005 22:33:21 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Dear Adrian and Kireeti,
 
Thank you for the Response to the Q14/15 Liaison Concerning the Comparison of LMP and ASON Discovery. Q14/15 will address the LS in its upcoming meeting on January 24-28, 2005.
 
Regards,
Kam Lam, Q14/15 Rapporteur

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Sunday, January 16, 2005 12:52 PM
> To: Lam, Hing-Kam (Kam)
> Cc: 'Kireeti Kompella'; [e-mail]; Bill Fenner; Scott Bradner;
> [e-mail]; [e-mail]
> Subject: Response to Liaison Concerning the Comparison of LMP and ASON
> Discovery
> 
> 
> To: Mr. Kam Lam, Rapporteur Q14/15
> From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
> Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
>     Scott Bradner, IETF liaison to ITU-T
> For: Information
> Subject: Response to Liaison Concerning the Comparison of LMP and ASON
> Discovery
> 
> Dear Kam,
> 
> The IETF CCAMP Working Group thanks ITU-T Q14/15 for their feedback on
> draft-ietf-ccamp-transport-lmp-00.txt. It is always useful to 
> have extra
> review of our drafts, and since this draft attempts to explain ITU-T
> concepts to the IETF audience, it is particularly helpful to 
> your input.
> 
> >Q14/15 thanks the IETF CCAMP WG for providing us the draft document
> ><draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was 
> discussed at the
> >meeting and several of the comments are provided below. Based upon
> >this discussion we believe it would be highly beneficial to have some
> >joint discussions on terminology to ensure an aligned view to
> >facilitate our future work efforts.
> 
> Events have overtaken this liaison response and a meeting has 
> been set up.
> See the end of this liaison response for more comments.
> 
> Please see the reply to your specific issues in the following text.
> 
> >We have several questions of clarification, e.g., in section 3.1
> >(paragraph 2) of the I-D, "The separation between the two 
> processes and
> >corresponding two name spaces has the advantage that the discovery of
> >the transport plane can be performed independent from that of the
> >control plane (and vice-versa), and independent of the method used in
> >each name space. This allows assigning link connections in 
> the control
> >plane without the link connection being physically connected."
> >
> >What is the intention of the term independent, for example, 
> could it be
> >indicating at a different time or different approaches? In the last
> >sentence, is "assign" used in the context of the management plane,
> >meaning management plane provisioning? Is it assumed that the
> >transport plane resources supporting the link connection endpoints
> >exist or do not exist? In section 4.2 (paragraph 2) of the 
> I-D, "G.8080
> >refers to a component link as a variable adaptation function i.e. a
> >single server layer trail dynamically supporting different 
> multiplexing
> >structures." This could be interpreted as indicating G.8080
> >defines the term "component link". G.8080 does not use this
> >term. Some clarification would be beneficial.
> 
> As this section of the draft indicates, it is summarizing 
> G.8080 Discovery
> (not LMP). The description is directly based on G.8080's text,
> i.e.:
> 
> " This separation allows control plane names to be completely
>   separate from transport plane names, and completely independent
>   of the method used to populate the DAs with those transport names."
> 
> " In order to assign an SNP-SNP link connection to an SNPP link, it
>   is only necessary for the transport name for the link connection to
>   exist. Thus, it is possible to assign link connections to 
> the control
>   plane without the link connection being physically connected."
> 
> The authors will clarify for these paragraphs that we are quoting from
> G.8080 (not describing LMP). In particular:
> 
> "G.8080 refers to a component link as a variable adaptation 
> function" was
> worded to present an interpretation of G.8080 from an IETF terminology
> perspective; i.e. the LMP component link is referred to by G.8080 as a
> variable adaptation function. The authors will clarify the text to say
> "G.8080's variable adaptation function is broadly equivalent to LMP's
> component link."
> 
> >Initial reviews of the draft document have raised concerns about the
> >possible misinterpretation in the usage of the term 'TE link'. As the
> >draft notes, the definition of a TE link is concise. Some 
> more clarity
> >would be appreciated. Our current understanding of this term includes
> >the following: A TE link may be composed of resource from multiple
> >(G.805) layers in parallel. If so, this is an important 
> distinction as
> >an SNPP link is in a single layer only. An SNPP link may contain SNP
> >link connections from various links (e.g., different STS-1s from
> >a set of parallel OC-48 trails). It is not clear if this is
> >also true for TE links. We think it may, but it is not stated.
> >SNPPs exist at different routing levels (not layers) and thus an
> >SNPP link at a higher level can encompass SNPPs at a lower level
> >(see Section 6.2.2 of G.8080 Amendment 2, which is attached for
> >your convenience). We think TE links may do this with bundles
> >and FAs, but the definition is not clear to us.
> >
> >Please advise if this is a correct understanding or not. 
> This may have
> >an impact on the terminology mapping in the draft. We think it would
> >be beneficial to have a TE link definition that enables these
> >distinctions to be understood.
> 
> It is not the intention of this draft to define a TE link. 
> The TE link is
> defined in the LMP draft (draft-ietf-ccamp-lmp-10.txt) through a
> restatement of the definition in the GMPLS Routing draft
> (draft-ietf-ccamp-gmpls-routing-09.txt).
> 
> At the request of several individuals we tried to bring 
> clarity to the TE
> link concept by additional explanation within this draft. The IETF
> definition of the TE link describes the way that resources 
> are grouped and
> mapped for the purpose of path computation. Constraints on 
> the physical
> resources define what is possible rather than defining any elaborate
> structures within the TE link.
> 
> Therefore an SNPP link could easily be mapped to a TE link.
> 
> There is a separation between the constraints of the physical 
> resources
> and the information aggregation of TE link. Bundling is a mechanism to
> efficiently aggregate TE resources within the constraints of 
> the physical
> technology.
> 
> An LSP created across an LSP region (see
> draft-ietf-mpls-lsp-hierarchy-08.txt) in the network may be 
> assigned as a
> TE link by an upper region and so appear as TE resources 
> within the upper
> region (just as any other TE link). Such a TE link is referred to as a
> Forwarding Adjacency.
> 
> A TE link may contain STS-1s from parallel OC-48 trails.
> 
> The authors will add text to clarify.
> 
> >In the table in section 4.2 "CP" is mapped to "Interface". A
> >Connection Point is more closely related to a timeslot, wavelength,
> >etc. rather than to an entire interface. Similarly "CP Name" 
> is mapped
> >to "Interface ID" while it might more closely relate to a "Label".
> 
> LMP distinguishes data links depending on the multiplexing 
> capability of
> the endpoint on that link: "ports" are not multiplexing capable,
> "component links" are multiplexing capable. Following this 
> reasoning, the
> data link for SDH/SONET networks is not the "timeslot" (this 
> is the label)
> but the SDH/SONET section on which the timeslot (i.e. label) gets
> allocated. This is clearly described in draft-ietf-ccamp-lmp-10.txt.
> 
> A Connection Point (CP) most closely maps to an interface in 
> terms of the
> IETF definitions.
> 
> >Joint discussion of the terminology mapping may be beneficial in
> >reaching alignment on the most accurate mapping. As noted 
> above, these
> >represent several of the comments discussed. In order to progress our
> >mutual understanding, we would like to invite IETF participants to
> >attend the January 24-28, 2005 Q14/15 interim meeting, in New Jersey,
> >USA, where we could devote a session to terminology alignment. We
> >believe this effort will greatly benefit our future collaboration on
> >control plane standards development.  We welcome IETF experts'
> >participation in other sessions of the interim meeting as well.
> >Details of the meeting agenda will be provided prior to the meeting.
> >For those interested in further information and/or attending the
> >interim meeting should contact the Rapporteur for Q.14/15 
> (H. Kam Lam,
> >[e-mail]) by 10th January 2005.
> 
> We welcome the efforts by Q14/15 to improve mutual understanding of
> terminology.
> 
> This meeting and the clarification of general GMPLS/ASON 
> terminology is
> distinct from the review of draft-ietf-ccamp-transport-lmp. 
> This draft has
> fairly limited scope and does not need to be dependent on a full and
> mutual exchange of terminology.
> 
> Various members of the CCAMP working group including some of 
> the authors
> of this draft plan to attend your meeting on January 25th and 26th.
> 
> 
> Thank you once again for your feedback on this draft.
> If you have further comments, we would certainly like to hear 
> them. The
> easiest way for individuals to contribute to the discussion 
> of this topic
> is by sending mail to the CCAMP mailing list. Details of how 
> to subscribe
> to this list can be found at
> http://www.ietf.org/html.charters/ccamp-charter.html
> 
> Yours sincerely,
> Adrian Farrel and Kireeti Kompella
> 



Envelope-to: [e-mail]
Delivery-date: Sun, 16 Jan 2005 17:55:03 +0000
Message-ID: <00a301c4fbf4$2e5b64b0$e7cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Response to Liaison Concerning the Comparison of LMP and ASON Discovery
Date: Sun, 16 Jan 2005 17:52:28 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
    Scott Bradner, IETF liaison to ITU-T
For: Information
Subject: Response to Liaison Concerning the Comparison of LMP and ASON
Discovery

Dear Kam,

The IETF CCAMP Working Group thanks ITU-T Q14/15 for their feedback on
draft-ietf-ccamp-transport-lmp-00.txt. It is always useful to have extra
review of our drafts, and since this draft attempts to explain ITU-T
concepts to the IETF audience, it is particularly helpful to your input.

>Q14/15 thanks the IETF CCAMP WG for providing us the draft document
><draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the
>meeting and several of the comments are provided below. Based upon
>this discussion we believe it would be highly beneficial to have some
>joint discussions on terminology to ensure an aligned view to
>facilitate our future work efforts.

Events have overtaken this liaison response and a meeting has been set up.
See the end of this liaison response for more comments.

Please see the reply to your specific issues in the following text.

>We have several questions of clarification, e.g., in section 3.1
>(paragraph 2) of the I-D, "The separation between the two processes and
>corresponding two name spaces has the advantage that the discovery of
>the transport plane can be performed independent from that of the
>control plane (and vice-versa), and independent of the method used in
>each name space. This allows assigning link connections in the control
>plane without the link connection being physically connected."
>
>What is the intention of the term independent, for example, could it be
>indicating at a different time or different approaches? In the last
>sentence, is "assign" used in the context of the management plane,
>meaning management plane provisioning? Is it assumed that the
>transport plane resources supporting the link connection endpoints
>exist or do not exist? In section 4.2 (paragraph 2) of the I-D, "G.8080
>refers to a component link as a variable adaptation function i.e. a
>single server layer trail dynamically supporting different multiplexing
>structures." This could be interpreted as indicating G.8080
>defines the term "component link". G.8080 does not use this
>term. Some clarification would be beneficial.

As this section of the draft indicates, it is summarizing G.8080 Discovery
(not LMP). The description is directly based on G.8080's text,
i.e.:

" This separation allows control plane names to be completely
  separate from transport plane names, and completely independent
  of the method used to populate the DAs with those transport names."

" In order to assign an SNP-SNP link connection to an SNPP link, it
  is only necessary for the transport name for the link connection to
  exist. Thus, it is possible to assign link connections to the control
  plane without the link connection being physically connected."

The authors will clarify for these paragraphs that we are quoting from
G.8080 (not describing LMP). In particular:

"G.8080 refers to a component link as a variable adaptation function" was
worded to present an interpretation of G.8080 from an IETF terminology
perspective; i.e. the LMP component link is referred to by G.8080 as a
variable adaptation function. The authors will clarify the text to say
"G.8080's variable adaptation function is broadly equivalent to LMP's
component link."

>Initial reviews of the draft document have raised concerns about the
>possible misinterpretation in the usage of the term 'TE link'. As the
>draft notes, the definition of a TE link is concise. Some more clarity
>would be appreciated. Our current understanding of this term includes
>the following: A TE link may be composed of resource from multiple
>(G.805) layers in parallel. If so, this is an important distinction as
>an SNPP link is in a single layer only. An SNPP link may contain SNP
>link connections from various links (e.g., different STS-1s from
>a set of parallel OC-48 trails). It is not clear if this is
>also true for TE links. We think it may, but it is not stated.
>SNPPs exist at different routing levels (not layers) and thus an
>SNPP link at a higher level can encompass SNPPs at a lower level
>(see Section 6.2.2 of G.8080 Amendment 2, which is attached for
>your convenience). We think TE links may do this with bundles
>and FAs, but the definition is not clear to us.
>
>Please advise if this is a correct understanding or not. This may have
>an impact on the terminology mapping in the draft. We think it would
>be beneficial to have a TE link definition that enables these
>distinctions to be understood.

It is not the intention of this draft to define a TE link. The TE link is
defined in the LMP draft (draft-ietf-ccamp-lmp-10.txt) through a
restatement of the definition in the GMPLS Routing draft
(draft-ietf-ccamp-gmpls-routing-09.txt).

At the request of several individuals we tried to bring clarity to the TE
link concept by additional explanation within this draft. The IETF
definition of the TE link describes the way that resources are grouped and
mapped for the purpose of path computation. Constraints on the physical
resources define what is possible rather than defining any elaborate
structures within the TE link.

Therefore an SNPP link could easily be mapped to a TE link.

There is a separation between the constraints of the physical resources
and the information aggregation of TE link. Bundling is a mechanism to
efficiently aggregate TE resources within the constraints of the physical
technology.

An LSP created across an LSP region (see
draft-ietf-mpls-lsp-hierarchy-08.txt) in the network may be assigned as a
TE link by an upper region and so appear as TE resources within the upper
region (just as any other TE link). Such a TE link is referred to as a
Forwarding Adjacency.

A TE link may contain STS-1s from parallel OC-48 trails.

The authors will add text to clarify.

>In the table in section 4.2 "CP" is mapped to "Interface". A
>Connection Point is more closely related to a timeslot, wavelength,
>etc. rather than to an entire interface. Similarly "CP Name" is mapped
>to "Interface ID" while it might more closely relate to a "Label".

LMP distinguishes data links depending on the multiplexing capability of
the endpoint on that link: "ports" are not multiplexing capable,
"component links" are multiplexing capable. Following this reasoning, the
data link for SDH/SONET networks is not the "timeslot" (this is the label)
but the SDH/SONET section on which the timeslot (i.e. label) gets
allocated. This is clearly described in draft-ietf-ccamp-lmp-10.txt.

A Connection Point (CP) most closely maps to an interface in terms of the
IETF definitions.

>Joint discussion of the terminology mapping may be beneficial in
>reaching alignment on the most accurate mapping. As noted above, these
>represent several of the comments discussed. In order to progress our
>mutual understanding, we would like to invite IETF participants to
>attend the January 24-28, 2005 Q14/15 interim meeting, in New Jersey,
>USA, where we could devote a session to terminology alignment. We
>believe this effort will greatly benefit our future collaboration on
>control plane standards development.  We welcome IETF experts'
>participation in other sessions of the interim meeting as well.
>Details of the meeting agenda will be provided prior to the meeting.
>For those interested in further information and/or attending the
>interim meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
>[e-mail]) by 10th January 2005.

We welcome the efforts by Q14/15 to improve mutual understanding of
terminology.

This meeting and the clarification of general GMPLS/ASON terminology is
distinct from the review of draft-ietf-ccamp-transport-lmp. This draft has
fairly limited scope and does not need to be dependent on a full and
mutual exchange of terminology.

Various members of the CCAMP working group including some of the authors
of this draft plan to attend your meeting on January 25th and 26th.


Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this topic
is by sending mail to the CCAMP mailing list. Details of how to subscribe
to this list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Sun, 16 Jan 2005 04:06:07 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: [e-mail], Scott Bradner <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, [e-mail], [e-mail], Bill Fenner <[e-mail]>
Subject: RE: Response to ITU-T Q14/15 Liaison about CCAMP Crankback Draft
Date: Sat, 15 Jan 2005 23:02:31 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FB7F.BDFE2C8A"

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

------_=_NextPart_001_01C4FB7F.BDFE2C8A
Content-Type: text/plain;
	charset="iso-8859-1"

Dear Mr. Farrel,
 
Thank you for the Response to the Q14/15 Liaison about the CCAMP Crankback Draft. We appreciate the opportunity to provide further input to the work. Q14/15 will address the LS in its upcoming meeting.
 
Regards,
Kam Lam, Q14/15 Rapporteur

-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]]
Sent: Saturday, January 15, 2005 6:55 AM
To: Lam, Hing-Kam (Kam)
Cc: [e-mail]; Scott Bradner; 'Kireeti Kompella'; [e-mail]; [e-mail]; Bill Fenner
Subject: Response to ITU-T Q14/15 Liaison about CCAMP Crankback Draft


To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
    Scott Bradner, IETF liaison to ITU-T
Subject: Crankback in GMPLS Systems
For: Information
 
Dear Kam,

Thank you for your liaison concerning draft-ietf-ccamp-crankback-03. It is
useful to have additional review input from a wide audience. Please convey
our special thanks to Stephen Shew and Marco Carugi for their detailed
review of the draft in Geneva.

We would like to urge Q14/15 to continue to consider this draft as further
work is carried out on crankback within the context of G.7713.

In response to the specific points that were raised in the liaison...

> 1.       Semantics of the term "node".  Due to the GMPLS principle of
> maintaining separation of control and transport (data/bearer) planes,
> there are two meanings for the term "node".  First, an instance of a
> signalling protocol (and/or routing protocol) that has some transport
> resources in its scope.  Second, a transport plane resource such as a
> cross connect.  Using the first meaning, a node is not the context for
> the interface identifiers that are passed in crankback TLVs.
> Throughout the document the particular meaning can be determined
> by the context of the term.  Examples are:
>
> - Section 5.2, the sentence "Otherwise, multiple nodes might attempt to
> repair the LSP." means the control functions of signalling and routing.
>
> - Section 7.1 "As described above, full crankback information SHOULD
> indicate the node, link and other resources, which have been attempted."
> refers to the transport resource.

It is correct to observe that historically there has been poor separation
of controllers and transport devices within GMPLS, with much of this issue
arising from the historic collocation of controllers and data switches in
MPLS networks. This persists because of the (eminently sensible) tendency
to optimize for the majority case.

However, in the case of crankback, and specifically in the case of this
draft, the emphasis in providing 'full crankback information' is on the
addresses of transport links and nodes and not controllers. We will
revisit the draft to ensure that where control plane function is implied,
the "node" that takes action is clearly identified as the control plane
node.

> There are some occasions where the use of the term appear to be
> ambiguous and clarity would be appreciated.  In particular TLV
> types 10 and 32. If  type 10 represents a routing and signalling
> function, then what TLV describes the "transport plane node"
> (e.g., cross connect or Network Element)?  If type 32 means
> "transport plane nodes", then a different TLV may be needed
> to identify the "routing/signalling nodes" that have already
> participated in crankback attempts.
> Having a clearer distinction between control plane functions
> and transport plane resources would be helpful.

As indicated above, the intention of crankback is to apply a process to
the path determination for an LSP. The path is determined using transport
plane links and nodes, and although there may be some interesting
aggregation available by converting this information to control plane
nodes, the conversion is not necessarily simple. Thus, these TLVs all
refer to transport plane quantities, and we will make this clearer in the
draft.

Again, of course, in the majority case we can make considerable
optimizations by knowing that control plane and transport plane "nodes"
are related in a 1:1 ratio and are usually collocated.

> 2.       When crankback information is received at a "routing/signalling
> node", can it be used by the routing path computation function for other
> LSP requests than the LSP whose signalling caused the crankback action?

It is generally out-of-scope for the IETF to dictate how individual
implementations operate. It is quite conceivable that such an action would
be taken, but it is also clear that there is a potentially dangerous
interaction with the TE flooding process (i.e. the IGP). Thus we would say
that the crankback information MAY be used to inform other path
computations.

We would want to be very cautious that crankback is not intended to
supplement or replace the normal operation of the TE flooding mechanism
provided by the TE extensions to the IGP except for the establishment of a
single LSP. If the IGP is found to be deficient as a flooding mechanism we
would expect to look first at ways to address the problems through IGP
extensions before utilizing a signaling mechanism.

We will look at how to add some of this information to the draft.

> 3.       Section 6.1 "Segment-based Re-routing" option.  It is not clear
> what this means.  Can multiple "routing/signalling nodes" perform
> crankback on the same LSP at the same time if this flag is set?

Since the intention is to establish only one LSP, there must be only one
active sequence of LSP setup messages (RSVP-TE Path messages) at any time.
Thus only one LSR may attempt re-routing at any one time.

If you consider the processes by which Path messages are attempted and
crankback information is returned on PathErr messages, this will be clear.
That is, when an PSR receives a crankback PathErr, it may attempt to
re-route or it may forward the PathErr back upstream.

It might help if we reworded the draft to say "Any node may attempt
rerouting after it receives an error report and before it passes the error
report further upstream."

> 4.       Section 4.3 History persistence.  If a repair point (a
> "routing/signalling node") is unsuccessful in a crankback attempt, is it
> possible for it to be not involved when another repair point (e.g.,
> closer to the source) succeeds in a crankback attempt.  If so, how
> does the first repair point know to clear its history?

Note that the purpose of the history table as described in section 4.3 is
to correlate information when repeated retry attempts are made by the same
LSR. Suppose an attempt is made to route from A through B, and the
signalling controller for B returns a failure with crankback information.
An attempt may be made to route from A through C, and this may also fail
with the return of crankback information. The next attempt SHOULD NOT be
to route from A through B, and this is achieved by use of the history
table.

The history table can be discarded by the signaling controller for A if
the LSP is successfully established through A. The history table MAY be
retained after the signaling controller for A sends an error upstream,
however it is questionable what value this provides since a future retry
as a result of crankback rerouting should not attempt to route through A
(such is the nature of crankback). If the history information is retained
for a longer period it SHOULD be discarded after a local timeout has
expired, and that timer MUST be shorter than the timer used by the ingress
to re-attempt a failed service (note that re-attempting a failed service
is not the same as making a re-route attempt after failure).

As mentioned for point 2, the crankback information MAY be used to enhance
future routing attempts for any LSP, but this is not what section 4.3 is
describing.

We will try to clarify this in the draft.

> 5.       Section 4.5 Retries.  Some guidance on setting the number of
> retries may be helpful as this is a distributed parameter.  Is it set to
> be the same value at all points that can perform crankback within one
> network?

The view of CCAMP at the moment is that although it is technically
possible to allow the number of retries to be set for each LSP, this
probably represents too much configuration and too fine a level of
control. It seems likely that initial deployments will wish to set the
number of retries per node through a network-wide configuration constant
(that is, all LSRs capable of retrying will apply the same count) with the
possibility of configuring specific LSRs to have greater or lower counts.
Note that configuring an LSR not to be able to perform retries is
equivalent to configuring the retry count to be zero for that LSR.

It is also probable that initial deployments will significantly restrict
the number of LSRs within the network that can perform crankback
rerouting. This would probably be limited to "boundary" nodes.

In the event that implementations and deployments wish to control the
number of retries on a per LSP basis, we would revisit the signaling
specification and add the relevant information to the Path and PathErr
messages.

The actual value to set for a retry threshold is entirely a deployment
issue. It will be constrained by the topology and nature of the network.
It would be inappropriate to suggest a figure in this draft since there
are no hard and fast rules.

In review of section 4.5 of the draft, we see that there is some old text
describing more flexibility in the control of retries than we intend to
provide. Thank you for drawing our attention to this; we will clean it up.


Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this topic
is by sending mail to the CCAMP mailing list. Details of how to subscribe
to this list can be found at
 <http://www.ietf.org/html.charters/ccamp-charter.html> http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella



------_=_NextPart_001_01C4FB7F.BDFE2C8A
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 6.00.2800.1480" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Courier New" size=2>Dear Mr. Farrel,</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>Thank you for the&nbsp;<SPAN 
class=035145903-16012005>Response to the Q14/15 Liaison about the CCAMP 
Crankback Draft</SPAN>. We appreciate the opportunity to provide&nbsp;<SPAN 
class=035145903-16012005>further </SPAN>input to the work. Q14/15 will address 
the LS in its upcoming meeting.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>Regards,<BR>Kam Lam, Q14/15 
Rapporteur</FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Adrian Farrel 
  [mailto:[e-mail]]<BR><B>Sent:</B> Saturday, January 15, 2005 6:55 
  AM<BR><B>To:</B> Lam, Hing-Kam (Kam)<BR><B>Cc:</B> [e-mail]; Scott 
  Bradner; 'Kireeti Kompella'; [e-mail]; [e-mail]; Bill 
  Fenner<BR><B>Subject:</B> Response to ITU-T Q14/15 Liaison about CCAMP 
  Crankback Draft<BR><BR></FONT></DIV>
  <DIV><FONT face=Courier size=2>To: Mr. Kam Lam, Rapporteur Q14/15<BR>From: 
  Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs</FONT></DIV>
  <DIV><FONT face=Courier size=2>Cc: Alex Zinin and Bill Fenner, IETF Routing 
  Area Directors</FONT></DIV>
  <DIV><FONT face=Courier size=2>&nbsp;&nbsp;&nbsp; Scott Bradner, IETF liaison 
  to ITU-T<BR>Subject: Crankback in GMPLS Systems<BR>For: 
  Information</FONT></DIV>
  <DIV><FONT face=Courier size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Courier size=2>Dear Kam,<BR><BR>Thank you for your liaison 
  concerning draft-ietf-ccamp-crankback-03. It is<BR>useful to have additional 
  review input from a wide audience. Please convey<BR>our special thanks to 
  Stephen Shew and Marco Carugi for their detailed<BR>review of the draft in 
  Geneva.<BR><BR>We would like to urge Q14/15 to continue to consider this draft 
  as further<BR>work is carried out on crankback within the context of 
  G.7713.<BR><BR>In response to the specific points that were raised in the 
  liaison...<BR><BR>&gt; 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Semantics of the 
  term "node".&nbsp; Due to the GMPLS principle of<BR>&gt; maintaining 
  separation of control and transport (data/bearer) planes,<BR>&gt; there are 
  two meanings for the term "node".&nbsp; First, an instance of a<BR>&gt; 
  signalling protocol (and/or routing protocol) that has some transport<BR>&gt; 
  resources in its scope.&nbsp; Second, a transport plane resource such as 
  a<BR>&gt; cross connect.&nbsp; Using the first meaning, a node is not the 
  context for<BR>&gt; the interface identifiers that are passed in crankback 
  TLVs.<BR>&gt; Throughout the document the particular meaning can be 
  determined<BR>&gt; by the context of the term.&nbsp; Examples 
  are:<BR>&gt;<BR>&gt; - Section 5.2, the sentence "Otherwise, multiple nodes 
  might attempt to<BR>&gt; repair the LSP." means the control functions of 
  signalling and routing.<BR>&gt;<BR>&gt; - Section 7.1 "As described above, 
  full crankback information SHOULD<BR>&gt; indicate the node, link and other 
  resources, which have been attempted."<BR>&gt; refers to the transport 
  resource.<BR><BR>It is correct to observe that historically there has been 
  poor separation<BR>of controllers and transport devices within GMPLS, with 
  much of this issue<BR>arising from the historic collocation of controllers and 
  data switches in<BR>MPLS networks. This persists because of the (eminently 
  sensible) tendency<BR>to optimize for the majority case.<BR><BR>However, in 
  the case of crankback, and specifically in the case of this<BR>draft, the 
  emphasis in providing 'full crankback information' is on the<BR>addresses of 
  transport links and nodes and not controllers. We will<BR>revisit the draft to 
  ensure that where control plane function is implied,<BR>the "node" that takes 
  action is clearly identified as the control plane<BR>node.<BR><BR>&gt; There 
  are some occasions where the use of the term appear to be<BR>&gt; ambiguous 
  and clarity would be appreciated.&nbsp; In particular TLV<BR>&gt; types 10 and 
  32. If&nbsp; type 10 represents a routing and signalling<BR>&gt; function, 
  then what TLV describes the "transport plane node"<BR>&gt; (e.g., cross 
  connect or Network Element)?&nbsp; If type 32 means<BR>&gt; "transport plane 
  nodes", then a different TLV may be needed<BR>&gt; to identify the 
  "routing/signalling nodes" that have already<BR>&gt; participated in crankback 
  attempts.<BR>&gt; Having a clearer distinction between control plane 
  functions<BR>&gt; and transport plane resources would be helpful.<BR><BR>As 
  indicated above, the intention of crankback is to apply a process to<BR>the 
  path determination for an LSP. The path is determined using transport<BR>plane 
  links and nodes, and although there may be some interesting<BR>aggregation 
  available by converting this information to control plane<BR>nodes, the 
  conversion is not necessarily simple. Thus, these TLVs all<BR>refer to 
  transport plane quantities, and we will make this clearer in 
  the<BR>draft.<BR><BR>Again, of course, in the majority case we can make 
  considerable<BR>optimizations by knowing that control plane and transport 
  plane "nodes"<BR>are related in a 1:1 ratio and are usually 
  collocated.<BR><BR>&gt; 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When crankback 
  information is received at a "routing/signalling<BR>&gt; node", can it be used 
  by the routing path computation function for other<BR>&gt; LSP requests than 
  the LSP whose signalling caused the crankback action?<BR><BR>It is generally 
  out-of-scope for the IETF to dictate how individual<BR>implementations 
  operate. It is quite conceivable that such an action would<BR>be taken, but it 
  is also clear that there is a potentially dangerous<BR>interaction with the TE 
  flooding process (i.e. the IGP). Thus we would say<BR>that the crankback 
  information MAY be used to inform other path<BR>computations.<BR><BR>We would 
  want to be very cautious that crankback is not intended to<BR>supplement or 
  replace the normal operation of the TE flooding mechanism<BR>provided by the 
  TE extensions to the IGP except for the establishment of a<BR>single LSP. If 
  the IGP is found to be deficient as a flooding mechanism we<BR>would expect to 
  look first at ways to address the problems through IGP<BR>extensions before 
  utilizing a signaling mechanism.<BR><BR>We will look at how to add some of 
  this information to the draft.<BR><BR>&gt; 
  3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6.1 "Segment-based Re-routing" 
  option.&nbsp; It is not clear<BR>&gt; what this means.&nbsp; Can multiple 
  "routing/signalling nodes" perform<BR>&gt; crankback on the same LSP at the 
  same time if this flag is set?<BR><BR>Since the intention is to establish only 
  one LSP, there must be only one<BR>active sequence of LSP setup messages 
  (RSVP-TE Path messages) at any time.<BR>Thus only one LSR may attempt 
  re-routing at any one time.<BR><BR>If you consider the processes by which Path 
  messages are attempted and<BR>crankback information is returned on PathErr 
  messages, this will be clear.<BR>That is, when an PSR receives a crankback 
  PathErr, it may attempt to<BR>re-route or it may forward the PathErr back 
  upstream.<BR><BR>It might help if we reworded the draft to say "Any node may 
  attempt<BR>rerouting after it receives an error report and before it passes 
  the error<BR>report further upstream."<BR><BR>&gt; 
  4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 4.3 History persistence.&nbsp; 
  If a repair point (a<BR>&gt; "routing/signalling node") is unsuccessful in a 
  crankback attempt, is it<BR>&gt; possible for it to be not involved when 
  another repair point (e.g.,<BR>&gt; closer to the source) succeeds in a 
  crankback attempt.&nbsp; If so, how<BR>&gt; does the first repair point know 
  to clear its history?<BR><BR>Note that the purpose of the history table as 
  described in section 4.3 is<BR>to correlate information when repeated retry 
  attempts are made by the same<BR>LSR. Suppose an attempt is made to route from 
  A through B, and the<BR>signalling controller for B returns a failure with 
  crankback information.<BR>An attempt may be made to route from A through C, 
  and this may also fail<BR>with the return of crankback information. The next 
  attempt SHOULD NOT be<BR>to route from A through B, and this is achieved by 
  use of the history<BR>table.<BR><BR>The history table can be discarded by the 
  signaling controller for A if<BR>the LSP is successfully established through 
  A. The history table MAY be<BR>retained after the signaling controller for A 
  sends an error upstream,<BR>however it is questionable what value this 
  provides since a future retry<BR>as a result of crankback rerouting should not 
  attempt to route through A<BR>(such is the nature of crankback). If the 
  history information is retained<BR>for a longer period it SHOULD be discarded 
  after a local timeout has<BR>expired, and that timer MUST be shorter than the 
  timer used by the ingress<BR>to re-attempt a failed service (note that 
  re-attempting a failed service<BR>is not the same as making a re-route attempt 
  after failure).<BR><BR>As mentioned for point 2, the crankback information MAY 
  be used to enhance<BR>future routing attempts for any LSP, but this is not 
  what section 4.3 is<BR>describing.<BR><BR>We will try to clarify this in the 
  draft.<BR><BR>&gt; 5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 4.5 
  Retries.&nbsp; Some guidance on setting the number of<BR>&gt; retries may be 
  helpful as this is a distributed parameter.&nbsp; Is it set to<BR>&gt; be the 
  same value at all points that can perform crankback within one<BR>&gt; 
  network?<BR><BR>The view of CCAMP at the moment is that although it is 
  technically<BR>possible to allow the number of retries to be set for each LSP, 
  this<BR>probably represents too much configuration and too fine a level 
  of<BR>control. It seems likely that initial deployments will wish to set 
  the<BR>number of retries per node through a network-wide configuration 
  constant<BR>(that is, all LSRs capable of retrying will apply the same count) 
  with the<BR>possibility of configuring specific LSRs to have greater or lower 
  counts.<BR>Note that configuring an LSR not to be able to perform retries 
  is<BR>equivalent to configuring the retry count to be zero for that 
  LSR.<BR><BR>It is also probable that initial deployments will significantly 
  restrict<BR>the number of LSRs within the network that can perform 
  crankback<BR>rerouting. This would probably be limited to "boundary" 
  nodes.<BR><BR>In the event that implementations and deployments wish to 
  control the<BR>number of retries on a per LSP basis, we would revisit the 
  signaling<BR>specification and add the relevant information to the Path and 
  PathErr<BR>messages.<BR><BR>The actual value to set for a retry threshold is 
  entirely a deployment<BR>issue. It will be constrained by the topology and 
  nature of the network.<BR>It would be inappropriate to suggest a figure in 
  this draft since there<BR>are no hard and fast rules.<BR><BR>In review of 
  section 4.5 of the draft, we see that there is some old text<BR>describing 
  more flexibility in the control of retries than we intend to<BR>provide. Thank 
  you for drawing our attention to this; we will clean it up.<BR><BR><BR>Thank 
  you once again for your feedback on this draft.<BR>If you have further 
  comments, we would certainly like to hear them. The<BR>easiest way for 
  individuals to contribute to the discussion of this topic<BR>is by sending 
  mail to the CCAMP mailing list. Details of how to subscribe<BR>to this list 
  can be found at<BR></FONT><A 
  href="http://www.ietf.org/html.charters/ccamp-charter.html"><FONT face=Courier 
  size=2>http://www.ietf.org/html.charters/ccamp-charter.html</FONT></A><BR><BR><FONT 
  face=Courier size=2>Yours sincerely,<BR>Adrian Farrel and Kireeti 
  Kompella<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4FB7F.BDFE2C8A--



Envelope-to: [e-mail]
Delivery-date: Sat, 15 Jan 2005 12:25:59 +0000
Message-ID: <008c01c4fafd$21b868e0$16cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: <[e-mail]>, "Scott Bradner" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Response to ITU-T Q14/15 Liaison about CCAMP Crankback Draft
Date: Sat, 15 Jan 2005 11:54:42 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C4FAF8.FFC72090"

This is a multi-part message in MIME format.

------=_NextPart_000_0060_01C4FAF8.FFC72090
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
    Scott Bradner, IETF liaison to ITU-T
Subject: Crankback in GMPLS Systems
For: Information

Dear Kam,

Thank you for your liaison concerning draft-ietf-ccamp-crankback-03. It =
is
useful to have additional review input from a wide audience. Please =
convey
our special thanks to Stephen Shew and Marco Carugi for their detailed
review of the draft in Geneva.

We would like to urge Q14/15 to continue to consider this draft as =
further
work is carried out on crankback within the context of G.7713.

In response to the specific points that were raised in the liaison...

> 1.       Semantics of the term "node".  Due to the GMPLS principle of
> maintaining separation of control and transport (data/bearer) planes,
> there are two meanings for the term "node".  First, an instance of a
> signalling protocol (and/or routing protocol) that has some transport
> resources in its scope.  Second, a transport plane resource such as a
> cross connect.  Using the first meaning, a node is not the context for
> the interface identifiers that are passed in crankback TLVs.
> Throughout the document the particular meaning can be determined
> by the context of the term.  Examples are:
>
> - Section 5.2, the sentence "Otherwise, multiple nodes might attempt =
to
> repair the LSP." means the control functions of signalling and =
routing.
>
> - Section 7.1 "As described above, full crankback information SHOULD
> indicate the node, link and other resources, which have been =
attempted."
> refers to the transport resource.

It is correct to observe that historically there has been poor =
separation
of controllers and transport devices within GMPLS, with much of this =
issue
arising from the historic collocation of controllers and data switches =
in
MPLS networks. This persists because of the (eminently sensible) =
tendency
to optimize for the majority case.

However, in the case of crankback, and specifically in the case of this
draft, the emphasis in providing 'full crankback information' is on the
addresses of transport links and nodes and not controllers. We will
revisit the draft to ensure that where control plane function is =
implied,
the "node" that takes action is clearly identified as the control plane
node.

> There are some occasions where the use of the term appear to be
> ambiguous and clarity would be appreciated.  In particular TLV
> types 10 and 32. If  type 10 represents a routing and signalling
> function, then what TLV describes the "transport plane node"
> (e.g., cross connect or Network Element)?  If type 32 means
> "transport plane nodes", then a different TLV may be needed
> to identify the "routing/signalling nodes" that have already
> participated in crankback attempts.
> Having a clearer distinction between control plane functions
> and transport plane resources would be helpful.

As indicated above, the intention of crankback is to apply a process to
the path determination for an LSP. The path is determined using =
transport
plane links and nodes, and although there may be some interesting
aggregation available by converting this information to control plane
nodes, the conversion is not necessarily simple. Thus, these TLVs all
refer to transport plane quantities, and we will make this clearer in =
the
draft.

Again, of course, in the majority case we can make considerable
optimizations by knowing that control plane and transport plane "nodes"
are related in a 1:1 ratio and are usually collocated.

> 2.       When crankback information is received at a =
"routing/signalling
> node", can it be used by the routing path computation function for =
other
> LSP requests than the LSP whose signalling caused the crankback =
action?

It is generally out-of-scope for the IETF to dictate how individual
implementations operate. It is quite conceivable that such an action =
would
be taken, but it is also clear that there is a potentially dangerous
interaction with the TE flooding process (i.e. the IGP). Thus we would =
say
that the crankback information MAY be used to inform other path
computations.

We would want to be very cautious that crankback is not intended to
supplement or replace the normal operation of the TE flooding mechanism
provided by the TE extensions to the IGP except for the establishment of =
a
single LSP. If the IGP is found to be deficient as a flooding mechanism =
we
would expect to look first at ways to address the problems through IGP
extensions before utilizing a signaling mechanism.

We will look at how to add some of this information to the draft.

> 3.       Section 6.1 "Segment-based Re-routing" option.  It is not =
clear
> what this means.  Can multiple "routing/signalling nodes" perform
> crankback on the same LSP at the same time if this flag is set?

Since the intention is to establish only one LSP, there must be only one
active sequence of LSP setup messages (RSVP-TE Path messages) at any =
time.
Thus only one LSR may attempt re-routing at any one time.

If you consider the processes by which Path messages are attempted and
crankback information is returned on PathErr messages, this will be =
clear.
That is, when an PSR receives a crankback PathErr, it may attempt to
re-route or it may forward the PathErr back upstream.

It might help if we reworded the draft to say "Any node may attempt
rerouting after it receives an error report and before it passes the =
error
report further upstream."

> 4.       Section 4.3 History persistence.  If a repair point (a
> "routing/signalling node") is unsuccessful in a crankback attempt, is =
it
> possible for it to be not involved when another repair point (e.g.,
> closer to the source) succeeds in a crankback attempt.  If so, how
> does the first repair point know to clear its history?

Note that the purpose of the history table as described in section 4.3 =
is
to correlate information when repeated retry attempts are made by the =
same
LSR. Suppose an attempt is made to route from A through B, and the
signalling controller for B returns a failure with crankback =
information.
An attempt may be made to route from A through C, and this may also fail
with the return of crankback information. The next attempt SHOULD NOT be
to route from A through B, and this is achieved by use of the history
table.

The history table can be discarded by the signaling controller for A if
the LSP is successfully established through A. The history table MAY be
retained after the signaling controller for A sends an error upstream,
however it is questionable what value this provides since a future retry
as a result of crankback rerouting should not attempt to route through A
(such is the nature of crankback). If the history information is =
retained
for a longer period it SHOULD be discarded after a local timeout has
expired, and that timer MUST be shorter than the timer used by the =
ingress
to re-attempt a failed service (note that re-attempting a failed service
is not the same as making a re-route attempt after failure).

As mentioned for point 2, the crankback information MAY be used to =
enhance
future routing attempts for any LSP, but this is not what section 4.3 is
describing.

We will try to clarify this in the draft.

> 5.       Section 4.5 Retries.  Some guidance on setting the number of
> retries may be helpful as this is a distributed parameter.  Is it set =
to
> be the same value at all points that can perform crankback within one
> network?

The view of CCAMP at the moment is that although it is technically
possible to allow the number of retries to be set for each LSP, this
probably represents too much configuration and too fine a level of
control. It seems likely that initial deployments will wish to set the
number of retries per node through a network-wide configuration constant
(that is, all LSRs capable of retrying will apply the same count) with =
the
possibility of configuring specific LSRs to have greater or lower =
counts.
Note that configuring an LSR not to be able to perform retries is
equivalent to configuring the retry count to be zero for that LSR.

It is also probable that initial deployments will significantly restrict
the number of LSRs within the network that can perform crankback
rerouting. This would probably be limited to "boundary" nodes.

In the event that implementations and deployments wish to control the
number of retries on a per LSP basis, we would revisit the signaling
specification and add the relevant information to the Path and PathErr
messages.

The actual value to set for a retry threshold is entirely a deployment
issue. It will be constrained by the topology and nature of the network.
It would be inappropriate to suggest a figure in this draft since there
are no hard and fast rules.

In review of section 4.5 of the draft, we see that there is some old =
text
describing more flexibility in the control of retries than we intend to
provide. Thank you for drawing our attention to this; we will clean it =
up.


Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this =
topic
is by sending mail to the CCAMP mailing list. Details of how to =
subscribe
to this list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella

------=_NextPart_000_0060_01C4FAF8.FFC72090
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>To: Mr. Kam Lam, Rapporteur =
Q14/15<BR>From:=20
Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: Alex Zinin and Bill Fenner, IETF =
Routing Area=20
Directors</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Scott Bradner, =
IETF liaison to=20
ITU-T<BR>Subject: Crankback in GMPLS Systems<BR>For: =
Information</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Dear Kam,<BR><BR>Thank you for your =
liaison=20
concerning draft-ietf-ccamp-crankback-03. It is<BR>useful to have =
additional=20
review input from a wide audience. Please convey<BR>our special thanks =
to=20
Stephen Shew and Marco Carugi for their detailed<BR>review of the draft =
in=20
Geneva.<BR><BR>We would like to urge Q14/15 to continue to consider this =
draft=20
as further<BR>work is carried out on crankback within the context of=20
G.7713.<BR><BR>In response to the specific points that were raised in =
the=20
liaison...<BR><BR>&gt; 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Semantics =
of the=20
term "node".&nbsp; Due to the GMPLS principle of<BR>&gt; maintaining =
separation=20
of control and transport (data/bearer) planes,<BR>&gt; there are two =
meanings=20
for the term "node".&nbsp; First, an instance of a<BR>&gt; signalling =
protocol=20
(and/or routing protocol) that has some transport<BR>&gt; resources in =
its=20
scope.&nbsp; Second, a transport plane resource such as a<BR>&gt; cross=20
connect.&nbsp; Using the first meaning, a node is not the context =
for<BR>&gt;=20
the interface identifiers that are passed in crankback TLVs.<BR>&gt; =
Throughout=20
the document the particular meaning can be determined<BR>&gt; by the =
context of=20
the term.&nbsp; Examples are:<BR>&gt;<BR>&gt; - Section 5.2, the =
sentence=20
"Otherwise, multiple nodes might attempt to<BR>&gt; repair the LSP." =
means the=20
control functions of signalling and routing.<BR>&gt;<BR>&gt; - Section =
7.1 "As=20
described above, full crankback information SHOULD<BR>&gt; indicate the =
node,=20
link and other resources, which have been attempted."<BR>&gt; refers to =
the=20
transport resource.<BR><BR>It is correct to observe that historically =
there has=20
been poor separation<BR>of controllers and transport devices within =
GMPLS, with=20
much of this issue<BR>arising from the historic collocation of =
controllers and=20
data switches in<BR>MPLS networks. This persists because of the =
(eminently=20
sensible) tendency<BR>to optimize for the majority case.<BR><BR>However, =
in the=20
case of crankback, and specifically in the case of this<BR>draft, the =
emphasis=20
in providing 'full crankback information' is on the<BR>addresses of =
transport=20
links and nodes and not controllers. We will<BR>revisit the draft to =
ensure that=20
where control plane function is implied,<BR>the "node" that takes action =
is=20
clearly identified as the control plane<BR>node.<BR><BR>&gt; There are =
some=20
occasions where the use of the term appear to be<BR>&gt; ambiguous and =
clarity=20
would be appreciated.&nbsp; In particular TLV<BR>&gt; types 10 and 32. =
If&nbsp;=20
type 10 represents a routing and signalling<BR>&gt; function, then what =
TLV=20
describes the "transport plane node"<BR>&gt; (e.g., cross connect or =
Network=20
Element)?&nbsp; If type 32 means<BR>&gt; "transport plane nodes", then a =

different TLV may be needed<BR>&gt; to identify the "routing/signalling =
nodes"=20
that have already<BR>&gt; participated in crankback attempts.<BR>&gt; =
Having a=20
clearer distinction between control plane functions<BR>&gt; and =
transport plane=20
resources would be helpful.<BR><BR>As indicated above, the intention of=20
crankback is to apply a process to<BR>the path determination for an LSP. =
The=20
path is determined using transport<BR>plane links and nodes, and =
although there=20
may be some interesting<BR>aggregation available by converting this =
information=20
to control plane<BR>nodes, the conversion is not necessarily simple. =
Thus, these=20
TLVs all<BR>refer to transport plane quantities, and we will make this =
clearer=20
in the<BR>draft.<BR><BR>Again, of course, in the majority case we can =
make=20
considerable<BR>optimizations by knowing that control plane and =
transport plane=20
"nodes"<BR>are related in a 1:1 ratio and are usually =
collocated.<BR><BR>&gt;=20
2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When crankback information is =
received at=20
a "routing/signalling<BR>&gt; node", can it be used by the routing path=20
computation function for other<BR>&gt; LSP requests than the LSP whose=20
signalling caused the crankback action?<BR><BR>It is generally =
out-of-scope for=20
the IETF to dictate how individual<BR>implementations operate. It is =
quite=20
conceivable that such an action would<BR>be taken, but it is also clear =
that=20
there is a potentially dangerous<BR>interaction with the TE flooding =
process=20
(i.e. the IGP). Thus we would say<BR>that the crankback information MAY =
be used=20
to inform other path<BR>computations.<BR><BR>We would want to be very =
cautious=20
that crankback is not intended to<BR>supplement or replace the normal =
operation=20
of the TE flooding mechanism<BR>provided by the TE extensions to the IGP =
except=20
for the establishment of a<BR>single LSP. If the IGP is found to be =
deficient as=20
a flooding mechanism we<BR>would expect to look first at ways to address =
the=20
problems through IGP<BR>extensions before utilizing a signaling=20
mechanism.<BR><BR>We will look at how to add some of this information to =
the=20
draft.<BR><BR>&gt; 3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 6.1=20
"Segment-based Re-routing" option.&nbsp; It is not clear<BR>&gt; what =
this=20
means.&nbsp; Can multiple "routing/signalling nodes" perform<BR>&gt; =
crankback=20
on the same LSP at the same time if this flag is set?<BR><BR>Since the =
intention=20
is to establish only one LSP, there must be only one<BR>active sequence =
of LSP=20
setup messages (RSVP-TE Path messages) at any time.<BR>Thus only one LSR =
may=20
attempt re-routing at any one time.<BR><BR>If you consider the processes =
by=20
which Path messages are attempted and<BR>crankback information is =
returned on=20
PathErr messages, this will be clear.<BR>That is, when an PSR receives a =

crankback PathErr, it may attempt to<BR>re-route or it may forward the =
PathErr=20
back upstream.<BR><BR>It might help if we reworded the draft to say "Any =
node=20
may attempt<BR>rerouting after it receives an error report and before it =
passes=20
the error<BR>report further upstream."<BR><BR>&gt;=20
4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 4.3 History =
persistence.&nbsp; If=20
a repair point (a<BR>&gt; "routing/signalling node") is unsuccessful in =
a=20
crankback attempt, is it<BR>&gt; possible for it to be not involved when =
another=20
repair point (e.g.,<BR>&gt; closer to the source) succeeds in a =
crankback=20
attempt.&nbsp; If so, how<BR>&gt; does the first repair point know to =
clear its=20
history?<BR><BR>Note that the purpose of the history table as described =
in=20
section 4.3 is<BR>to correlate information when repeated retry attempts =
are made=20
by the same<BR>LSR. Suppose an attempt is made to route from A through =
B, and=20
the<BR>signalling controller for B returns a failure with crankback=20
information.<BR>An attempt may be made to route from A through C, and =
this may=20
also fail<BR>with the return of crankback information. The next attempt =
SHOULD=20
NOT be<BR>to route from A through B, and this is achieved by use of the=20
history<BR>table.<BR><BR>The history table can be discarded by the =
signaling=20
controller for A if<BR>the LSP is successfully established through A. =
The=20
history table MAY be<BR>retained after the signaling controller for A =
sends an=20
error upstream,<BR>however it is questionable what value this provides =
since a=20
future retry<BR>as a result of crankback rerouting should not attempt to =
route=20
through A<BR>(such is the nature of crankback). If the history =
information is=20
retained<BR>for a longer period it SHOULD be discarded after a local =
timeout=20
has<BR>expired, and that timer MUST be shorter than the timer used by =
the=20
ingress<BR>to re-attempt a failed service (note that re-attempting a =
failed=20
service<BR>is not the same as making a re-route attempt after=20
failure).<BR><BR>As mentioned for point 2, the crankback information MAY =
be used=20
to enhance<BR>future routing attempts for any LSP, but this is not what =
section=20
4.3 is<BR>describing.<BR><BR>We will try to clarify this in the=20
draft.<BR><BR>&gt; 5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section 4.5=20
Retries.&nbsp; Some guidance on setting the number of<BR>&gt; retries =
may be=20
helpful as this is a distributed parameter.&nbsp; Is it set to<BR>&gt; =
be the=20
same value at all points that can perform crankback within one<BR>&gt;=20
network?<BR><BR>The view of CCAMP at the moment is that although it is=20
technically<BR>possible to allow the number of retries to be set for =
each LSP,=20
this<BR>probably represents too much configuration and too fine a level=20
of<BR>control. It seems likely that initial deployments will wish to set =

the<BR>number of retries per node through a network-wide configuration=20
constant<BR>(that is, all LSRs capable of retrying will apply the same =
count)=20
with the<BR>possibility of configuring specific LSRs to have greater or =
lower=20
counts.<BR>Note that configuring an LSR not to be able to perform =
retries=20
is<BR>equivalent to configuring the retry count to be zero for that=20
LSR.<BR><BR>It is also probable that initial deployments will =
significantly=20
restrict<BR>the number of LSRs within the network that can perform=20
crankback<BR>rerouting. This would probably be limited to "boundary"=20
nodes.<BR><BR>In the event that implementations and deployments wish to =
control=20
the<BR>number of retries on a per LSP basis, we would revisit the=20
signaling<BR>specification and add the relevant information to the Path =
and=20
PathErr<BR>messages.<BR><BR>The actual value to set for a retry =
threshold is=20
entirely a deployment<BR>issue. It will be constrained by the topology =
and=20
nature of the network.<BR>It would be inappropriate to suggest a figure =
in this=20
draft since there<BR>are no hard and fast rules.<BR><BR>In review of =
section 4.5=20
of the draft, we see that there is some old text<BR>describing more =
flexibility=20
in the control of retries than we intend to<BR>provide. Thank you for =
drawing=20
our attention to this; we will clean it up.<BR><BR><BR>Thank you once =
again for=20
your feedback on this draft.<BR>If you have further comments, we would =
certainly=20
like to hear them. The<BR>easiest way for individuals to contribute to =
the=20
discussion of this topic<BR>is by sending mail to the CCAMP mailing =
list.=20
Details of how to subscribe<BR>to this list can be found at<BR></FONT><A =

href=3D"http://www.ietf.org/html.charters/ccamp-charter.html"><FONT =
face=3DCourier=20
size=3D2>http://www.ietf.org/html.charters/ccamp-charter.html</FONT></A><=
BR><BR><FONT=20
face=3DCourier size=3D2>Yours sincerely,<BR>Adrian Farrel and Kireeti=20
Kompella<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0060_01C4FAF8.FFC72090--




Envelope-to: [e-mail]
Delivery-date: Sat, 15 Jan 2005 12:25:50 +0000
Message-ID: <008b01c4fafd$1cc292c0$16cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Updated Draft Response to Incoming liaison (2) from ITU-T SG15
Date: Sat, 15 Jan 2005 11:54:24 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C4FAF8.F548D140"

This is a multi-part message in MIME format.

------=_NextPart_000_005D_01C4FAF8.F548D140
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks Don and all for this draft.

I have made a few updates chiefly for format and process, and will send =
this on Sunday 16th, so comment quickly please. Sorry for the tight =
timeline

Adrian

=3D=3D=3D
To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Cc: Alex Zinin and Bill Fenner, IETF Routing Area Directors
    Scott Bradner, IETF liaison to ITU-T
For: Information
Subject: Response to Liaison Concerning the Comparison of LMP and ASON =
Discovery

Dear Kam,

The IETF CCAMP Working Group thanks ITU-T Q14/15 for their feedback on =
draft-ietf-ccamp-transport-lmp-00.txt. It is always useful to have extra =
review of our drafts, and since this draft attempts to explain ITU-T =
concepts to the IETF audience, it is particularly helpful to your input.

>Q14/15 thanks the IETF CCAMP WG for providing us the draft document
><draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the=20
 >meeting and several of the comments are provided below. Based upon=20
 >this discussion we believe it would be highly beneficial to have some=20
 >joint discussions on terminology to ensure an aligned view to=20
 >facilitate our future work efforts.

Events have overtaken this liaison response and a meeting has been set =
up. See the end of this liaison response for more comments.

Please see the reply to your specific issues in the following text.

>We have several questions of clarification, e.g., in section 3.1
>(paragraph 2) of the I-D, "The separation between the two processes and =

>corresponding two name spaces has the advantage that the discovery of=20
 >the transport plane can be performed independent from that of the=20
 >control plane (and vice-versa), and independent of the method used in=20
 >each name space. This allows assigning link connections in the control =

 >plane without the link connection being physically connected."
>=20
 >What is the intention of the term independent, for example, could it =
be
>indicating at a different time or different approaches? In the last=20
 >sentence, is "assign" used in the context of the management plane,=20
 >meaning management plane provisioning? Is it assumed that the=20
 >transport plane resources supporting the link connection endpoints=20
 >exist or do not exist? In section 4.2 (paragraph 2) of the I-D, =
"G.8080=20
 >refers to a component link as a variable adaptation function i.e. a=20
 >single server layer trail dynamically supporting different =
multiplexing
>structures." This could be interpreted as indicating G.8080
>defines the term "component link". G.8080 does not use this
>term. Some clarification would be beneficial.=20
=20
 As this section of the draft indicates, it is summarizing G.8080 =
Discovery (not LMP). The description is directly based on G.8080's text,
i.e.:
=20
" This separation allows control plane names to be completely=20
  separate from transport plane names, and completely independent=20
  of the method used to populate the DAs with those transport names."

" In order to assign an SNP-SNP link connection to an SNPP link, it=20
  is only necessary for the transport name for the link connection to=20
  exist. Thus, it is possible to assign link connections to the control=20
  plane without the link connection being physically connected."
=20
 The authors will clarify for these paragraphs that we are quoting from =
G.8080 (not describing LMP). In particular:

"G.8080 refers to a component link as a variable adaptation function" =
was worded to present an interpretation of G.8080 from an IETF =
terminology perspective; i.e. the LMP component link is refered to by =
G.8080 as a variable adaptation function. The authors will clarify the =
text to say "G.8080's variable adaptation function is broadly equivalent =
to LMP's component link."

>Initial reviews of the draft document have raised concerns about the
>possible misinterpretation in the usage of the term 'TE link'. As the=20
 >draft notes, the definition of a TE link is concise. Some more clarity =

 >would be appreciated. Our current understanding of this term includes=20
 >the following: A TE link may be composed of resource from multiple=20
 >(G.805) layers in parallel. If so, this is an important distinction as =

 >an SNPP link is in a single layer only. An SNPP link may contain SNP
>link connections from various links (e.g., different STS-1s from
>a set of parallel OC-48 trails). It is not clear if this is
>also true for TE links. We think it may, but it is not stated.
>SNPPs exist at different routing levels (not layers) and thus an
>SNPP link at a higher level can encompass SNPPs at a lower level
>(see Section 6.2.2 of G.8080 Amendment 2, which is attached for
>your convenience). We think TE links may do this with bundles
>and FAs, but the definition is not clear to us.=20
 >=20
>Please advise if this is a correct understanding or not. This may have
>an impact on the terminology mapping in the draft. We think it would=20
>be beneficial to have a TE link definition that enables these=20
 >distinctions to be understood.
=20
It is not the intention of this draft to define a TE link. The TE link =
is defined in the LMP draft (draft-ietf-ccamp-lmp-10.txt) through a =
restatement of the definition in the GMPLS Routing draft =
(draft-ietf-ccamp-gmpls-routing-09.txt).=20

At the request of several individuals we tried to bring clarity to the =
TE link concept by additional explanation within this draft. The IETF =
definition of the TE link describes the way that resources are grouped =
and mapped for the purpose of path computation. Constraints on the =
physical resources define what is possible rather than defining any =
elaborate structures within the TE link.=20

Therefore an SNPP link could easily be mapped to a TE link.

There is a separation between the constraints of the physical resources =
and the information aggregation of TE link. Bundling is a mechanism to =
efficiently aggregate TE resources within the constraints of the =
physical technology.=20

An LSP created across an LSP region (see =
draft-ietf-mpls-lsp-hierarchy-08.txt) in the network may be assigned as =
a TE link by an upper region and so appear as TE resources within the =
upper region (just as any other TE link). Such a TE link is referred to =
as a Forwarding Adjacency.

A TE link may contain STS-1s from parallel OC-48 trails.=20
=20
 The authors will add text to clarify.=20
=20
 >In the table in section 4.2 "CP" is mapped to "Interface". A
>Connection Point is more closely related to a timeslot, wavelength,=20
 >etc. rather than to an entire interface. Similarly "CP Name" is mapped =

 >to "Interface ID" while it might more closely relate to a "Label".
=20
 LMP distinguishes data links depending on the multiplexing capability =
of the endpoint on that link: "ports" are not multiplexing capable, =
"component links" are multiplexing capable. Following this reasoning, =
the data link for SDH/SONET networks is not the "timeslot" (this is the =
label) but the SDH/SONET section on which the timeslot (i.e. label) gets =
allocated. This is clearly described in draft-ietf-ccamp-lmp-10.txt.

A Connection Point (CP) most closely maps to an interface in terms of =
the IETF definitions.=20

>Joint discussion of the terminology mapping may be beneficial in
>reaching alignment on the most accurate mapping. As noted above, these=20
>represent several of the comments discussed. In order to progress our=20
>mutual understanding, we would like to invite IETF participants to=20
 >attend the January 24-28, 2005 Q14/15 interim meeting, in New Jersey,=20
 >USA, where we could devote a session to terminology alignment. We=20
 >believe this effort will greatly benefit our future collaboration on=20
 >control plane standards development.  We welcome IETF experts'=20
 >participation in other sessions of the interim meeting as well.
>Details of the meeting agenda will be provided prior to the meeting. =20
 >For those interested in further information and/or attending the=20
 >interim meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
>[e-mail]) by 10th January 2005.=20

We welcome the efforts by Q14/15 to improve mutual understanding of =
terminology.

This meeting and the clarification of general GMPLS/ASON terminology is =
distinct from the review of draft-ietf-ccamp-transport-lmp. This draft =
has fairly limited scope and does not need to be dependent on a full and =
mutual exchange of terminology.

Various members of the CCAMP working group inclusing some of the authors =
of this draft plan to attend your meeting on January 25th and 26th.
=20

Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this =
topic
is by sending mail to the CCAMP mailing list. Details of how to =
subscribe
to this list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella

------=_NextPart_000_005D_01C4FAF8.F548D140
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DCourier size=3D2>Thanks Don and all for this =
draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>I have made a few updates chiefly for =
format and=20
process, and will send this&nbsp;on Sunday 16th,&nbsp;so comment quickly =
please.=20
Sorry for the tight timeline</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>=3D=3D=3D</FONT></DIV>
<DIV>
<DIV><FONT face=3DCourier size=3D2>To: Mr. Kam Lam, Rapporteur =
Q14/15<BR>From:=20
Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: Alex Zinin and Bill Fenner, IETF =
Routing Area=20
Directors</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; Scott Bradner, =
IETF liaison to=20
ITU-T<BR>For: Information</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: Response to Liaison =
Concerning=20
the&nbsp;Comparison of LMP and ASON Discovery</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Dear Kam,<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>The IETF CCAMP Working Group thanks =
ITU-T Q14/15=20
for their feedback on&nbsp;draft-ietf-ccamp-transport-lmp-00.txt. It is =
always=20
useful to have extra review of our drafts, and since this draft attempts =
to=20
explain ITU-T concepts to the IETF audience, it is particularly helpful =
to your=20
input.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt;Q14/15 thanks the IETF CCAMP WG =
for providing=20
us the draft =
document<BR>&gt;&lt;draft-ietf-ccamp-transport-lmp-00.txt&gt;. This=20
I-D was discussed at the&nbsp;<BR> &gt;meeting and several of the =
comments are=20
provided below. Based upon&nbsp;<BR> &gt;this discussion we believe it =
would be=20
highly beneficial to have some&nbsp;<BR> &gt;joint discussions on =
terminology to=20
ensure an aligned view to&nbsp;<BR> &gt;facilitate our future work=20
efforts.</FONT></DIV><FONT face=3DCourier size=3D2></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Events have overtaken this liaison =
response and a=20
meeting has been set up. See the end of this liaison response for more=20
comments.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Please see the reply to your =
specific&nbsp;issues=20
in the following text.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>&gt;We have several questions of clarification, e.g., in section=20
3.1<BR>&gt;(paragraph 2) of the I-D, "The separation between the two =
processes=20
and&nbsp;<BR>&gt;corresponding two name spaces has the advantage that =
the=20
discovery of&nbsp;<BR> &gt;the transport plane can be performed =
independent from=20
that of the&nbsp;<BR> &gt;control plane (and vice-versa), and =
independent of the=20
method used in&nbsp;<BR> &gt;each name space. This allows assigning link =

connections in the control&nbsp;<BR> &gt;plane without the link =
connection being=20
physically connected."<BR>&gt;&nbsp;<BR> &gt;What is the intention of =
the term=20
independent, for example, could it be<BR>&gt;indicating at a different =
time or=20
different approaches? In the last&nbsp;<BR> &gt;sentence, is "assign" =
used in=20
the context of the management plane,&nbsp;<BR> &gt;meaning management =
plane=20
provisioning? Is it assumed that the&nbsp;<BR> &gt;transport plane =
resources=20
supporting the link connection endpoints&nbsp;<BR> &gt;exist or do not =
exist? In=20
section 4.2 (paragraph 2) of the I-D, "G.8080&nbsp;<BR> &gt;refers to a=20
component link as a variable adaptation function i.e. a&nbsp;<BR> =
&gt;single=20
server layer trail dynamically supporting different=20
multiplexing<BR>&gt;structures." This could be interpreted as indicating =

G.8080<BR>&gt;defines the term "component link". G.8080 does not use=20
this<BR>&gt;term. Some clarification would be =
beneficial.&nbsp;<BR>&nbsp;<BR> As=20
this section of the draft indicates, it is summarizing G.8080 Discovery =
(not=20
LMP). The&nbsp;description is directly based on G.8080's=20
text,<BR>i.e.:<BR>&nbsp;<BR>" This separation allows control plane names =
to be=20
completely&nbsp;<BR>&nbsp; separate from transport plane names, and =
completely=20
independent&nbsp;<BR>&nbsp; of the method used to populate the DAs with =
those=20
transport names."<BR><BR>" In order to assign an SNP-SNP link connection =
to an=20
SNPP link, it&nbsp;<BR>&nbsp; is only necessary for the transport name =
for the=20
link connection to&nbsp;<BR>&nbsp; exist. Thus, it is possible to assign =
link=20
connections to the control&nbsp;<BR>&nbsp; plane without the link =
connection=20
being physically connected."<BR>&nbsp;<BR> The authors will clarify for =
these=20
paragraphs that we are quoting from&nbsp;G.8080 (not describing LMP). In =

particular:<BR><BR>"G.8080 refers to a component link as a variable =
adaptation=20
function"&nbsp;was worded to present an interpretation of G.8080 from an =
IETF=20
terminology perspective; i.e. the LMP component link is refered to by=20
G.8080&nbsp;as a variable adaptation function. The authors&nbsp;will =
clarify the=20
text to say "G.8080's variable adaptation function is =
broadly&nbsp;equivalent to=20
LMP's component link."<BR><BR>&gt;Initial reviews of the draft document =
have=20
raised concerns about the<BR>&gt;possible misinterpretation in the usage =
of the=20
term 'TE link'. As the&nbsp;<BR> &gt;draft notes, the definition of a TE =
link is=20
concise. Some more clarity&nbsp;<BR> &gt;would be appreciated. Our =
current=20
understanding of this term includes&nbsp;<BR> &gt;the following: A TE =
link may=20
be composed of resource from multiple&nbsp;<BR> &gt;(G.805) layers in =
parallel.=20
If so, this is an important distinction as&nbsp;<BR> &gt;an SNPP link is =
in a=20
single layer only. An SNPP link may contain SNP<BR>&gt;link connections =
from=20
various links (e.g., different STS-1s from<BR>&gt;a set of parallel =
OC-48=20
trails). It is not clear if this is<BR>&gt;also true for TE links. We =
think it=20
may, but it is not stated.<BR>&gt;SNPPs exist at different routing =
levels (not=20
layers) and thus an<BR>&gt;SNPP link at a higher level can encompass =
SNPPs at a=20
lower level<BR>&gt;(see Section 6.2.2 of G.8080 Amendment 2, which is =
attached=20
for<BR>&gt;your convenience). We think TE links may do this with=20
bundles<BR>&gt;and FAs, but the definition is not clear to us.&nbsp;<BR> =

&gt;&nbsp;<BR>&gt;Please advise if this is a correct understanding or =
not. This=20
may have<BR>&gt;an impact on the terminology mapping in the draft. We =
think it=20
would&nbsp;<BR>&gt;be beneficial to have a TE link definition that =
enables=20
these&nbsp;<BR> &gt;distinctions to be understood.<BR>&nbsp;<BR>It is =
not the=20
intention of this draft&nbsp;to define a TE link. The TE link =
is&nbsp;defined in=20
the LMP draft (draft-ietf-ccamp-lmp-10.txt) through a restatement of the =

definition in the GMPLS Routing draft =
(draft-ietf-ccamp-gmpls-routing-09.txt).=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>At the request&nbsp;of several individuals we tried to bring =
clarity to the=20
TE link concept by additional explanation within this draft. =
The&nbsp;IETF=20
definition of the TE link describes the way that resources =
are&nbsp;grouped and=20
mapped for the purpose of path computation. Constraints on&nbsp;the =
physical=20
resources define what is possible rather than defining any=20
elaborate&nbsp;structures within the TE link. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore an SNPP link could easily be mapped&nbsp;to a TE =
link.</DIV>
<DIV>&nbsp;</DIV>
<DIV>There is a separation between the constraints of the&nbsp;physical=20
resources and the information aggregation of TE link. Bundling is=20
a&nbsp;mechanism to efficiently aggregate TE resources within&nbsp;the=20
constraints of the physical technology.&nbsp;<BR><BR>An LSP created =
across an=20
LSP region (see&nbsp;draft-ietf-mpls-lsp-hierarchy-08.txt) in the =
network may be=20
assigned as a TE link by an upper region and so appear as TE=20
resources&nbsp;within the upper region (just as any other TE link). Such =
a TE=20
link is referred to as a Forwarding&nbsp;Adjacency.</DIV>
<DIV><BR>A TE link may contain STS-1s from parallel OC-48=20
trails.&nbsp;<BR>&nbsp;<BR> The authors will add text to=20
clarify.&nbsp;<BR>&nbsp;<BR> &gt;In the table in section 4.2 "CP" is =
mapped to=20
"Interface". A<BR>&gt;Connection Point is more closely related to a =
timeslot,=20
wavelength,&nbsp;<BR> &gt;etc. rather than to an entire interface. =
Similarly "CP=20
Name" is mapped&nbsp;<BR> &gt;to "Interface ID" while it might more =
closely=20
relate to a "Label".<BR>&nbsp;<BR> LMP distinguishes data links =
depending on the=20
multiplexing capability&nbsp;of the endpoint on that link: "ports" are =
not=20
multiplexing capable,&nbsp;"component links"&nbsp;are multiplexing =
capable.=20
Following&nbsp;this reasoning, the data link for SDH/SONET networks is =
not the=20
"timeslot" (this is the label) but the SDH/SONET section on =
which&nbsp;the=20
timeslot (i.e. label) gets allocated. This is clearly described in=20
draft-ietf-ccamp-lmp-10.txt.</DIV>
<DIV>&nbsp;</DIV>
<DIV>A Connection Point (CP) most closely maps to an interface in =
terms&nbsp;of=20
the IETF definitions. </DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt;Joint discussion of the terminology mapping may be beneficial=20
in<BR>&gt;reaching alignment on the most accurate mapping. As noted =
above,=20
these&nbsp;<BR>&gt;represent several of the comments discussed. In order =
to=20
progress our&nbsp;<BR>&gt;mutual understanding, we would like to invite =
IETF=20
participants to&nbsp;<BR> &gt;attend the January 24-28, 2005 Q14/15 =
interim=20
meeting, in New Jersey,&nbsp;<BR> &gt;USA, where we could devote a =
session to=20
terminology alignment. We&nbsp;<BR> &gt;believe this effort will greatly =
benefit=20
our future collaboration on&nbsp;<BR> &gt;control plane standards=20
development.&nbsp; We welcome IETF experts'&nbsp;<BR> &gt;participation =
in other=20
sessions of the interim meeting as well.<BR>&gt;Details of the meeting =
agenda=20
will be provided prior to the meeting.&nbsp;&nbsp;<BR> &gt;For those =
interested=20
in further information and/or attending the&nbsp;<BR> &gt;interim =
meeting should=20
contact the Rapporteur for Q.14/15 (H. Kam Lam,<BR>&gt;[e-mail]) =
by 10th=20
January 2005.&nbsp;<BR></DIV>
<DIV>We welcome the efforts by Q14/15 to improve mutual understanding of =

terminology.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This meeting and the clarification of general GMPLS/ASON =
terminology is=20
distinct from the review of draft-ietf-ccamp-transport-lmp. This draft =
has=20
fairly limited scope and does not need to be dependent on a full and =
mutual=20
exchange of terminology.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Various members of the CCAMP working group inclusing some of the =
authors of=20
this draft plan to attend your meeting on January 25th and 26th.</DIV>
<DIV>&nbsp;<BR></FONT><FONT face=3DCourier size=3D2></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Thank you once again for your =
feedback on this=20
draft.<BR>If you have further comments, we would certainly like to hear =
them.=20
The<BR>easiest way for individuals to contribute to the discussion of =
this=20
topic<BR>is by sending mail to the CCAMP mailing list. Details of how to =

subscribe<BR>to this list can be found at<BR></FONT><A=20
href=3D"http://www.ietf.org/html.charters/ccamp-charter.html"><FONT =
face=3DCourier=20
size=3D2>http://www.ietf.org/html.charters/ccamp-charter.html</FONT></A><=
BR><BR><FONT=20
face=3DCourier size=3D2>Yours sincerely,<BR>Adrian Farrel and Kireeti=20
Kompella<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_005D_01C4FAF8.F548D140--




Envelope-to: [e-mail]
Delivery-date: Sat, 15 Jan 2005 12:25:42 +0000
Message-ID: <008a01c4fafd$1bc03df0$16cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN
Date: Fri, 14 Jan 2005 22:33:12 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Sent: Friday, January 14, 2005 3:09 PM
Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting
inMinneapolis, MN


> There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting
> in Minneapolis, MN:
>
> February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft
Submissions
>
> All initial Internet-Drafts (-00) must be submitted by Monday, February
14th at 9:00 AM ET.
> As always, all initial submissions (-00) with a filename beginning with
"draft-ietf"
> must be approved by the appropriate WG Chair before they can be
processed or announced.
> WG Chair approval must be received by Monday, February 7th at 9:00 AM
ET.
>
> February 21st: Cutoff Date for Revised (i.e., -01 and higher)
Internet-Draft Submissions
>
> All revised Internet-Drafts (-01 and higher) must be submitted by
Monday, February 21st
> at 9:00 AM ET.
>
> Initial and revised Internet-Drafts received after their respective
cutoff dates will not
> be made available in the Internet-Drafts directory or announced, and
will have to be
> resubmitted. Please do not wait until the last minute to submit. The
Secretariat will
> begin accepting Internet-Draft submissions starting Monday, March 7th at
9:00 AM ET,
> but may not post or announce them until Monday, March 14th.
>
> Thank you for your understanding and cooperation. If you have any
questions or concerns,
> then please send a message to [e-mail].
>
> The IETF Secretariat
>
> FYI: The Internet-Draft cutoff dates as well as other significant dates
for the 62nd IETF
> Meeting can be found at http://www.ietf.org/meetings/IETF-62.html.
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>




Envelope-to: [e-mail]
Delivery-date: Fri, 14 Jan 2005 22:12:02 +0000
Message-ID: <051801c4fa85$e8505670$b4cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
Date: Fri, 14 Jan 2005 21:17:55 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Alex,

This draft has been through CCAMP WG last call and has been updated to my
satisfaction.

Please take it on its next step in the long (some may say too long)
journey towards being an RFC.

Thanks,
Adrian

<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-h
ello-01.txt>




Envelope-to: [e-mail]
Delivery-date: Fri, 14 Jan 2005 12:00:17 +0000
Message-ID: <046b01c4fa30$8f1dde10$b4cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 14 Jan 2005 11:43:28 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0442_01C4FA2E.43DEA1C0"

This is a multi-part message in MIME format.

------=_NextPart_000_0442_01C4FA2E.43DEA1C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Here are my comments on this draft.

It is a great shame to see an I-D put up for last call when it fails the =
idnits script. In particular, since this concerns how the IPR statements =
are interpreted, it is crucial that these issues are resolved before the =
draft can move forward. Additionally it is a matter of courtesy to the =
readers to resolve the formatting issues.

It seems to me that this draft is applicable to a strict ERO where one =
of the hops is a non-specific abstract node such as an AS number. This =
is made clear in section 2, but the Abstract and Introduction (yeah, and =
also the title and draft name) do not adequately expose this fact. But, =
further, the Introduction talks only about reoptimization without any =
mention of loose hops or abstract nodes. Thus the draft is schizoid to =
the third degree - is this loose path reoptimization, reoptimization of =
loose and non-specific abstract nodes, or general reoptimization? The =
draft needs to be consistent and clear.

The title contains acronyms which need to be spelled out (MPLS and LSP).

The Abstract is too long. Need it about half the length. You can move =
some of the material into the introduction which is currently rather =
short (shorter than the abstract!) Same comment about acronyms (MPLS, =
GMPLS, TE, LSP, ERO) - make sure they are expanded for their first =
usage.

Conventions used in this document. Contains unresolved citation.

Section 2
s/Ipv4/IPv4/

Section 2 states that an ERO expansion is either up to the next loose =
hop or to the destination. But, in fact, the ERO expansion may also be =
any partial fragment towards either of these targets (including next hop =
resolution). I suggest re-wording this paragraph to list (as bullets) =
what an ERO might contain, and in a separate list, what the computation =
might produce.

Section 2
s/The path an/The path of an/

Section 2.
s/head-End/head-end/

In section 2 I don't like the distinction between "CSPF or any other =
PCE-based path computation method". Part of the implication here is that =
PCE might not perform CSPF! I suspect you are trying to highlight that =
the computation may be performed locally of remotely. I don't think this =
is relevant to this I-D; you should simply say "invokes path =
computation".

Section 2
[RSVP-TE] unresolved normative reference.

Section 4.1
s/but instead just signal/but instead just signals/

In section 4.1 you add a note about the selection of component links =
from within a bundle. While this is true, it is unclear why you pick =
this case out but don't describe the selection of alternate resources =
(e.g. lambdas). This is associated to the new error values defined in =
section 4.2. How would you report a component link going oos? How would =
you report a link resource (e.g. a lambda) going oos? If you use "local =
link maintenance required" won't the computing node believe that the =
whole link is unusable? If your answer here is that the recomputation =
will ignore the error value and will perform a recomputation based on =
the new TED (see [GR-SHUT]) then why do you need to distinguish between =
link maintenance required and node maintenance required? If you actually =
need to report the component link or resource as a separate quantity, I =
suggest you refer to the crankback draft.

Section 4.1
I'm not comfortable with the Session Attributes toggling like this. This =
type of function is what the Admin Status object was invented for.

Section 5.3.1
   This=20
   bit is then cleared in subsequent RSVP path messages sent downstream.
This implies that a Path refresh *never* carries this bit set (which =
makes it a trigger when it comes after a Path with the bit set).
Thus we may lose the request (either through a lost Path message, or =
through a refresh catching up with a trigger Path message). I think we =
discussed this before. You need to make it clear in the draft that these =
requests can be lost.
I think it is also worth considering how to prevent the toggling off of =
the bit from appearing as a trigger message.

Section 5.3.1
        At this point, the LSR=20
        MAY decide to clear the ?h re-evaluation request?t of the=20
        SESSION-ATTRIBUTE object in subsequent RSVP Path messages sent=20
        downstream: this mode is the RECOMMENDED mode for the reasons=20
        described below. =20
It really isn't a matter of clearing the bit, so much as not propagating =
it. That is, it is not necessary to send a new Path message at this =
point.

Section 5.3.1
[PATH-COMP] is required as a normative reference.

In section 5.3.2
        - The link (sub-code=3D7) or the node (sub-code=3D8) MUST be=20
        locally registered for further reference (the TE database must=20
        be updated)=20
What does "the TE database must be updated" mean? Are you saying that =
the TED is now built from information flooded by the IGP *and* by =
information fed back from signaling? If so (and I don't approve!) then =
you must define what happens when you receive a new LSA for the specific =
link that contradicts the information signaled. There is a strong =
argument that says that *the* method we use for building the TED is IGP =
flooding - if this mechanism doesn't provide you with the information =
you need, then you should propose extensions to the IGP, not hook the =
information onto signaling.
OTOH it may be that all you mean is that the Session state should be =
updated to indicate the link or node that is being shut down so that =
later recomputation can avoid this link. In this case, I suggest you =
refer to the CCAMP crankback draft.

In section 5.3.2
        - ... Note that in the case of TE LSP=20
        spanning multiple administrative domains, it may be desirable=20
        for the boundary LSR to modify the RSVP PathError message and=20
        insert its own address for confidentiality reason.=20
Yes. Good point, but doesn't the error code also need to change? =
Otherwise it will appear that the border node is the node being taken =
oos.

Section 5.3.3. suggests the use of a timer. You must, therefore, suggest =
a default time value. I suspect that you want to suggest some basic =
multiple of the path computation time or of the IGP refresh period.

Section 6
Need to describe the processing by an LSR that does not understand the =
new flag (rather than understand it but not support it). note that you =
cannot define the behavior of legacy LSRs in this draft, so you must =
reference behavior defined in some other document.
Ditto the new error code.

Section 7
This technique has implications for the trust model between domains. In =
particular, one domain may cause another to perform additional (excess =
or unnecessary) work simply to ease its own task or for malicious =
reasons. Similarly, a headend domain might choose to ignore the requests =
for re-optimization issued by another domain. I think you need to point =
out that the peering agreements between domains need to include a =
definition of how this technique is supported.

Section 10
"Normative references" and "Informative references" need section numbers

Full Copyright Statement
Unnecessary quote marks.




Question...


How does the process of unsolicited notification (of a potential better =
path rather than of a link going oos) avoid thrashing races? As a very =
simple example, consider the following n/w.

<-A1-> <--A0-> <-A2->
A-----B       C-----D
      |       |
      |       |
E-----F---G---H-----I

Set up two LSPs AI and ED using EROs {A,B(L),H(L),I} and {E,F(L),C(L),D} =
producing paths ABFGHI and EFGHCD.

Now install a *low* bandwidth link BC capable of carrying either but not =
both LSPs. Both B and F will notice that the LSPs entering A0 through =
them can be re-optimized and will report the fact to A and E =
respectively. Both A and E will attempt mb4b, but (of course) only one =
will succeed. In a small network, this is not a big deal, but in a large =
network with a lot of LSPs this is clearly a waste of processing and =
will cause a degree of network thrash maybe only in the control plane, =
but maybe in the data plane if a lower priority LSP is re-routed first. =
In fact, this scenario can cause significant disruption in the data =
plane as the re-routed LSP will be preempted and could have been =
successfully left in its original place.

It seems that a considerably sophisticated policy is required for any =
domain, but particularly core domains like A0. In effect, the domain =
needs to evaluate the new link by examining all LSPs in the system and =
selecting which one(s) should be re-optimized. This type of processing =
is non-trivial and uses information stores that are not generally =
available (i.e. LSP maps).=20

Thus I would suggest removing the unsolicited notification of =
reoptimization opportunities (while retaining the unsolicited =
notification of links going oos) or requiring that the policy be =
timer-based not event triggered.


Adrian 
------=_NextPart_000_0442_01C4FA2E.43DEA1C0
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=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DCourier size=3D2>Here are my comments on this =
draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It is a great shame to see an I-D put =
up for last=20
call when it fails the idnits script. In particular, since this concerns =
how the=20
IPR statements are interpreted, it is crucial that these issues are =
resolved=20
before the draft can move forward. Additionally it is a matter of =
courtesy to=20
the readers to resolve the formatting issues.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It seems to me that this draft is =
applicable to a=20
strict ERO where one of the hops is a non-specific abstract node such as =
an AS=20
number. This is made clear in section 2, but the Abstract and =
Introduction=20
(yeah, and also the title and draft name) do not adequately expose this =
fact.=20
But, further, the Introduction talks only about reoptimization without =
any=20
mention of loose hops or abstract nodes. Thus the draft is schizoid to =
the third=20
degree - is this loose path reoptimization, reoptimization of loose and=20
non-specific abstract nodes, or general reoptimization? The draft needs =
to be=20
consistent and clear.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The title contains acronyms which =
need to be=20
spelled out (MPLS and LSP).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The Abstract is too long. Need it =
about half the=20
length. You can move some of the material into the introduction which is =

currently rather short (shorter than the abstract!) Same comment about =
acronyms=20
(MPLS, GMPLS, TE, LSP, ERO) - make sure they are expanded for their =
first=20
usage.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Conventions used in this document. =
Contains=20
unresolved citation.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>s/Ipv4/IPv4/</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2 states that an&nbsp;ERO =
expansion=20
is&nbsp;either up to the next loose hop or to the destination. But, in =
fact, the=20
ERO expansion may also be any partial fragment towards either of these =
targets=20
(including next hop resolution). I suggest re-wording this paragraph to =
list (as=20
bullets) what an ERO might contain, and in a separate list, what the =
computation=20
might produce.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>s/The path an/The path of =
an/</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>s/head-End/head-end/</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In section 2 I don't like the =
distinction between=20
"CSPF or&nbsp;any other PCE-based path computation method".&nbsp;Part of =
the=20
implication here is that PCE might not perform CSPF! I suspect you are =
trying to=20
highlight that the computation may be performed locally of remotely. I =
don't=20
think this is relevant to this I-D; you should simply say "invokes path=20
computation".<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Section 2</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>[RSVP-TE] unresolved normative=20
reference.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>Section 4.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>s/but instead just signal/but instead =
just=20
signals/</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In section 4.1 you add a note about =
the selection=20
of component links from within a bundle. While this is true, it is =
unclear why=20
you pick this case out but don't describe the selection of alternate =
resources=20
(e.g. lambdas). This is associated to the new error values defined in =
section=20
4.2. How would you report a component link going oos? How would you =
report a=20
link resource (e.g. a lambda) going oos? If you use "local link =
maintenance=20
required" won't the computing node believe that the whole link is =
unusable? If=20
your answer here is that the recomputation will ignore the error value =
and will=20
perform a recomputation based on the new TED (see [GR-SHUT]) then why do =
you=20
need to distinguish between link maintenance required and node =
maintenance=20
required? If you actually need to report the component link or resource =
as a=20
separate quantity, I suggest you refer to the crankback =
draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 4.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I'm not comfortable with the Session =
Attributes=20
toggling like this. This type of function is what the Admin Status =
object was=20
invented for.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.3.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp; This <BR>&nbsp;&nbsp; =
bit is then=20
cleared in subsequent RSVP path messages sent downstream.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This implies that a Path refresh =
*never* carries=20
this bit set (which makes it a trigger when it comes after a Path with =
the bit=20
set).</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Thus we may lose the request (either =
through a=20
lost Path message, or through a refresh catching up with a trigger Path=20
message).&nbsp;I think we discussed this before. You need to make it =
clear in=20
the draft that these requests can be lost.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>I think it is also worth considering =
how to=20
prevent the toggling off of the bit from appearing as a trigger=20
message.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.3.1</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At=20
this point, the LSR <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MAY =
decide to=20
clear the ?h re-evaluation request?t of the=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SESSION-ATTRIBUTE object =
in=20
subsequent RSVP Path messages sent=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; downstream: this mode is =
the=20
RECOMMENDED mode for the reasons =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
described below.&nbsp; <BR>It really isn't a matter of clearing the bit, =
so much=20
as not propagating it. That is, it is not necessary to send a new Path =
message=20
at this point.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.3.1</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>[PATH-COMP] is required as a =
normative=20
reference.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In section 5.3.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - The=20
link (sub-code=3D7) or the node (sub-code=3D8) MUST be=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; locally registered for =
further=20
reference (the TE database must =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
be updated) <BR>What does "the TE database must be updated" mean? Are =
you saying=20
that the TED is now built from information flooded by the IGP *and* by=20
information fed back from signaling? If so (and I don't approve!) then =
you must=20
define what happens when you receive a new LSA for the specific link =
that=20
contradicts the information signaled. There is a strong argument that =
says that=20
*the* method we use for building the TED is IGP flooding - if this =
mechanism=20
doesn't provide you with the information you need, then you should =
propose=20
extensions to the IGP, not hook the information onto =
signaling.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>OTOH it may be that all you mean is =
that the=20
Session state should be updated to indicate the link or node that is =
being shut=20
down so that later recomputation can avoid this link. In this case, I =
suggest=20
you refer to the CCAMP crankback draft.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>In section 5.3.2</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - ...=20
Note that in the case of TE LSP =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
spanning multiple administrative domains, it may be desirable=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for the boundary LSR to =
modify=20
the RSVP PathError message and =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
insert its own address for confidentiality reason. <BR>Yes. Good point, =
but=20
doesn't the error code also need to change? Otherwise it will appear =
that the=20
border node is the node being taken oos.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 5.3.3. suggests the use of a =
timer. You=20
must, therefore, suggest a default time value. I suspect that you want =
to=20
suggest some basic multiple of the path computation time or of the IGP =
refresh=20
period.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 6</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Need to describe the processing by an =
LSR that=20
does not understand the new flag (rather than understand it but not =
support it).=20
note that you cannot define the behavior of legacy LSRs in this draft, =
so you=20
must reference behavior defined in some other document.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Ditto the new error =
code.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 7</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>This technique has implications for =
the trust=20
model between domains. In particular, one domain may cause another to =
perform=20
additional (excess or unnecessary) work simply to ease its own task or =
for=20
malicious reasons. Similarly, a headend domain might choose to ignore =
the=20
requests for re-optimization issued by another domain. I think you need =
to point=20
out that the peering agreements between domains need to include a =
definition of=20
how this technique is supported.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Section 10</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"Normative references" and =
"Informative=20
references" need section numbers<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Full Copyright Statement</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Unnecessary quote marks.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV><BR></DIV></FONT>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Question...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV><BR>How does the process of unsolicited notification (of a =
potential better=20
path rather than of a link going oos) avoid thrashing races? As a very =
simple=20
example, consider the following n/w.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&lt;-A1-&gt;&nbsp;&lt;--A0-&gt;=20
&lt;-A2-&gt;</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>A-----B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
C-----D</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;=20
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>E-----F---G---H-----I</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Set up two LSPs AI and ED using EROs=20
{A,B(L),H(L),I} and {E,F(L),C(L),D} producing paths ABFGHI and=20
EFGHCD.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Now install a *low* bandwidth link BC =
capable of=20
carrying either but not both LSPs. Both B and F will notice that the =
LSPs=20
entering A0 through them can be re-optimized and will report the fact to =
A and E=20
respectively. Both A and E will attempt mb4b, but (of course) only one =
will=20
succeed. In a small network, this is not a big deal, but in a large =
network with=20
a lot of LSPs this is clearly a waste of processing and will cause a =
degree of=20
network thrash maybe only in the control plane, but maybe in the data =
plane if a=20
lower priority LSP is re-routed first. In fact, this scenario can cause=20
significant disruption in the data plane as the re-routed LSP will be =
preempted=20
and could have been successfully left in its original =
place.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>It seems that a considerably =
sophisticated policy=20
is required for any domain, but particularly core domains like A0. In =
effect,=20
the&nbsp;domain needs to evaluate the new link by examining all LSPs in =
the=20
system and selecting which one(s) should be re-optimized. This type of=20
processing is non-trivial and uses information stores that are not =
generally=20
available (i.e. LSP maps). </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thus I would suggest removing the =
unsolicited=20
notification of reoptimization opportunities (while retaining the =
unsolicited=20
notification of links going oos) or requiring that the policy be =
timer-based not=20
event triggered.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Adrian </FONT></DIV></BODY></HTML>

------=_NextPart_000_0442_01C4FA2E.43DEA1C0--




Envelope-to: [e-mail]
Delivery-date: Fri, 14 Jan 2005 04:50:05 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Jan 2005 13:47:33 +0900
From: "K. Miyazaki" <[e-mail]>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: [e-mail]
Subject: CALL FOR PARTICIPATION: iPOP 2005
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

************************************************************************

CALL FOR PARTICIPATION: iPOP 2005

The International Conference on IP + Optical Network (iPOP 2005)
GMPLS Interoperability Public Demonstration, Exhibition and Conference
Tokyo, Japan, February 21-22, 2005
http://www.pilab.org/ipop2005/

iPOP 2005 is the international conference that will convince you that
the IP and Optical technologies are the breakthrough needed for the
next-generation network infrastructure. It is intended to share the
latest results among industry and academia, and experience in state-
of-the-art of "IP and Optical Networking technologies".

Following this theme, it will provide a showcase for GMPLS
interoperability, which is the first demonstration of its kind in Asia.
Additionally, it will exhibit GMPLS network equipment (IP routers,
SONET/SDH XCs, Optical/Photonic XCs), GMPLS protocol test equipment,
GMPLS network operation support tools, Optical Switches, and other
related devices.

The conference also features keynotes, special and technical sessions by
leaders of IP and Photonic Network technologies from academia and
industry.

We hope for your participation.

YOU WILL ENJOY:
* GMPLS Interoperability Demonstrations by world-wide vendors:
- Multi-Region Routing and Signaling
- Multi-Layer Traffic Engineering
- MPLS/GMPLS Migration
- GMPLS-based Protection and Restoration

* Exhibition of state-of-the-art photonic network products:
- GMPLS network equipment: IP routers, SONET/SDH XCs, Optical/Photonic
XCs
- GMPLS protocol test equipment,
- GMPLS network operation support tools,
- Optical switches and other devices.

* Conference sessions on
- Interoperability of IP and Optical Networking Products and Services
- Field trial Plan/Report
- Network Operator Experience
- Advances of GMPLS and Future Optical Networking Technologies

CONFIRMED SPEAKERS
- Prof. Tomonori Aoyama, University of Tokyo, Japan.
- Prof. Shoichiro Asano, the National Institute of Informatics (NII),
Japan.
- Mr. Hisao Iizuka, NTT Communications, Japan.
- Dr. Bijan Jabbari, ISOCORE, USA.
- Prof. Ken-ichi Kitayama, Osaka University, Japan.
- Dr. Tatsuzo Koga, Tsukuba JGN II Research Center, Japan.
- Mr. Rajiv Papneja, ISOCORE, USA.
- Dr. Rajiv Ramaswami, Cisco Systems, USA.
- Mr. Jerry Sobieski, Mid-Atlantic Crossroads, USA.
- Dr. Masatoshi Suzuki, KDDI Laboratories, Japan.
- Ms. Amy Wang, Avici Systems, USA.
- Prof. Naoaki Yamanaka, Keio University, Japan.

REGISTRATION
Attendance to iPOP 2005 is FREE OF CHARGE with pre-registration
required.
Please register at http://www.pilab.org/ipop2005/ through January 31,
2005.

LOCATION
The venue, Tokyo Fashion Town (TFT) Hall is located in Tokyo's newly
developed seafront area known as Odaiba. It is easily accessible by
public transport from downtown Tokyo and Narita International Airport.
For more information, please visit the iPOP 2005 Web site at
http://www.pilab.org/ipop2005/.

TENTATIVE CONFERENCE PROGRAM

February 21, 2005
* Opening Addresses
- Prof. Tomonori Aoyama (General Chair, University of Tokyo)
- Dr. Bijan Jabbari (General Chair, ISOCORE)

* Keynote
- IP + Optical in the Next Generation Network
by Dr. Rajiv Ramaswami (Cisco Systems)

* Program Introduction
- Mr. Tadanobu Okada (TPC Chair, NTT)

* Special Session 1: Toward Truly Interoperable IP and Optical
Networking Products and Services
- Mr. Rajiv Papneja (ISOCORE)
- Prof. Naoaki Yamanaka (Organization Committee Chair, PIL)
- Ms. Amy Wang (OIF)

* Special Session 2: Project Report: IP+Optical Testbed
- Super SINET by Prof. Shoichiro Asano (NII)
- JGN II by Dr. Tatsuzo Koga (Tsukuba JGN II Research Center)
- 863 Project (China: Inviting)
- Keihanna by Prof. Ken-ichi Kitayama (Osaka University)
- Dragon Project by Mr. Jerry Sobieski (Mid-Atlantic Crossroads)

* Public Demonstration
GMPLS Interop Showcase at Exhibition Hall

* Special Session 3: Visions for the Next Generation IP+Optical Network
Research and Development
- Mr. Hisao Iizuka (NTT Communications)
- Dr. Masatoshi Suzuki (KDDI Laboratories)

February 22, 2005
* Technical Session 1: Multi-layer: IP+Optical
* Technical Session 2: New services: VPN, QoS, Grid
* Technical Session 3: Migration Scenario to GMPLS Networks
* Technical Session 4: Implementation Report Experiments

SPONSORSHIP
PIL (Photonic Internet Lab, http://www.pilab.org), founded by 6 vendors
and 1 service provider in 2002, is promoting R&D on next-generation
photonic network control protocols based on photonic technologies for
managed networks.

ISOCORE (http://www.isocore.com) is the leading technology validation
lab in the next generation IP and optical networking. Its goal is to
advance internetworking through technology validation and product
verification and to promote development and rapid deployment of
innovative networking technologies.

PIF (Photonic Internet Forum, http://www.scat.or.jp/photonic/english/)
is a non-profit organization contributing to the progress of info-
communication technology to realize all optical ultra-high-speed
networks.

************************************************************************




Envelope-to: [e-mail]
Delivery-date: Thu, 13 Jan 2005 13:46:40 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Jan 2005 07:45:44 -0600
From: Jim Jones <[e-mail]>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: "'Kireeti Kompella'" <[e-mail]>, [e-mail], Bill Fenner <[e-mail]>, [e-mail]
Subject: Re: Communication on Procedures for Modifying the Resource reSerVation Protocol (RSVP)
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Dear Mr. Farrel,

I apologize for the delay in replying to this letter. We appreciate your 
pointing us to this RFC. I have uploaded your letter as an OIF 
contribution, and it is on the agenda for next week's OIF Technical 
Committee meeting.

Regards,
Jim Jones
OIF Technical Committee Chair

Adrian Farrel wrote:

>To:      Mr. Jim Jones, Technical Chair, OIF
>From:    Adrian Farrel and Kireeti Kompella
>            Co-chairs of the CCAMP Working Group of the IETF
>Cc:      Alex Zinin and Bill Fenner, Routing Area Directors of the IETF
>         CCAMP Working Group
>For:     Information
>Subject: Procedures for Modifying the Resource reSerVation Protocol (RSVP)
>
>Dear Mr. Jones,
>
>We would like to draw your attention to a recent IETF publication that may be of relevance
>to your organisation in its work with MPLS and GMPLS signaling protocols.
>
>"Procedures for Modifying the Resource reSerVation Protocol (RSVP)" has been published as
>RFC 3936 and accepted by the IESG as a Best Common Practice (BCP 96).
>
>The abstract of this document reads as follows:
>    This memo specifies procedures for modifying the Resource reSerVation
>    Protocol (RSVP).  This memo also lays out new assignment guidelines
>    for number spaces for RSVP messages, object classes, class-types, and
>    sub-objects.
>
>    This document specifies an Internet Best Current Practices for the
>    Internet Community, and requests discussion and suggestions for
>    improvements.  Distribution of this memo is unlimited.
>
>The full document can be found at http://www.ietf.org/rfc/rfc3936.txt
>
>Yours sincerely,
>Kireeti Kompella & Adrian Farrel, CCAMP WG chairs
>
>
>
>
>  
>




Envelope-to: [e-mail]
Delivery-date: Thu, 13 Jan 2005 13:41:53 +0000
Message-ID: <B258A372CEA20246A363BB86753DB53601CABC80@zrtphxm2>
From: "Don Fedyk" <[e-mail]>
To: [e-mail]
Cc: "Don Fedyk" <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>, [e-mail], "Brungard, Deborah A, ALABS" <[e-mail]>, "Osama Aboul-Magd" <[e-mail]>, Jonathan Lang <[e-mail]>
Subject: Draft Response to Incoming liaison (2) from ITU-T SG15
Date: Thu, 13 Jan 2005 08:39:41 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F975.56ED63E9"

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

------_=_NextPart_001_01C4F975.56ED63E9
Content-Type: text/plain

Hi

The Authors of the CCAMP draft "A Transport Network View of the Link
Management Protocol" have prepared the following draft response to the
Liaison from ITU SG15. The text is included below for WG comments. 

Thanks,
Don Fedyk 


> 
>============
>From: ITU-T SG15
>To: CCAMP
>For: Action 
>Deadline: 15 March 2005 
 
>Subject: Response to IETF CCAMP WG on Comparison of LMP and ASON 
>Discovery

> 
>Q14/15 thanks the IETF CCAMP WG for providing us the draft document
><draft-ietf-ccamp-transport-lmp-00.txt>. This I-D was discussed at the 
>meeting and several of the comments are provided below. Based upon 
>this discussion we believe it would be highly beneficial to have some 
>joint discussions on terminology to ensure an aligned view to 
>facilitate our future work efforts.

IETF CCAMP thanks the Q14/15 for their feedback on the 
<draft-ietf-ccamp-transport-lmp-00.txt>. Please see the reply to the 
comments in the following text. 
> 
>We have several questions of clarification, e.g., in section 3.1
>(paragraph 2) of the I-D, "The separation between the two processes and 
>corresponding two name spaces has the advantage that the discovery of 
>the transport plane can be performed independent from that of the 
>control plane (and vice-versa), and independent of the method used in 
>each name space. This allows assigning link connections in the control 
>plane without the link connection being physically connected."
> 
>What is the intention of the term independent, for example, could it be
>indicating at a different time or different approaches? In the last 
>sentence, is "assign" used in the context of the management plane, 
>meaning management plane provisioning? Is it assumed that the 
>transport plane resources supporting the link connection endpoints 
>exist or do not exist? In section 4.2 (paragraph 2) of the I-D, "G.8080 
>refers to a component link as a variable adaptation function i.e. a 
>single server layer trail dynamically supporting different multiplexing
>structures." This could be interpreted as indicating G.8080
>defines the term "component link". G.8080 does not use this
>term. Some clarification would be beneficial. 

As this section indicates, it is summarizing G.8080 Discovery (not LMP). The
description is directly based on G8080's text,
e.g.:

 " This separation allows control plane names to be completely 
  separate from transport plane names, and completely independent 
  of the method used to populate the DAs with those transport names."

 "In order to assign an SNP-SNP link connection to an SNPP link, it 
  is only necessary for the transport name for the link connection to 
  exist. Thus, it is possible to assign link connections to the control 
  plane without the link connection being physically connected . "

The authors will clarify for these paragraphs that we are quoting from 
G8080 (not describing LMP).

 "G8080 refers to a component link as a variable adaptation function" 
  was worded from an IETF terminology interpretation i.e. G8080 refers 
  to a LMP component link as a variable adaptation function. The authors 
  will clarify to say "G8080's variable adaptation function is broadly 
  equivalent to LMP's component link."

> 
>Initial reviews of the draft document have raised concerns about the
>possible misinterpretation in the usage of the term 'TE link'. As the 
>draft notes, the definition of a TE link is concise. Some more clarity 
>would be appreciated. Our current understanding of this term includes 
>the following: A TE link may be composed of resource from multiple 
>(G.805) layers in parallel. If so, this is an important distinction as 
>an SNPP link is in a single layer only. An SNPP link may contain SNP
>link connections from various links (e.g., different STS-1s from
>a set of parallel OC-48 trails). It is not clear if this is
>also true for TE links. We think it may, but it is not stated.
>SNPPs exist at different routing levels (not layers) and thus an
>SNPP link at a higher level can encompass SNPPs at a lower level
>(see Section 6.2.2 of G.8080 Amendment 2, which is attached for
>your convenience). We think TE links may do this with bundles
>and FAs, but the definition is not clear to us. 
> 
>Please advise if this is a correct understanding or not. This may have
>an impact on the terminology mapping in the draft. We think it would 
>be beneficial to have a TE link definition that enables these 
>distinctions to be understood.

The intention of the draft is not to define a TE link. The TE link is 
defined in the LMP draft. <draft-ietf-ccamp-lmp-10.txt> At the request 
of several individuals we tried to bring clarity to the TE link concept. The
IETF definition of the TE link describes the way that resources are 
grouped and mapped for the purpose of path computation. Constraints on 
the physical resources define what is possible rather than any elaborate 
structures in the TE link. Therefore an SNPP link could easily be mapped 
to a TE link. There is a separation between the constraints of the 
physical resources and the information aggregation of TE link. Bundling is a
mechanism to efficiently aggregate TE resources within 
the constraints of the physical technology. 

"An LSP created across an LSP region see 
<draft-ietf-mpls-lsp-hierarchy-08.txt> in the network may be inherited 
as a TE link by an upper region and so appear as TE resources 
(as any other TE link). Such a TE link is referred to as a Forwarding 
Adjacency."

A TE link may contain STS-1s from parallel OC-48 trails. 

The authors will add text to clarify. 
> 
>In the table in section 4.2 "CP" is mapped to "Interface". A
>Connection Point is more closely related to a timeslot, wavelength, 
>etc. rather than to an entire interface. Similarly "CP Name" is mapped 
>to "Interface ID" while it might more closely relate to a "Label".

LMP distinguishes data links depending on the multiplexing capability 
of the endpoint on that link: "ports" are non multiplexing capable 
versus "component links" which are multiplexing capable. Following 
this reasoning, the data link for SDH/SONET networks is not the 
"timeslot" (this is the label) but the SDH/SONET section on which 
the timeslot (i.e. label) gets allocated.

A Connection Point (CP) most closely maps to an interface in terms 
of the IETF definitions. 

>Joint discussion of the terminology mapping may be beneficial in
>reaching alignment on the most accurate mapping. As noted above, these 
>represent several of the comments discussed. In order to progress our 
>mutual understanding, we would like to invite IETF participants to 
>attend the January 24-28, 2005 Q14/15 interim meeting, in New Jersey, 
>USA, where we could devote a session to terminology alignment. We 
>believe this effort will greatly benefit our future collaboration on 
>control plane standards development.  We welcome IETF experts' 
>participation in other sessions of the interim meeting as well.
>Details of the meeting agenda will be provided prior to the meeting.  
>For those interested in further information and/or attending the 
>interim meeting should contact the Rapporteur for Q.14/15 (H. Kam Lam,
>[e-mail]) by 10th January 2005. 

This point is a separate point from the discussion of the specific draft.  
The Transport View of LMP has a fairly limited scope of discussing 
terminology.  Some of the Authors of the Transport View of LMP will 
attend the session on January 25th and 26th. 



------_=_NextPart_001_01C4F975.56ED63E9
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>Draft Response to Incoming liaison (2) from ITU-T SG15</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi</FONT>
</P>

<P><FONT SIZE=3D2>The Authors of the CCAMP draft &quot;A Transport =
Network View of the Link Management Protocol&quot; have prepared the =
following draft response to the Liaison from ITU SG15. The text is =
included below for WG comments. </FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Don Fedyk </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt;From: ITU-T SG15</FONT>
<BR><FONT SIZE=3D2>&gt;To: CCAMP</FONT>
<BR><FONT SIZE=3D2>&gt;For: Action </FONT>
<BR><FONT SIZE=3D2>&gt;Deadline: 15 March 2005 </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: Response to IETF CCAMP WG on Comparison =
of LMP and ASON </FONT>
<BR><FONT SIZE=3D2>&gt;Discovery</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Q14/15 thanks the IETF CCAMP WG for providing us =
the draft document</FONT>
<BR><FONT SIZE=3D2>&gt;&lt;draft-ietf-ccamp-transport-lmp-00.txt&gt;. =
This I-D was discussed at the </FONT>
<BR><FONT SIZE=3D2>&gt;meeting and several of the comments are provided =
below. Based upon </FONT>
<BR><FONT SIZE=3D2>&gt;this discussion we believe it would be highly =
beneficial to have some </FONT>
<BR><FONT SIZE=3D2>&gt;joint discussions on terminology to ensure an =
aligned view to </FONT>
<BR><FONT SIZE=3D2>&gt;facilitate our future work efforts.</FONT>
</P>

<P><FONT SIZE=3D2>IETF CCAMP thanks the Q14/15 for their feedback on =
the </FONT>
<BR><FONT SIZE=3D2>&lt;draft-ietf-ccamp-transport-lmp-00.txt&gt;. =
Please see the reply to the </FONT>
<BR><FONT SIZE=3D2>comments in the following text. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;We have several questions of clarification, =
e.g., in section 3.1</FONT>
<BR><FONT SIZE=3D2>&gt;(paragraph 2) of the I-D, &quot;The separation =
between the two processes and </FONT>
<BR><FONT SIZE=3D2>&gt;corresponding two name spaces has the advantage =
that the discovery of </FONT>
<BR><FONT SIZE=3D2>&gt;the transport plane can be performed independent =
from that of the </FONT>
<BR><FONT SIZE=3D2>&gt;control plane (and vice-versa), and independent =
of the method used in </FONT>
<BR><FONT SIZE=3D2>&gt;each name space. This allows assigning link =
connections in the control </FONT>
<BR><FONT SIZE=3D2>&gt;plane without the link connection being =
physically connected.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;What is the intention of the term independent, =
for example, could it be</FONT>
<BR><FONT SIZE=3D2>&gt;indicating at a different time or different =
approaches? In the last </FONT>
<BR><FONT SIZE=3D2>&gt;sentence, is &quot;assign&quot; used in the =
context of the management plane, </FONT>
<BR><FONT SIZE=3D2>&gt;meaning management plane provisioning? Is it =
assumed that the </FONT>
<BR><FONT SIZE=3D2>&gt;transport plane resources supporting the link =
connection endpoints </FONT>
<BR><FONT SIZE=3D2>&gt;exist or do not exist? In section 4.2 (paragraph =
2) of the I-D, &quot;G.8080 </FONT>
<BR><FONT SIZE=3D2>&gt;refers to a component link as a variable =
adaptation function i.e. a </FONT>
<BR><FONT SIZE=3D2>&gt;single server layer trail dynamically supporting =
different multiplexing</FONT>
<BR><FONT SIZE=3D2>&gt;structures.&quot; This could be interpreted as =
indicating G.8080</FONT>
<BR><FONT SIZE=3D2>&gt;defines the term &quot;component link&quot;. =
G.8080 does not use this</FONT>
<BR><FONT SIZE=3D2>&gt;term. Some clarification would be beneficial. =
</FONT>
</P>

<P><FONT SIZE=3D2>As this section indicates, it is summarizing G.8080 =
Discovery (not LMP). The description is directly based on G8080's text,<=
/FONT></P>

<P><FONT SIZE=3D2>e.g.:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&quot; This separation allows control plane =
names to be completely </FONT>
<BR><FONT SIZE=3D2>&nbsp; separate from transport plane names, and =
completely independent </FONT>
<BR><FONT SIZE=3D2>&nbsp; of the method used to populate the DAs with =
those transport names.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&quot;In order to assign an SNP-SNP link =
connection to an SNPP link, it </FONT>
<BR><FONT SIZE=3D2>&nbsp; is only necessary for the transport name for =
the link connection to </FONT>
<BR><FONT SIZE=3D2>&nbsp; exist. Thus, it is possible to assign link =
connections to the control </FONT>
<BR><FONT SIZE=3D2>&nbsp; plane without the link connection being =
physically connected . &quot;</FONT>
</P>

<P><FONT SIZE=3D2>The authors will clarify for these paragraphs that we =
are quoting from </FONT>
<BR><FONT SIZE=3D2>G8080 (not describing LMP).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&quot;G8080 refers to a component link as a =
variable adaptation function&quot; </FONT>
<BR><FONT SIZE=3D2>&nbsp; was worded from an IETF terminology =
interpretation i.e. G8080 refers </FONT>
<BR><FONT SIZE=3D2>&nbsp; to a LMP component link as a variable =
adaptation function. The authors </FONT>
<BR><FONT SIZE=3D2>&nbsp; will clarify to say &quot;G8080's variable =
adaptation function is broadly </FONT>
<BR><FONT SIZE=3D2>&nbsp; equivalent to LMP's component =
link.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Initial reviews of the draft document have =
raised concerns about the</FONT>
<BR><FONT SIZE=3D2>&gt;possible misinterpretation in the usage of the =
term 'TE link'. As the </FONT>
<BR><FONT SIZE=3D2>&gt;draft notes, the definition of a TE link is =
concise. Some more clarity </FONT>
<BR><FONT SIZE=3D2>&gt;would be appreciated. Our current understanding =
of this term includes </FONT>
<BR><FONT SIZE=3D2>&gt;the following: A TE link may be composed of =
resource from multiple </FONT>
<BR><FONT SIZE=3D2>&gt;(G.805) layers in parallel. If so, this is an =
important distinction as </FONT>
<BR><FONT SIZE=3D2>&gt;an SNPP link is in a single layer only. An SNPP =
link may contain SNP</FONT>
<BR><FONT SIZE=3D2>&gt;link connections from various links (e.g., =
different STS-1s from</FONT>
<BR><FONT SIZE=3D2>&gt;a set of parallel OC-48 trails). It is not clear =
if this is</FONT>
<BR><FONT SIZE=3D2>&gt;also true for TE links. We think it may, but it =
is not stated.</FONT>
<BR><FONT SIZE=3D2>&gt;SNPPs exist at different routing levels (not =
layers) and thus an</FONT>
<BR><FONT SIZE=3D2>&gt;SNPP link at a higher level can encompass SNPPs =
at a lower level</FONT>
<BR><FONT SIZE=3D2>&gt;(see Section 6.2.2 of G.8080 Amendment 2, which =
is attached for</FONT>
<BR><FONT SIZE=3D2>&gt;your convenience). We think TE links may do this =
with bundles</FONT>
<BR><FONT SIZE=3D2>&gt;and FAs, but the definition is not clear to us. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;Please advise if this is a correct understanding =
or not. This may have</FONT>
<BR><FONT SIZE=3D2>&gt;an impact on the terminology mapping in the =
draft. We think it would </FONT>
<BR><FONT SIZE=3D2>&gt;be beneficial to have a TE link definition that =
enables these </FONT>
<BR><FONT SIZE=3D2>&gt;distinctions to be understood.</FONT>
</P>

<P><FONT SIZE=3D2>The intention of the draft is not to define a TE =
link. The TE link is </FONT>
<BR><FONT SIZE=3D2>defined in the LMP draft. =
&lt;draft-ietf-ccamp-lmp-10.txt&gt; At the request </FONT>
<BR><FONT SIZE=3D2>of several individuals we tried to bring clarity to =
the TE link concept. The IETF definition of the TE link describes the =
way that resources are </FONT></P>

<P><FONT SIZE=3D2>grouped and mapped for the purpose of path =
computation. Constraints on </FONT>
<BR><FONT SIZE=3D2>the physical resources define what is possible =
rather than any elaborate </FONT>
<BR><FONT SIZE=3D2>structures in the TE link. Therefore an SNPP link =
could easily be mapped </FONT>
<BR><FONT SIZE=3D2>to a TE link. There is a separation between the =
constraints of the </FONT>
<BR><FONT SIZE=3D2>physical resources and the information aggregation =
of TE link. Bundling is a mechanism to efficiently aggregate TE =
resources within </FONT></P>

<P><FONT SIZE=3D2>the constraints of the physical technology. </FONT>
</P>

<P><FONT SIZE=3D2>&quot;An LSP created across an LSP region see </FONT>
<BR><FONT SIZE=3D2>&lt;draft-ietf-mpls-lsp-hierarchy-08.txt&gt; in the =
network may be inherited </FONT>
<BR><FONT SIZE=3D2>as a TE link by an upper region and so appear as TE =
resources </FONT>
<BR><FONT SIZE=3D2>(as any other TE link). Such a TE link is referred =
to as a Forwarding </FONT>
<BR><FONT SIZE=3D2>Adjacency.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>A TE link may contain STS-1s from parallel OC-48 =
trails. </FONT>
</P>

<P><FONT SIZE=3D2>The authors will add text to clarify. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;In the table in section 4.2 &quot;CP&quot; is =
mapped to &quot;Interface&quot;. A</FONT>
<BR><FONT SIZE=3D2>&gt;Connection Point is more closely related to a =
timeslot, wavelength, </FONT>
<BR><FONT SIZE=3D2>&gt;etc. rather than to an entire interface. =
Similarly &quot;CP Name&quot; is mapped </FONT>
<BR><FONT SIZE=3D2>&gt;to &quot;Interface ID&quot; while it might more =
closely relate to a &quot;Label&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>LMP distinguishes data links depending on the =
multiplexing capability </FONT>
<BR><FONT SIZE=3D2>of the endpoint on that link: &quot;ports&quot; are =
non multiplexing capable </FONT>
<BR><FONT SIZE=3D2>versus &quot;component links&quot; which are =
multiplexing capable. Following </FONT>
<BR><FONT SIZE=3D2>this reasoning, the data link for SDH/SONET networks =
is not the </FONT>
<BR><FONT SIZE=3D2>&quot;timeslot&quot; (this is the label) but the =
SDH/SONET section on which </FONT>
<BR><FONT SIZE=3D2>the timeslot (i.e. label) gets allocated.</FONT>
</P>

<P><FONT SIZE=3D2>A Connection Point (CP) most closely maps to an =
interface in terms </FONT>
<BR><FONT SIZE=3D2>of the IETF definitions. </FONT>
</P>

<P><FONT SIZE=3D2>&gt;Joint discussion of the terminology mapping may =
be beneficial in</FONT>
<BR><FONT SIZE=3D2>&gt;reaching alignment on the most accurate mapping. =
As noted above, these </FONT>
<BR><FONT SIZE=3D2>&gt;represent several of the comments discussed. In =
order to progress our </FONT>
<BR><FONT SIZE=3D2>&gt;mutual understanding, we would like to invite =
IETF participants to </FONT>
<BR><FONT SIZE=3D2>&gt;attend the January 24-28, 2005 Q14/15 interim =
meeting, in New Jersey, </FONT>
<BR><FONT SIZE=3D2>&gt;USA, where we could devote a session to =
terminology alignment. We </FONT>
<BR><FONT SIZE=3D2>&gt;believe this effort will greatly benefit our =
future collaboration on </FONT>
<BR><FONT SIZE=3D2>&gt;control plane standards development.&nbsp; We =
welcome IETF experts' </FONT>
<BR><FONT SIZE=3D2>&gt;participation in other sessions of the interim =
meeting as well.</FONT>
<BR><FONT SIZE=3D2>&gt;Details of the meeting agenda will be provided =
prior to the meeting.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;For those interested in further information =
and/or attending the </FONT>
<BR><FONT SIZE=3D2>&gt;interim meeting should contact the Rapporteur =
for Q.14/15 (H. Kam Lam,</FONT>
<BR><FONT SIZE=3D2>&gt;[e-mail]) by 10th January 2005. </FONT>
</P>

<P><FONT SIZE=3D2>This point is a separate point from the discussion of =
the specific draft.&nbsp; </FONT>
<BR><FONT SIZE=3D2>The Transport View of LMP has a fairly limited scope =
of discussing </FONT>
<BR><FONT SIZE=3D2>terminology.&nbsp; Some of the Authors of the =
Transport View of LMP will </FONT>
<BR><FONT SIZE=3D2>attend the session on January 25th and 26th. </FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C4F975.56ED63E9--



Envelope-to: [e-mail]
Delivery-date: Thu, 13 Jan 2005 12:01:06 +0000
Message-ID: <02bb01c4f967$2b573620$b4cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Fw: WG Last Call for "Extensions to OSPF for Advertising Optional Router"
Date: Thu, 13 Jan 2005 10:50:24 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

This draft has some interest to CCAMP.
Please send any comments to the OSPF list or to Acee himself.

Adrian

----- Original Message ----- 
From: "Acee Lindem" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, January 08, 2005 3:31 AM
Subject: WG Last Call for "Extensions to OSPF for Advertising Optional
Router"


> This the start of  the  Working Group Last Call for "Extensions to OSPF
for
> Advertising Optional Router" - draft-ietf-ospf-cap-05.txt.
> All comments must be sent to the OSPF list by 12:00 AM EST on Monday,
> January 24, 2005.
>
>
> A URL for this Internet-draft is provided below:
>
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt
>
> Thanks,
> Acee
>
>




Envelope-to: [e-mail]
Delivery-date: Wed, 12 Jan 2005 23:35:38 +0000
Mime-Version: 1.0 (Apple Message framework v619)
To: Mailing List <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: JP Vasseur <[e-mail]>
Date: Wed, 12 Jan 2005 18:14:19 -0500
Cc: 
Subject: [mpls] Fwd: WG Action: Path Computation Element (pce)
Content-Type: multipart/mixed; boundary="===============0288458767=="

--===============0288458767==
Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577


--Apple-Mail-42-562924577
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

FYI,

JP.

Begin forwarded message:

> From: The IESG <[e-mail]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [e-mail]
> Cc: [e-mail], Adrian Farrel <[e-mail]>, JP Vasseur 
> <[e-mail]>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <[e-mail]>
> JP Vasseur <[e-mail]>
>
> Routing Area Director(s):
> Bill Fenner <[e-mail]>
> Alex Zinin <[e-mail]>
>
> Routing Area Advisor:
> Alex Zinin <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: [e-mail]
> In Body: subscribe pce
> Archive: http://www.ietf.org/mail-archive/web/pce/
>
> Description of Working Group:
>
> The PCE Working Group is chartered to specify a Path Computation 
> Element (PCE)
> based architecture for the computation of paths for MPLS and GMPLS 
> Traffic
> Engineering LSPs.
>
> In this architecture path computation does not occur on the head-end 
> (ingress)
> LSR, but on some other path computation entity that may physically not 
> be
> located on the head-end LSR.
>
> The PCE WG will work on application of this model within a single 
> domain
> or within a small group of domains (where a domain is a layer, IGP area
> or Autonomous System with limited visibility from the head-end LSR).
> At this time, applying this model to large groups of domains such as 
> the
> Internet is not thought to be possible, and the PCE WG will not spend
> energy on that topic.
>
> The WG will specify a protocol for communication between LSRs (termed 
> Path
> Computation Clients - PCCs) and PCEs, and between cooperating PCEs. 
> This
> protocol will be capable of representing requests for path computation
> including a full set of constraints, will be able to return multiple 
> paths, and
> will include security mechanisms such as authentication and 
> confidentiality.
>
> The WG will determine requirements for extensions to existing routing 
> and
> signaling protocols in support of PCE discovery and signaling of 
> inter-domain
> paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, 
> ISIS-TE and
> BGP. Any necessary extensions will be produced in collaboration with 
> the
> Working Groups responsible for the protocols.
>
> The Working Group will also work on the definition of metrics to
> evaluate path quality, scalability, responsiveness and robustness of
> path computation models.
>
> Work Items:
>
> - Functional specification of MPLS and GMPLS Traffic Engineered LSP 
> path
> computation models involving Path Computation Element(s). This
> includes the case of computing the paths of intra and inter-domain
> TE LSPs. Such path computation includes the generation of primary,
> protection and recovery paths, as well as computations for 
> (local/global)
> reoptimization and load balancing. The WG will address the inter-area
> (single IGP domain) scenario first. WG progress will be evaluated 
> before
> inter-AS related work is started.
>
> - Specification of the PCE-based architecture.
>
> - Specification of requirements and protocol extensions related to
> the policy, and security aspects of PCE-based path computation 
> involving
> PCEs of multiple administrative entities.
>
> - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
> MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> signaling (RSVP-TE) extensions required to support PCE-based path
> computation models.
>
> - Specification of techniques in support of PCE discovery within and
> across domains. Where such techniques result in the extensions of
> existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in
> conjunction with the appropriate WGs.
>
> - Specification of a new communication protocol for use between a PCC
> and a PCE, and between PCEs. A single protocol will be selected from
> among candidates that include the existing protocols defined in other
> WGs.
>
> - Definition of objective metrics to evaluate various criteria such as
> the measurement of path quality, response time, robustness and
> scalability of path computation models.
>
> Review of the document "Requirements for path computation element in
> GMPLS inter-domain networks" produced by the CCAMP WG.
>
>
> Goals and Milestones:
>
> Feb 05: Submit first draft of PCE architecture document
>
> Feb 05: Submit first draft of PCE discovery requirements and protocol
> extensions documents
>
> Apr 05: Submit first draft of the PCE communication protocol
> requirements
>
> May 05: Submit first draft of the definition of objective metrics
>
> Jul 05: Submit first draft of the PCE communication protocol
> specification
>
> Aug 05: Submit PCE architecture specification to the IESG to be
> considered as Informational RFC
>
> Nov 05: Submit first draft of applicability statement (describing the 
> processes
> and procedures for the use of the PCE architecture, protocols
> and protocol extensions for inter-area MPLS and GMPLS Traffic
> Engineering)
>
> Nov 05: Submit first draft of the MIB module for the PCE protocol
>
> Dec 05: Submit PCE communication protocol requirements to the IESG to 
> be
> considered as an Informational RFC
>
> Dec 05: Submit PCE discovery protocol extensions specifications to the
> IESG to be considered as a Proposed Standard
>
> Dec 05: Submit PCE communication protocol specification to the IESG to
> be considered as a Proposed Standard
>
> Feb 06: Submit the applicability and metrics documents to the IESG to 
> be
> considered as Informational RFC
>
> Feb 06: Evaluate WG progress, recharter or close.
>

--Apple-Mail-42-562924577
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI,


JP.


Begin forwarded message:


<excerpt><bold><fontfamily><param>Helvetica</param><color><param>0000,0000,0000</param>From:
</color></fontfamily></bold><fontfamily><param>Helvetica</param>The
IESG <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>January
12, 2005 3:39:31 PM EST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[e-mail]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[e-mail], Adrian Farrel <<[e-mail]>, JP
Vasseur <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Subject: </color>WG Action:
Path Computation Element (pce)

</bold></fontfamily>

A new IETF working group has been formed in the Routing Area. For
additional 

information, please contact the Area Directors or the WG Chairs.


Path Computation Element (pce)

================================


Current Status: Active Working Group


Chair(s):

Adrian Farrel <<[e-mail]>

JP Vasseur <<[e-mail]>


Routing Area Director(s):

Bill Fenner <<[e-mail]>

Alex Zinin <<[e-mail]>


Routing Area Advisor:

Alex Zinin <<[e-mail]>


Mailing Lists:

General Discussion: [e-mail]

To Subscribe: [e-mail]

In Body: subscribe pce

Archive: http://www.ietf.org/mail-archive/web/pce/


Description of Working Group:


The PCE Working Group is chartered to specify a Path Computation
Element (PCE)

based architecture for the computation of paths for MPLS and GMPLS
Traffic

Engineering LSPs.


In this architecture path computation does not occur on the head-end
(ingress)

LSR, but on some other path computation entity that may physically not
be

located on the head-end LSR.


The PCE WG will work on application of this model within a single
domain

or within a small group of domains (where a domain is a layer, IGP area

or Autonomous System with limited visibility from the head-end LSR).

At this time, applying this model to large groups of domains such as
the

Internet is not thought to be possible, and the PCE WG will not spend

energy on that topic.


The WG will specify a protocol for communication between LSRs (termed
Path

Computation Clients - PCCs) and PCEs, and between cooperating PCEs.
This

protocol will be capable of representing requests for path computation

including a full set of constraints, will be able to return multiple
paths, and

will include security mechanisms such as authentication and
confidentiality.


The WG will determine requirements for extensions to existing routing
and

signaling protocols in support of PCE discovery and signaling of
inter-domain

paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE,
ISIS-TE and

BGP. Any necessary extensions will be produced in collaboration with
the

Working Groups responsible for the protocols.


The Working Group will also work on the definition of metrics to

evaluate path quality, scalability, responsiveness and robustness of

path computation models.


Work Items:


- Functional specification of MPLS and GMPLS Traffic Engineered LSP
path

computation models involving Path Computation Element(s). This

includes the case of computing the paths of intra and inter-domain

TE LSPs. Such path computation includes the generation of primary,

protection and recovery paths, as well as computations for
(local/global)

reoptimization and load balancing. The WG will address the inter-area

(single IGP domain) scenario first. WG progress will be evaluated
before

inter-AS related work is started.


- Specification of the PCE-based architecture.


- Specification of requirements and protocol extensions related to

the policy, and security aspects of PCE-based path computation
involving

PCEs of multiple administrative entities.


- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,

MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP

signaling (RSVP-TE) extensions required to support PCE-based path

computation models.


- Specification of techniques in support of PCE discovery within and

across domains. Where such techniques result in the extensions of

existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in

conjunction with the appropriate WGs.


- Specification of a new communication protocol for use between a PCC

and a PCE, and between PCEs. A single protocol will be selected from

among candidates that include the existing protocols defined in other

WGs.


- Definition of objective metrics to evaluate various criteria such as

the measurement of path quality, response time, robustness and

scalability of path computation models.


Review of the document "Requirements for path computation element in

GMPLS inter-domain networks" produced by the CCAMP WG.



Goals and Milestones:


Feb 05: Submit first draft of PCE architecture document


Feb 05: Submit first draft of PCE discovery requirements and protocol

extensions documents


Apr 05: Submit first draft of the PCE communication protocol

requirements


May 05: Submit first draft of the definition of objective metrics


Jul 05: Submit first draft of the PCE communication protocol

specification


Aug 05: Submit PCE architecture specification to the IESG to be

considered as Informational RFC


Nov 05: Submit first draft of applicability statement (describing the
processes

and procedures for the use of the PCE architecture, protocols

and protocol extensions for inter-area MPLS and GMPLS Traffic

Engineering)


Nov 05: Submit first draft of the MIB module for the PCE protocol


Dec 05: Submit PCE communication protocol requirements to the IESG to
be

considered as an Informational RFC


Dec 05: Submit PCE discovery protocol extensions specifications to the

IESG to be considered as a Proposed Standard


Dec 05: Submit PCE communication protocol specification to the IESG to

be considered as a Proposed Standard


Feb 06: Submit the applicability and metrics documents to the IESG to
be

considered as Informational RFC


Feb 06: Evaluate WG progress, recharter or close.


</excerpt>
--Apple-Mail-42-562924577--


--===============0288458767==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0288458767==--




Envelope-to: [e-mail]
Delivery-date: Wed, 12 Jan 2005 23:35:20 +0000
Mime-Version: 1.0 (Apple Message framework v619)
To: Mailing List <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
From: JP Vasseur <[e-mail]>
Date: Wed, 12 Jan 2005 18:14:19 -0500
Cc: 
Subject: [mpls] Fwd: WG Action: Path Computation Element (pce)
Content-Type: multipart/mixed; boundary="===============0288458767=="

--===============0288458767==
Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577


--Apple-Mail-42-562924577
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

FYI,

JP.

Begin forwarded message:

> From: The IESG <[e-mail]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [e-mail]
> Cc: [e-mail], Adrian Farrel <[e-mail]>, JP Vasseur 
> <[e-mail]>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <[e-mail]>
> JP Vasseur <[e-mail]>
>
> Routing Area Director(s):
> Bill Fenner <[e-mail]>
> Alex Zinin <[e-mail]>
>
> Routing Area Advisor:
> Alex Zinin <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: [e-mail]
> In Body: subscribe pce
> Archive: http://www.ietf.org/mail-archive/web/pce/
>
> Description of Working Group:
>
> The PCE Working Group is chartered to specify a Path Computation 
> Element (PCE)
> based architecture for the computation of paths for MPLS and GMPLS 
> Traffic
> Engineering LSPs.
>
> In this architecture path computation does not occur on the head-end 
> (ingress)
> LSR, but on some other path computation entity that may physically not 
> be
> located on the head-end LSR.
>
> The PCE WG will work on application of this model within a single 
> domain
> or within a small group of domains (where a domain is a layer, IGP area
> or Autonomous System with limited visibility from the head-end LSR).
> At this time, applying this model to large groups of domains such as 
> the
> Internet is not thought to be possible, and the PCE WG will not spend
> energy on that topic.
>
> The WG will specify a protocol for communication between LSRs (termed 
> Path
> Computation Clients - PCCs) and PCEs, and between cooperating PCEs. 
> This
> protocol will be capable of representing requests for path computation
> including a full set of constraints, will be able to return multiple 
> paths, and
> will include security mechanisms such as authentication and 
> confidentiality.
>
> The WG will determine requirements for extensions to existing routing 
> and
> signaling protocols in support of PCE discovery and signaling of 
> inter-domain
> paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, 
> ISIS-TE and
> BGP. Any necessary extensions will be produced in collaboration with 
> the
> Working Groups responsible for the protocols.
>
> The Working Group will also work on the definition of metrics to
> evaluate path quality, scalability, responsiveness and robustness of
> path computation models.
>
> Work Items:
>
> - Functional specification of MPLS and GMPLS Traffic Engineered LSP 
> path
> computation models involving Path Computation Element(s). This
> includes the case of computing the paths of intra and inter-domain
> TE LSPs. Such path computation includes the generation of primary,
> protection and recovery paths, as well as computations for 
> (local/global)
> reoptimization and load balancing. The WG will address the inter-area
> (single IGP domain) scenario first. WG progress will be evaluated 
> before
> inter-AS related work is started.
>
> - Specification of the PCE-based architecture.
>
> - Specification of requirements and protocol extensions related to
> the policy, and security aspects of PCE-based path computation 
> involving
> PCEs of multiple administrative entities.
>
> - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
> MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> signaling (RSVP-TE) extensions required to support PCE-based path
> computation models.
>
> - Specification of techniques in support of PCE discovery within and
> across domains. Where such techniques result in the extensions of
> existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in
> conjunction with the appropriate WGs.
>
> - Specification of a new communication protocol for use between a PCC
> and a PCE, and between PCEs. A single protocol will be selected from
> among candidates that include the existing protocols defined in other
> WGs.
>
> - Definition of objective metrics to evaluate various criteria such as
> the measurement of path quality, response time, robustness and
> scalability of path computation models.
>
> Review of the document "Requirements for path computation element in
> GMPLS inter-domain networks" produced by the CCAMP WG.
>
>
> Goals and Milestones:
>
> Feb 05: Submit first draft of PCE architecture document
>
> Feb 05: Submit first draft of PCE discovery requirements and protocol
> extensions documents
>
> Apr 05: Submit first draft of the PCE communication protocol
> requirements
>
> May 05: Submit first draft of the definition of objective metrics
>
> Jul 05: Submit first draft of the PCE communication protocol
> specification
>
> Aug 05: Submit PCE architecture specification to the IESG to be
> considered as Informational RFC
>
> Nov 05: Submit first draft of applicability statement (describing the 
> processes
> and procedures for the use of the PCE architecture, protocols
> and protocol extensions for inter-area MPLS and GMPLS Traffic
> Engineering)
>
> Nov 05: Submit first draft of the MIB module for the PCE protocol
>
> Dec 05: Submit PCE communication protocol requirements to the IESG to 
> be
> considered as an Informational RFC
>
> Dec 05: Submit PCE discovery protocol extensions specifications to the
> IESG to be considered as a Proposed Standard
>
> Dec 05: Submit PCE communication protocol specification to the IESG to
> be considered as a Proposed Standard
>
> Feb 06: Submit the applicability and metrics documents to the IESG to 
> be
> considered as Informational RFC
>
> Feb 06: Evaluate WG progress, recharter or close.
>

--Apple-Mail-42-562924577
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

FYI,


JP.


Begin forwarded message:


<excerpt><bold><fontfamily><param>Helvetica</param><color><param>0000,0000,0000</param>From:
</color></fontfamily></bold><fontfamily><param>Helvetica</param>The
IESG <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>January
12, 2005 3:39:31 PM EST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[e-mail]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[e-mail], Adrian Farrel <<[e-mail]>, JP
Vasseur <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Subject: </color>WG Action:
Path Computation Element (pce)

</bold></fontfamily>

A new IETF working group has been formed in the Routing Area. For
additional 

information, please contact the Area Directors or the WG Chairs.


Path Computation Element (pce)

================================


Current Status: Active Working Group


Chair(s):

Adrian Farrel <<[e-mail]>

JP Vasseur <<[e-mail]>


Routing Area Director(s):

Bill Fenner <<[e-mail]>

Alex Zinin <<[e-mail]>


Routing Area Advisor:

Alex Zinin <<[e-mail]>


Mailing Lists:

General Discussion: [e-mail]

To Subscribe: [e-mail]

In Body: subscribe pce

Archive: http://www.ietf.org/mail-archive/web/pce/


Description of Working Group:


The PCE Working Group is chartered to specify a Path Computation
Element (PCE)

based architecture for the computation of paths for MPLS and GMPLS
Traffic

Engineering LSPs.


In this architecture path computation does not occur on the head-end
(ingress)

LSR, but on some other path computation entity that may physically not
be

located on the head-end LSR.


The PCE WG will work on application of this model within a single
domain

or within a small group of domains (where a domain is a layer, IGP area

or Autonomous System with limited visibility from the head-end LSR).

At this time, applying this model to large groups of domains such as
the

Internet is not thought to be possible, and the PCE WG will not spend

energy on that topic.


The WG will specify a protocol for communication between LSRs (termed
Path

Computation Clients - PCCs) and PCEs, and between cooperating PCEs.
This

protocol will be capable of representing requests for path computation

including a full set of constraints, will be able to return multiple
paths, and

will include security mechanisms such as authentication and
confidentiality.


The WG will determine requirements for extensions to existing routing
and

signaling protocols in support of PCE discovery and signaling of
inter-domain

paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE,
ISIS-TE and

BGP. Any necessary extensions will be produced in collaboration with
the

Working Groups responsible for the protocols.


The Working Group will also work on the definition of metrics to

evaluate path quality, scalability, responsiveness and robustness of

path computation models.


Work Items:


- Functional specification of MPLS and GMPLS Traffic Engineered LSP
path

computation models involving Path Computation Element(s). This

includes the case of computing the paths of intra and inter-domain

TE LSPs. Such path computation includes the generation of primary,

protection and recovery paths, as well as computations for
(local/global)

reoptimization and load balancing. The WG will address the inter-area

(single IGP domain) scenario first. WG progress will be evaluated
before

inter-AS related work is started.


- Specification of the PCE-based architecture.


- Specification of requirements and protocol extensions related to

the policy, and security aspects of PCE-based path computation
involving

PCEs of multiple administrative entities.


- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,

MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP

signaling (RSVP-TE) extensions required to support PCE-based path

computation models.


- Specification of techniques in support of PCE discovery within and

across domains. Where such techniques result in the extensions of

existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in

conjunction with the appropriate WGs.


- Specification of a new communication protocol for use between a PCC

and a PCE, and between PCEs. A single protocol will be selected from

among candidates that include the existing protocols defined in other

WGs.


- Definition of objective metrics to evaluate various criteria such as

the measurement of path quality, response time, robustness and

scalability of path computation models.


Review of the document "Requirements for path computation element in

GMPLS inter-domain networks" produced by the CCAMP WG.



Goals and Milestones:


Feb 05: Submit first draft of PCE architecture document


Feb 05: Submit first draft of PCE discovery requirements and protocol

extensions documents


Apr 05: Submit first draft of the PCE communication protocol

requirements


May 05: Submit first draft of the definition of objective metrics


Jul 05: Submit first draft of the PCE communication protocol

specification


Aug 05: Submit PCE architecture specification to the IESG to be

considered as Informational RFC


Nov 05: Submit first draft of applicability statement (describing the
processes

and procedures for the use of the PCE architecture, protocols

and protocol extensions for inter-area MPLS and GMPLS Traffic

Engineering)


Nov 05: Submit first draft of the MIB module for the PCE protocol


Dec 05: Submit PCE communication protocol requirements to the IESG to
be

considered as an Informational RFC


Dec 05: Submit PCE discovery protocol extensions specifications to the

IESG to be considered as a Proposed Standard


Dec 05: Submit PCE communication protocol specification to the IESG to

be considered as a Proposed Standard


Feb 06: Submit the applicability and metrics documents to the IESG to
be

considered as Informational RFC


Feb 06: Evaluate WG progress, recharter or close.


</excerpt>
--Apple-Mail-42-562924577--


--===============0288458767==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
mpls mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0288458767==--




Envelope-to: [e-mail]
Delivery-date: Wed, 12 Jan 2005 23:16:09 +0000
Mime-Version: 1.0 (Apple Message framework v619)
To: Mailing List <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
Content-Type: multipart/alternative; boundary=Apple-Mail-42-562924577
From: JP Vasseur <[e-mail]>
Subject: Fwd: WG Action: Path Computation Element (pce)
Date: Wed, 12 Jan 2005 18:14:19 -0500

--Apple-Mail-42-562924577
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

FYI,

JP.

Begin forwarded message:

> From: The IESG <[e-mail]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [e-mail]
> Cc: [e-mail], Adrian Farrel <[e-mail]>, JP Vasseur 
> <[e-mail]>
> Subject: WG Action: Path Computation Element (pce)
>
> A new IETF working group has been formed in the Routing Area. For 
> additional
> information, please contact the Area Directors or the WG Chairs.
>
> Path Computation Element (pce)
> ================================
>
> Current Status: Active Working Group
>
> Chair(s):
> Adrian Farrel <[e-mail]>
> JP Vasseur <[e-mail]>
>
> Routing Area Director(s):
> Bill Fenner <[e-mail]>
> Alex Zinin <[e-mail]>
>
> Routing Area Advisor:
> Alex Zinin <[e-mail]>
>
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: [e-mail]
> In Body: subscribe pce
> Archive: http://www.ietf.org/mail-archive/web/pce/
>
> Description of Working Group:
>
> The PCE Working Group is chartered to specify a Path Computation 
> Element (PCE)
> based architecture for the computation of paths for MPLS and GMPLS 
> Traffic
> Engineering LSPs.
>
> In this architecture path computation does not occur on the head-end 
> (ingress)
> LSR, but on some other path computation entity that may physically not 
> be
> located on the head-end LSR.
>
> The PCE WG will work on application of this model within a single 
> domain
> or within a small group of domains (where a domain is a layer, IGP area
> or Autonomous System with limited visibility from the head-end LSR).
> At this time, applying this model to large groups of domains such as 
> the
> Internet is not thought to be possible, and the PCE WG will not spend
> energy on that topic.
>
> The WG will specify a protocol for communication between LSRs (termed 
> Path
> Computation Clients - PCCs) and PCEs, and between cooperating PCEs. 
> This
> protocol will be capable of representing requests for path computation
> including a full set of constraints, will be able to return multiple 
> paths, and
> will include security mechanisms such as authentication and 
> confidentiality.
>
> The WG will determine requirements for extensions to existing routing 
> and
> signaling protocols in support of PCE discovery and signaling of 
> inter-domain
> paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE, 
> ISIS-TE and
> BGP. Any necessary extensions will be produced in collaboration with 
> the
> Working Groups responsible for the protocols.
>
> The Working Group will also work on the definition of metrics to
> evaluate path quality, scalability, responsiveness and robustness of
> path computation models.
>
> Work Items:
>
> - Functional specification of MPLS and GMPLS Traffic Engineered LSP 
> path
> computation models involving Path Computation Element(s). This
> includes the case of computing the paths of intra and inter-domain
> TE LSPs. Such path computation includes the generation of primary,
> protection and recovery paths, as well as computations for 
> (local/global)
> reoptimization and load balancing. The WG will address the inter-area
> (single IGP domain) scenario first. WG progress will be evaluated 
> before
> inter-AS related work is started.
>
> - Specification of the PCE-based architecture.
>
> - Specification of requirements and protocol extensions related to
> the policy, and security aspects of PCE-based path computation 
> involving
> PCEs of multiple administrative entities.
>
> - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
> MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> signaling (RSVP-TE) extensions required to support PCE-based path
> computation models.
>
> - Specification of techniques in support of PCE discovery within and
> across domains. Where such techniques result in the extensions of
> existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in
> conjunction with the appropriate WGs.
>
> - Specification of a new communication protocol for use between a PCC
> and a PCE, and between PCEs. A single protocol will be selected from
> among candidates that include the existing protocols defined in other
> WGs.
>
> - Definition of objective metrics to evaluate various criteria such as
> the measurement of path quality, response time, robustness and
> scalability of path computation models.
>
> Review of the document "Requirements for path computation element in
> GMPLS inter-domain networks" produced by the CCAMP WG.
>
>
> Goals and Milestones:
>
> Feb 05: Submit first draft of PCE architecture document
>
> Feb 05: Submit first draft of PCE discovery requirements and protocol
> extensions documents
>
> Apr 05: Submit first draft of the PCE communication protocol
> requirements
>
> May 05: Submit first draft of the definition of objective metrics
>
> Jul 05: Submit first draft of the PCE communication protocol
> specification
>
> Aug 05: Submit PCE architecture specification to the IESG to be
> considered as Informational RFC
>
> Nov 05: Submit first draft of applicability statement (describing the 
> processes
> and procedures for the use of the PCE architecture, protocols
> and protocol extensions for inter-area MPLS and GMPLS Traffic
> Engineering)
>
> Nov 05: Submit first draft of the MIB module for the PCE protocol
>
> Dec 05: Submit PCE communication protocol requirements to the IESG to 
> be
> considered as an Informational RFC
>
> Dec 05: Submit PCE discovery protocol extensions specifications to the
> IESG to be considered as a Proposed Standard
>
> Dec 05: Submit PCE communication protocol specification to the IESG to
> be considered as a Proposed Standard
>
> Feb 06: Submit the applicability and metrics documents to the IESG to 
> be
> considered as Informational RFC
>
> Feb 06: Evaluate WG progress, recharter or close.
>

--Apple-Mail-42-562924577
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

FYI,


JP.


Begin forwarded message:


<excerpt><bold><fontfamily><param>Helvetica</param><color><param>0000,0000,0000</param>From:
</color></fontfamily></bold><fontfamily><param>Helvetica</param>The
IESG <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>January
12, 2005 3:39:31 PM EST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[e-mail]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[e-mail], Adrian Farrel <<[e-mail]>, JP
Vasseur <<[e-mail]>

<bold><color><param>0000,0000,0000</param>Subject: </color>WG Action:
Path Computation Element (pce)

</bold></fontfamily>

A new IETF working group has been formed in the Routing Area. For
additional 

information, please contact the Area Directors or the WG Chairs.


Path Computation Element (pce)

================================


Current Status: Active Working Group


Chair(s):

Adrian Farrel <<[e-mail]>

JP Vasseur <<[e-mail]>


Routing Area Director(s):

Bill Fenner <<[e-mail]>

Alex Zinin <<[e-mail]>


Routing Area Advisor:

Alex Zinin <<[e-mail]>


Mailing Lists:

General Discussion: [e-mail]

To Subscribe: [e-mail]

In Body: subscribe pce

Archive: http://www.ietf.org/mail-archive/web/pce/


Description of Working Group:


The PCE Working Group is chartered to specify a Path Computation
Element (PCE)

based architecture for the computation of paths for MPLS and GMPLS
Traffic

Engineering LSPs.


In this architecture path computation does not occur on the head-end
(ingress)

LSR, but on some other path computation entity that may physically not
be

located on the head-end LSR.


The PCE WG will work on application of this model within a single
domain

or within a small group of domains (where a domain is a layer, IGP area

or Autonomous System with limited visibility from the head-end LSR).

At this time, applying this model to large groups of domains such as
the

Internet is not thought to be possible, and the PCE WG will not spend

energy on that topic.


The WG will specify a protocol for communication between LSRs (termed
Path

Computation Clients - PCCs) and PCEs, and between cooperating PCEs.
This

protocol will be capable of representing requests for path computation

including a full set of constraints, will be able to return multiple
paths, and

will include security mechanisms such as authentication and
confidentiality.


The WG will determine requirements for extensions to existing routing
and

signaling protocols in support of PCE discovery and signaling of
inter-domain

paths. Candidate protocols for extensions are RSVP-TE, OSPF-TE,
ISIS-TE and

BGP. Any necessary extensions will be produced in collaboration with
the

Working Groups responsible for the protocols.


The Working Group will also work on the definition of metrics to

evaluate path quality, scalability, responsiveness and robustness of

path computation models.


Work Items:


- Functional specification of MPLS and GMPLS Traffic Engineered LSP
path

computation models involving Path Computation Element(s). This

includes the case of computing the paths of intra and inter-domain

TE LSPs. Such path computation includes the generation of primary,

protection and recovery paths, as well as computations for
(local/global)

reoptimization and load balancing. The WG will address the inter-area

(single IGP domain) scenario first. WG progress will be evaluated
before

inter-AS related work is started.


- Specification of the PCE-based architecture.


- Specification of requirements and protocol extensions related to

the policy, and security aspects of PCE-based path computation
involving

PCEs of multiple administrative entities.


- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,

MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP

signaling (RSVP-TE) extensions required to support PCE-based path

computation models.


- Specification of techniques in support of PCE discovery within and

across domains. Where such techniques result in the extensions of

existing protocols (e.g., OSPF, ISIS or BGP), this work will be done in

conjunction with the appropriate WGs.


- Specification of a new communication protocol for use between a PCC

and a PCE, and between PCEs. A single protocol will be selected from

among candidates that include the existing protocols defined in other

WGs.


- Definition of objective metrics to evaluate various criteria such as

the measurement of path quality, response time, robustness and

scalability of path computation models.


Review of the document "Requirements for path computation element in

GMPLS inter-domain networks" produced by the CCAMP WG.



Goals and Milestones:


Feb 05: Submit first draft of PCE architecture document


Feb 05: Submit first draft of PCE discovery requirements and protocol

extensions documents


Apr 05: Submit first draft of the PCE communication protocol

requirements


May 05: Submit first draft of the definition of objective metrics


Jul 05: Submit first draft of the PCE communication protocol

specification


Aug 05: Submit PCE architecture specification to the IESG to be

considered as Informational RFC


Nov 05: Submit first draft of applicability statement (describing the
processes

and procedures for the use of the PCE architecture, protocols

and protocol extensions for inter-area MPLS and GMPLS Traffic

Engineering)


Nov 05: Submit first draft of the MIB module for the PCE protocol


Dec 05: Submit PCE communication protocol requirements to the IESG to
be

considered as an Informational RFC


Dec 05: Submit PCE discovery protocol extensions specifications to the

IESG to be considered as a Proposed Standard


Dec 05: Submit PCE communication protocol specification to the IESG to

be considered as a Proposed Standard


Feb 06: Submit the applicability and metrics documents to the IESG to
be

considered as Informational RFC


Feb 06: Evaluate WG progress, recharter or close.


</excerpt>
--Apple-Mail-42-562924577--



Envelope-to: [e-mail]
Delivery-date: Tue, 11 Jan 2005 20:33:21 +0000
Message-ID: <017c01c4f81c$99f41720$b4cb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison received from ITU-T SG13 Question 12
Date: Tue, 11 Jan 2005 13:15:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI...
The original liaison can be found at http://www.olddog.co.uk/incoming.htm
====
Question(s): 12/13 Geneva, 7-17 December 2004
Ref. : TD 59 Rev.1 (GEN)
Source: ITU-T SG13 (Geneva, 7-17 December 2004)
Title: Reply to IETF CCAMP working group on RSVP modification

LIAISON STATEMENT

To: IETF CCAMP working group
Approval: Agreed to at the SG 13 meeting
For: Information
Deadline: None
Contact: Rao Cherukuri
Q.12/13 Rapporteur
Tel: [phone]
Email: [e-mail]

ITU-T SG 13 Question 12 wishes to thank the IETF CCAMP working group for
the informative
liaison on RFC 3936 "Procedures for Modifying the Resource reSerVation
Protocol (RSVP)".

Question 12/13 is the continuation of Q.5/17 (formerly in SG 17) on Frame
Relay. Recently the
ITU-T approved Recommendation X.84 Frame Relay Services over MPLS. We are
currently
working on Draft new ITU-T Recommendation X.84 Amendment 1, Control Plane
and PVC Status
Monitoring.

We wish to encourage further communication between our two groups. We
shall keep you
informed on the progress of our work and request you do the same in
return.




Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 23:51:56 +0000
Message-ID: <008501c4f44a$964e7d20$0301a8c0@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Last Call: 'Link Bundling in MPLS Traffic Engineering' to Proposed  Standard 
Date: Thu, 6 Jan 2005 23:48:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: "The IESG" <[e-mail]>
To: "IETF-Announce" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 06, 2005 8:39 PM
Subject: Last Call: 'Link Bundling in MPLS Traffic Engineering' to
Proposed Standard


> The IESG has received a request from the Multiprotocol Label Switching
WG to
> consider the following document:
>
> - 'Link Bundling in MPLS Traffic Engineering '
>    <draft-ietf-mpls-bundle-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [e-mail] or [e-mail] mailing lists by 2005-01-20.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-06.txt
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 20:04:24 +0000
Message-ID: <[e-mail]>
Date: Thu, 06 Jan 2005 18:03:00 -0200
From: Daniela Cunha <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To:  [e-mail]
Subject: Label set model
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi all,
Is there any place I can find a label set modelling or mathematical 
model or blocking probabilty (performance analysis, or evaluation)? I 
mean, a way to model the use of Label set in a GMPLS environment and 
compare when I do not use it? Or a way to talk about label set in a 
mathematical way?
Or I am talking about something that do not exists?

tks
Cunha





Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 17:20:24 +0000
Message-ID: <[e-mail]>
From: "Stephen Shew" <[e-mail]>
To: [e-mail]
Subject: RE: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 6 Jan 2005 12:18:20 -0500 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F413.817783A1"

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

------_=_NextPart_001_01C4F413.817783A1
Content-Type: text/plain

I have read <draft-ietf-ccamp-loose-path-reopt-00.txt> and have some
questions and comments.

1. The actual reoptimization procedure is not specified as this is done via
the make before break method or some other way.  Only the triggers to cause
reoptimization are specified.  Is this correct?

2. In mid-point explict notification mode where a link or node is specified,
I am unsure what link is being referred to.  Because this is an LSP, it is
either the link upstream to to the mid-point node or the one downstream.  Is
there some RSVP convention that distinguishes this?  I think it is
downstream but don't know for sure.

3. Again in mid-point explict notification mode it is not clear what is
meant by "the TE database must be updated".  Does it mean that the link or
node is removed from the local TE database so that the first upstream node
that expands the ERO can compute around the link/node?  If so, then it is
necessary to indicate what the link and node are for the non-packet LSP
case.  That is, I am assuming that the RSVP signaling process (control) is
separated from the bearer plane (e.g., a SONET cross connect).  It is the
identity of the control "node" that is put into the PathErr whereas the
bearer "node" has a different identity.

To do this, I would suggest that the IF_ID ERROR_SPEC object (from
[RFC3473]) and all of the TLVs it may contain including from
draft-ietf-ccamp-crankback-03.txt be added to the PathErr message when
Error sub-codes 7&8 are used.  This will enable the actual link to be known.
In the case of node, Type 8 (NODE_ID) would identify the bearer node.

For security reasons, if the LSP spans domains, the OSPF_AREA or
AUTONOMOUS_SYSTEM TLVs could be used when error subcode 8 is passed
upstream.

4. In the same context as point 3, does the head-end LSR do anything to its
TE database based on the link or node Error sub-codes?

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 05, 2005 13:41
> To: [e-mail]
> Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
> 
> 
> This email starts a two week last call on 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat
> h-reopt-00.txt
> 
> Please send your comments to the list or to the chairs by 
> noon GMT on 20th January 2005.
> 
> Thanks,
> Adrian and Kireeti

------_=_NextPart_001_01C4F413.817783A1
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: Working Group Last Call =
draft-ietf-ccamp-loose-path-reopt-</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have read =
&lt;draft-ietf-ccamp-loose-path-reopt-00.txt&gt; and have some =
questions and comments.</FONT>
</P>

<P><FONT SIZE=3D2>1. The actual reoptimization procedure is not =
specified as this is done via the make before break method or some =
other way.&nbsp; Only the triggers to cause reoptimization are =
specified.&nbsp; Is this correct?</FONT></P>

<P><FONT SIZE=3D2>2. In mid-point explict notification mode where a =
link or node is specified, I am unsure what link is being referred =
to.&nbsp; Because this is an LSP, it is either the link upstream to to =
the mid-point node or the one downstream.&nbsp; Is there some RSVP =
convention that distinguishes this?&nbsp; I think it is downstream but =
don't know for sure.</FONT></P>

<P><FONT SIZE=3D2>3. Again in mid-point explict notification mode it is =
not clear what is meant by &quot;the TE database must be =
updated&quot;.&nbsp; Does it mean that the link or node is removed from =
the local TE database so that the first upstream node that expands the =
ERO can compute around the link/node?&nbsp; If so, then it is necessary =
to indicate what the link and node are for the non-packet LSP =
case.&nbsp; That is, I am assuming that the RSVP signaling process =
(control) is separated from the bearer plane (e.g., a SONET cross =
connect).&nbsp; It is the identity of the control &quot;node&quot; that =
is put into the PathErr whereas the bearer &quot;node&quot; has a =
different identity.</FONT></P>

<P><FONT SIZE=3D2>To do this, I would suggest that the IF_ID ERROR_SPEC =
object (from [RFC3473]) and all of the TLVs it may contain including =
from draft-ietf-ccamp-crankback-03.txt be added to the PathErr message =
when&nbsp; Error sub-codes 7&amp;8 are used.&nbsp; This will enable the =
actual link to be known.&nbsp; In the case of node, Type 8 (NODE_ID) =
would identify the bearer node.</FONT></P>

<P><FONT SIZE=3D2>For security reasons, if the LSP spans domains, the =
OSPF_AREA or AUTONOMOUS_SYSTEM TLVs could be used when error subcode 8 =
is passed upstream.</FONT></P>

<P><FONT SIZE=3D2>4. In the same context as point 3, does the head-end =
LSR do anything to its TE database based on the link or node Error =
sub-codes?</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: [e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>] On Behalf Of Adrian Farrel</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 05, 2005 13:41</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Working Group Last Call =
draft-ietf-ccamp-loose-path-reopt-</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This email starts a two week last call on =
</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-pat" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-ccamp-l=
oose-pat</A></FONT>
<BR><FONT SIZE=3D2>&gt; h-reopt-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please send your comments to the list or to the =
chairs by </FONT>
<BR><FONT SIZE=3D2>&gt; noon GMT on 20th January 2005.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; Adrian and Kireeti</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4F413.817783A1--



Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 11:18:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 06 Jan 2005 12:15:30 +0100
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

adrian, all,

some comments:

1. section 2: "The path computation may either be performed by
    means of CSPF or any Path Computation Element (PCE) and can be
    partial (up to the next loose hop) or complete (up to the TE LSP
    destination)."

two point here, the "or" in the first part of the sentence does not 
compare comparable things (an alogrithm versus a computation entity)
i think what you mean is "locally" or via an external computation 
element - i think the end paragraph of section 5.3.1 confirms my 
comment-  the second relates to the second is the word "complete" 
meaning strict under the tunnel end-point address ?

2. in the note, another terminology is introduced "full" i guess it has 
the same meaning as complete ?

3. i do not see the relationship of including the following paragraph 
(in the following paragraph " There is another scenario whereby 
notifying the head-end of the existence of a better path is desirable: 
if the current path is about the fail due to some (link or node) 
required maintenance (see also [GR-SHUT]).") within the context of this 
document as non-time sensitive mechanism is targeted here while the 
referenced document targets time-sensititve mechanism (existing LSPs are 
about to fail and not existing LSP can be re-optimized due to the 
existence of additional resource) however this point triggers to me the 
following question in case of link/node down for maintenance reasons 
what gives the guarantee that the head-end will respond on time before 
the maintenance operation is performed

4. section 4.: "New ERO flags and Error value sub-codes are proposed in 
this document (to be assigned by IANA)." i don't see any new ERO flag 
defined as far as my reading goes

5. section 5.3.1 to which LSR (intermediate vs head-end) the first LSR 
mentioned refers to "At this point, the LSR MAY decide to clear the 
ôPath re-evaluation requestö bit of the SESSION-ATTRIBUTE object in 
subsequent RSVP Path messages sent downstream:" and what "subsequent" 
refers to in the present context

6. section 5.3.1 "Note that the head-end LSR might use the METRIC-
    TYPE object (defined in [PATH-COMP]) in its path message to request
    the LSR having a next hop defined as a loose hop or an abstract node
    in the ERO to use another metric to determine a preferable path." do 
not appropriate to introduce alternatives based on objects and methods 
at this point in time in the document additionally these methods have 
never been discussed before therefore a more generic statement should 
replace the above statement allowing for future improvments when validated

7. section 5.3.2. " In this case, the mid-point LSR where the
    local maintenance must be performed is responsible for sending an
    RSVP PathError message with Error code 25 and Error sub-code=7 or 8
    depending on the affected network element (link or node)." my 
reading of all previous content was that in such a case the mid-point 
LSR is not the local maintenance point is realized - inline with what 
follows down this paragraph -

some edits

1. the document should refer to "PathErr" message and not "Path Error", 
   or "PathError"

2. section 3. reference to make-before-break i.e. RFC 3209 should be 
provided

3. there are lot of spurious charcaters such as ô, ö, etc.

thanks,
- dimitri

Adrian Farrel wrote:

> This email starts a two week last call on
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt
> 
> Please send your comments to the list or to the chairs by noon GMT on 20th
> January 2005.
> 
> Thanks,
> Adrian and Kireeti
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 03:23:11 +0000
Date: Wed, 5 Jan 2005 19:21:47 -0800
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Fwd: Review Call: draft-andersson-rtg-gmpls-change-00.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

fyi
-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: Alex Zinin <[e-mail]>
To: [e-mail]
Cc: 
Date: Wednesday, January 5, 2005, 4:29:00 PM
Subject: Review Call: draft-andersson-rtg-gmpls-change-00.txt

===8<==============Original message text===============
Folks-

 We'd like to solicit your comments on this document before Last-Call'ing it.
 Please send your comments to the routing-discussion mailing list.

 http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls-change-00.txt
 
                     MPLS and GMPLS Change Process
               draft-andersson-rtg-gmpls-change-00.txt
Abstract

   The MPLS and GMPLS protocol suites have become quite popular for a
   growing number of applications and deployment scenarios.  One result
   of this popularity is a large number of suggestions for modifications
   and extensions.

   The IETF needs to be flexible and responsive in how it handles these
   suggestions, and has a responsiblity to supervise the growth and
   evolution of MPLS and GMPLS protocols.

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   the MPLS and GMPLS standards.  This process means that extensions and
   changes to protocols specified by these working groups can only be
   made through the IETF, the body that created the (G)MPLS
   ((Generalized) Multiprotocol Label Switching) technologies.

-- 
Alex
http://www.psg.com/~zinin


_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion

===8<===========End of original message text===========




Envelope-to: [e-mail]
Delivery-date: Thu, 06 Jan 2005 01:41:51 +0000
Message-ID: <022101c4f390$62d47ef0$d39c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Proposed response to ITU-T liaison about Crankback
Date: Thu, 6 Jan 2005 01:36:36 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Here is a draft of a response to the SG15 liaison on the CCAMP crankback
draft. Comments are welcome in the next week.

Thanks,
Adrian

===========
To: Mr. Kam Lam, Rapporteur Q14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP co-chairs
Subject: Crankback in GMPLS Systems
For: Information

Thank you for your liaison concerning draft-ietf-ccamp-crankback-03. It is
useful to have additional review input from a wide audience. Please convey
our special thanks to Stephen Shew and Marco Carugi for their detailed
review of the draft in Geneva.

We would like to urge Q14/15 to continue to consider this draft as further
work is carried out on crankback within the context of G.7713.

 In response to the specific points that were raised in the liaison...

> 1.       Semantics of the term "node".  Due to the GMPLS principle of
> maintaining separation of control and transport (data/bearer) planes,
> there are two meanings for the term "node".  First, an instance of a
> signalling protocol (and/or routing protocol) that has some transport
> resources in its scope.  Second, a transport plane resource such as a
> cross connect.  Using the first meaning, a node is not the context for
> the interface identifiers that are passed in crankback TLVs.
> Throughout the document the particular meaning can be determined
> by the context of the term.  Examples are:
>
> - Section 5.2, the sentence "Otherwise, multiple nodes might attempt to
> repair the LSP." means the control functions of signalling and routing.
>
> - Section 7.1 "As described above, full crankback information SHOULD
> indicate the node, link and other resources, which have been attempted."
> refers to the transport resource.

It is correct to observe that historically there has been poor separation
of controllers and transport devices within GMPLS, with much of this issue
arising from the historic collocation of controllers and data switches in
MPLS networks. This persists because of the (emminently sensible) tendency
to optimize for the majority case.

However, in the case of crankback, and specifically in the case of this
draft, the emphasis in providing 'full crankback information' is on the
addresses of transport links and nodes and not controllers. We will
revisit the draft to ensure that where control plane function is implied,
the "node" that takes action is clearly identified as the control plane
node.

> There are some occasions where the use of the term appear to be
> ambiguous and clarity would be appreciated.  In particular TLV
> types 10 and 32. If  type 10 represents a routing and signalling
> function, then what TLV describes the "transport plane node"
> (e.g., cross connect or Network Element)?  If type 32 means
> "transport plane nodes", then a different TLV may be needed
> to identify the "routing/signalling nodes" that have already
> participated in crankback attempts.
> Having a clearer distinction between control plane functions
> and transport plane resources would be helpful.

As indicated above, the intention of crankback is to apply a process to
the path determination for an LSP. The path is determined using transport
plane links and nodes, and although there may be some interesting
aggregation available by converting this information to control plane
nodes, the conversion is not necessarily simple. Thus, these TLVs all
refer to transport plane quantities, and we will make this clearer in the
draft.

Again, of course, in the majority case we can make considerable
optimizations by knowing that control plane and transport plane "nodes"
are related in a 1:1 ratio and are usually collocated.

> 2.       When crankback information is received at a "routing/signalling
> node", can it be used by the routing path computation function for other
> LSP requests than the LSP whose signalling caused the crankback action?

It is generally out-of-scope for the IETF to dictate how individual
implementations operate. It is quite conceivable that such an action would
be taken, but it is also clear that there is a potentially dangerous
interaction with the TE flooding process (i.e. the IGP). Thus we would say
that the crankback information MAY be used to inform other path
computations.

We would want to be very cautious that crankback is not intended to
supplement or replace the normal operation of the TE flooding mechanism
provided by the TE extensions to the IGP except for the establishment of a
single LSP. If the IGP is found to be deficient as a flooding mechanism we
would expect to look first at ways to address the problems through IGP
extensions before utilizing a signaling mechanism.

We will look at how to add some of this information to the draft.

> 3.       Section 6.1 "Segment-based Re-routing" option.  It is not clear
> what this means.  Can multiple "routing/signalling nodes" perform
> crankback on the same LSP at the same time if this flag is set?

Since the intention is to establish only one LSP, there must be only one
active sequence of LSP setup messages (RSVP-TE Path messages) at any time.
Thus only one LSR may attempt re-routing at any one time.

If you consider the processes by which Path messages are attempted and
crankback information is returned on PathErr messages, this will be clear.
That is, when an PSR receives a crankback PathErr, it may attempt to
re-route or it may forward the PathErr back upstream.

It might help if we reworded the draft to say "Any node may attempt
rerouting after it receives an error report and before it passes the error
report further upstream."

> 4.       Section 4.3 History persistence.  If a repair point (a
> "routing/signalling node") is unsuccessful in a crankback attempt, is it
> possible for it to be not involved when another repair point (e.g.,
> closer to the source) succeeds in a crankback attempt.  If so, how
> does the first repair point know to clear its history?

Note that the purpose of the history table as described in section 4.3 is
to correlate information when repeated retry attempts are made by the same
LSR. Suppose an attempt is made to route from A through B, and the
signalling controller for B returns a failure with crankback information.
An attempt may be made to route from A through C, and this may also fail
with the return of crankback information. The next attempt SHOULD NOT be
to route from A through B, and this is achieved by use of the history
table.

The history table can be discarded by the signaling controller for A if
the LSP is successfully established through A. The history table MAY be
retained after the signaling controller for A sends an error upstream,
however it is questionable what value this provides since a future retry
as a result of crankback rerouting should not attempt to route through A
(such is the nature of crankback). If the history information is retained
for a longer period it SHOULD be discarded after a local timeout has
expired, and that timer MUST be shorter than the timer used by the ingress
to re-attempt a failed service (note that re-attempting a failed service
is not the same as making a re-route attempt after failure).

As mentioned for point 2, the crankback information MAY be used to enhance
future routing attempts for any LSP, but this is not what section 4.3 is
describing.

We will try to clarify this in the draft.

> 5.       Section 4.5 Retries.  Some guidance on setting the number of
> retries may be helpful as this is a distributed parameter.  Is it set to
> be the same value at all points that can perform crankback within one
> network?

The view of CCAMP at the moment is that although it is technically
possible to allow the number of retries to be set for each LSP, this
probably represents too much configuration and too fine a level of
control. It seems likely that initial deployments will wish to set the
number of retries per node through a network-wide configuration constant
(that is, all LSRs capable of retrying will apply the same count) with the
possibility of configuring specific LSRs to have greater or lower counts.
Note that configuring an LSR not to be able to perform retries is
equivalent to configuring the retry count to be zero for that LSR.

It is also probable that initial deployments will significantly restrict
the number of LSRs within the network that can perform crankback
rerouting. This would probably be limited to "boundary" nodes.

In the event that implementations and deployments wish to control the
number of retries on a per LSP basis, we would revisit the signaling
specification and add the relevant information to the Path and PathErr
messages.

The actual value to set for a retry threshold is entirely a deployment
issue. It will be constrained by the topology and nature of the network.
It would be inappropriate to suggest a figure in this draft since there
are no hard and fast rules.

In review of section 4.5 of the draft, we see that there is some old text
describing more flexibility in the control of retries than we intend to
provide. Thank you for drawing our attention to this; we will clean it up.


Thank you once again for your feedback on this draft.
If you have further comments, we would certainly like to hear them. The
easiest way for individuals to contribute to the discussion of this topic
is by sending mail to the CCAMP mailing list. Details of how to subscribe
to this list can be found at
http://www.ietf.org/html.charters/ccamp-charter.html

Yours sincerely,
Adrian Farrel and Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Wed, 05 Jan 2005 18:56:50 +0000
Message-ID: <016d01c4f356$37fef7d0$d39c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Wed, 5 Jan 2005 18:40:30 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

This email starts a two week last call on
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-loose-path-reopt-00.txt

Please send your comments to the list or to the chairs by noon GMT on 20th
January 2005.

Thanks,
Adrian and Kireeti




Envelope-to: [e-mail]
Delivery-date: Wed, 05 Jan 2005 11:11:22 +0000
Message-ID: <016201c4f316$5af43380$d39c9ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Submission of individual draft to CCAMP
Date: Wed, 5 Jan 2005 11:04:12 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit

Hi,

Dr. Jaihyung Cho wishes to draw your attention to the following draft that
he has submitted.

Adrian

> I have submitted attached individual draft and confirmed it is
> stored in IETF web directory. Please announce this submission
> to mailing list and let me hear comments from others.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lseframework-00.txt
> The contribution includes discussion on what technology need to
> be considered in GMPLS implementation for local area network
> and proposes LSE (Label Switched Ethernet) technology as a
> solution.
> It is the first part of series of documents I am planning to submit
> in CCAMP. At this time, I am only focusing on local area network,
> however the discussion will be extened to access network and
> eventually cover core network.
>
> I wish this issue may get people's attention to participate in
> effort to develop Ethernet.
> I belived GMPLS is the best glue technology to fill the gab between
> Ethernet and IP.
>
> Thanks
>
> Dr. Jaihyung Cho
> ETRI, Korea
> phone :       [phone]
> oversea: [phone]
> fax:         [phone]