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

From: The IESG <[email-masked]>
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: [email-masked]
Delivery-date: Mon, 31 Jan 2005 16:03:33 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>,  ccamp mailing list <[email-masked]>, ccamp chair <[email-masked]>, ccamp chair <[email-masked]>
Subject: Document Action: 'Requirements for Generalized MPLS (GMPLS)  Signaling Usage and Extensions for Automatically Switched Optical  Network (ASON)' to Informational RFC 
Message-Id: <[email-masked]>
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.

Delivery-date: Mon, 31 Jan 2005 15:53:12 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "JP Vasseur" <[email-masked]>, <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 31 Jan 2005 09:54:34 -0000

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: <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "JP Vasseur" <[email-masked]>; <[email-masked]>
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

Delivery-date: Mon, 31 Jan 2005 14:41:47 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Ali Sajassi <[email-masked]>
Cc: Ali Sajassi <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Mon, 31 Jan 2005 06:38:40 -0800

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: [email-masked] [mailto:[email-masked]]
Sent: Saturday, January 29, 2005 5:45 AM
To: Ali Sajassi
Cc: [email-masked]; Ali Sajassi; Shahram Davari; David Allan; [email-masked]'; 'Adrian Farrel'; [email-masked]
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 <[email-masked]>
01/28/2005 15:49 PST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari <[email-masked]>
cc: Shahram Davari <[email-masked]>, Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
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> 
[email-masked] 
[mailto:[email-masked]]<BR><B>Sent:</B> Saturday, January 29, 
2005 5:45 AM<BR><B>To:</B> Ali Sajassi<BR><B>Cc:</B> 
[email-masked]; Ali Sajassi; Shahram Davari; David Allan; 
[email-masked]'; 'Adrian Farrel'; [email-masked]<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;[email-masked]&gt;</B><BR>01/28/2005 15:49 PST<BR><BR>To:<FONT 
  size=4> </FONT>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
  &lt;[email-masked]&gt;<BR>cc:<FONT size=4> </FONT>Shahram 
  Davari &lt;[email-masked]&gt;, Dimitri 
  PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan 
  &lt;[email-masked]&gt;, "[email-masked]'" 
  &lt;[email-masked]&gt;, "'Adrian Farrel'" &lt;[email-masked]&gt;, 
  [email-masked]<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--

Delivery-date: Sun, 30 Jan 2005 12:52:13 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: "JP Vasseur" <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Sun, 30 Jan 2005 13:48:56 +0100

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

Delivery-date: Sun, 30 Jan 2005 06:56:54 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Sat, 29 Jan 2005 14:59:42 -0000

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

Delivery-date: Sat, 29 Jan 2005 10:50:41 +0000
To: Ali Sajassi <[email-masked]>
Cc: [email-masked], Ali Sajassi <[email-masked]>, Shahram Davari <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 11:44:47 +0100

Delivery-date: Sat, 29 Jan 2005 01:07:48 +0000
Date: Fri, 28 Jan 2005 17:06:04 -0800
To: [email-masked], Ali Sajassi <[email-masked]>
From: Ali Sajassi <[email-masked]>
Subject: RE: Layer 2 Switching Caps LSPs
Cc: [email-masked], Shahram Davari <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]

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

At 01:09 AM 1/29/2005 +0100, [email-masked] 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 <[email-masked]>
>01/28/2005 15:49 PST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Shahram Davari 
><[email-masked]>
>cc: Shahram Davari <[email-masked]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>, 
>"[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
><[email-masked]>, [email-masked]
>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, [email-masked] 
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;[email-masked]&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;[email-masked]&gt;</font><br>
<font size=2>cc:</font> <font size=2>Shahram Davari
&lt;[email-masked]&gt;, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan
&lt;[email-masked]&gt;, &quot;[email-masked]'&quot;
&lt;[email-masked]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[email-masked]&gt;, [email-masked]</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--

Delivery-date: Sat, 29 Jan 2005 00:11:08 +0000
To: Ali Sajassi <[email-masked]>
Cc: [email-masked], Shahram Davari <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 01:09:59 +0100

Delivery-date: Sat, 29 Jan 2005 00:01:23 +0000
Content-Class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Sat, 29 Jan 2005 00:01:56 -0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: 28 January 2005 22:10
To: Shahram Davari; [email-masked]; David Allan
Cc: [email-masked]; Adrian Farrel; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked] [mailto:[email-masked]]On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked]
[mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]';
'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line=20

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

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian
Farrel'" <[email-masked]>, "'Shahram Davari'"
<[email-masked]>, [email-masked]
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
[email-masked] [mailto:[email-masked]] <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; [email-masked]; =
David=20
Allan<BR><B>Cc:</B> [email-masked]; Adrian Farrel;=20
[email-masked]<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> [email-masked]=20
  [mailto:[email-masked]] <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; [email-masked]'; David Allan<BR><B>Cc:</B>=20
  [email-masked]'; 'Adrian Farrel';=20
  [email-masked]<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> =
[email-masked]=20
    [mailto:[email-masked]]<B>On Behalf Of </B>Shahram=20
    Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 =
PM<BR><B>To:</B>=20
    [email-masked]'; David Allan<BR><B>Cc:</B>=20
    [email-masked]'; 'Adrian Farrel';=20
    [email-masked]<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
      [email-masked]=20
      [mailto:[email-masked]]<BR><B>Sent:</B> Friday, =
January=20
      28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B>=20
      [email-masked]'; [email-masked]'; =
'Adrian=20
      Farrel'; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT =
size=3D2>Sent by:=20
      [email-masked]</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>"[email-masked]'" =
&lt;[email-masked]&gt;, "'Adrian=20
      Farrel'" &lt;[email-masked]&gt;, "'Shahram Davari'"=20
      &lt;[email-masked]&gt;, =
[email-masked]</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--

Delivery-date: Fri, 28 Jan 2005 23:51:56 +0000
Date: Fri, 28 Jan 2005 15:49:51 -0800
To: [email-masked], Shahram Davari <[email-masked]>
From: Ali Sajassi <[email-masked]>
Subject: RE: Layer 2 Switching Caps LSPs
Cc: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]

--=====================_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, [email-masked] 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 <[email-masked]>
>Sent by: [email-masked]
>01/28/2005 12:12 PST
>
>To: Shahram Davari <[email-masked]>, Dimitri 
>PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan <[email-masked]>
>cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
><[email-masked]>, [email-masked]
>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: [email-masked] [mailto:[email-masked]]On Behalf 
>Of Shahram Davari
>Sent: Friday, January 28, 2005 2:50 PM
>To: [email-masked]'; David Allan
>Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]]
>Sent: Friday, January 28, 2005 2:18 PM
>To: David Allan
>Cc: [email-masked]'; [email-masked]'; 'Adrian 
>Farrel'; Shahram Davari; [email-masked]
>Subject: RE: Layer 2 Switching Caps LSPs
>
>
>
>dave - see in-line
>
>"David Allan" <[email-masked]>
>Sent by: [email-masked]
>01/28/2005 13:54 EST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" 
><[email-masked]>, "'Shahram Davari'" <[email-masked]>, 
>[email-masked]
>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, [email-masked] 
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;[email-masked]&gt;</b></font><br>
<font size=2>Sent by: [email-masked]</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;[email-masked]&gt;, Dimitri
PAPADIMITRIOU/BE/ALCATEL@ALCATEL, David Allan
&lt;[email-masked]&gt;</font><br>
<font size=2>cc:</font> <font size=2>&quot;[email-masked]'&quot;
&lt;[email-masked]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[email-masked]&gt;, [email-masked]</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> [email-masked]
[<a href="mailto:[email-masked]%5DOn" eudora="autourl">mailto:[email-masked]]</a><a href="mailto:[email-masked]%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> [email-masked]'; David Allan<br>
<b>Cc:</b> [email-masked]'; 'Adrian Farrel';
[email-masked]<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> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]<br>
<b>Sent:</b> Friday, January 28, 2005 2:18 PM<br>
<b>To:</b> David Allan<br>
<b>Cc:</b> [email-masked]'; [email-masked]';
'Adrian Farrel'; Shahram Davari; [email-masked]<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;[email-masked]&gt;</b><br>
Sent by: [email-masked]<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;[email-masked]'&quot;
&lt;[email-masked]&gt;, &quot;'Adrian Farrel'&quot;
&lt;[email-masked]&gt;, &quot;'Shahram Davari'&quot;
&lt;[email-masked]&gt;, [email-masked]<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--

Delivery-date: Fri, 28 Jan 2005 22:25:19 +0000
From: Shahram Davari <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, [email-masked], David Allan <[email-masked]>
Cc: [email-masked], Adrian Farrel <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 14:24:14 -0800

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:[email-masked]]
Sent: Friday, January 28, 2005 5:10 PM
To: Shahram Davari; [email-masked]; David Allan
Cc: [email-masked]; Adrian Farrel; [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

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

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
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:[email-masked]]<BR><B>Sent:</B> Friday, January 28, 2005 5:10 
  PM<BR><B>To:</B> Shahram Davari; [email-masked]; David 
  Allan<BR><B>Cc:</B> [email-masked]; Adrian Farrel; 
  [email-masked]<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> [email-masked] 
  [mailto:[email-masked]] <B>On Behalf Of </B>Shahram 
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 3:12 PM<BR><B>To:</B> Shahram 
  Davari; [email-masked]'; David Allan<BR><B>Cc:</B> 
  [email-masked]'; 'Adrian Farrel'; 
  [email-masked]<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> [email-masked] 
    [mailto:[email-masked]]<B>On Behalf Of </B>Shahram 
    Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B> 
    [email-masked]'; David Allan<BR><B>Cc:</B> 
    [email-masked]'; 'Adrian Farrel'; 
    [email-masked]<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> 
      [email-masked] 
      [mailto:[email-masked]]<BR><B>Sent:</B> Friday, January 
      28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
      [email-masked]'; [email-masked]'; 'Adrian 
      Farrel'; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
      [email-masked]</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>"[email-masked]'" &lt;[email-masked]&gt;, "'Adrian 
      Farrel'" &lt;[email-masked]&gt;, "'Shahram Davari'" 
      &lt;[email-masked]&gt;, [email-masked]</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--

Delivery-date: Fri, 28 Jan 2005 22:12:05 +0000
content-class: urn:content-classes:message
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 16:09:55 -0600
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Shahram Davari" <[email-masked]>, <[email-masked]>, "David Allan" <[email-masked]>
Cc: <[email-masked]>, "Adrian Farrel" <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 3:12 PM
To: Shahram Davari; [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked]
[mailto:[email-masked]]On Behalf Of Shahram Davari
	Sent: Friday, January 28, 2005 2:50 PM
	To: [email-masked]'; David Allan
	Cc: [email-masked]'; 'Adrian Farrel';
[email-masked]
	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: [email-masked]
[mailto:[email-masked]]
		Sent: Friday, January 28, 2005 2:18 PM
		To: David Allan
		Cc: [email-masked]';
[email-masked]'; 'Adrian Farrel'; Shahram Davari;
[email-masked]
		Subject: RE: Layer 2 Switching Caps LSPs
	=09
	=09

		dave - see in-line=20
	=09
		"David Allan" <[email-masked]>
		Sent by: [email-masked]
		01/28/2005 13:54 EST
	=09
		To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
		cc: "[email-masked]'" <[email-masked]>,
"'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'"
<[email-masked]>, [email-masked]
		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> [email-masked]=20
[mailto:[email-masked]] <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; [email-masked]'; David Allan<BR><B>Cc:</B>=20
[email-masked]'; 'Adrian Farrel'; =
[email-masked]<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> =
[email-masked]=20
  [mailto:[email-masked]]<B>On Behalf Of </B>Shahram=20
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B>=20
  [email-masked]'; David Allan<BR><B>Cc:</B>=20
  [email-masked]'; 'Adrian Farrel';=20
  [email-masked]<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
    [email-masked]=20
    [mailto:[email-masked]]<BR><B>Sent:</B> Friday, =
January=20
    28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B>=20
    [email-masked]'; [email-masked]'; =
'Adrian=20
    Farrel'; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=3D2>Sent =
by:=20
    [email-masked]</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>"[email-masked]'" &lt;[email-masked]&gt;, =
"'Adrian=20
    Farrel'" &lt;[email-masked]&gt;, "'Shahram Davari'"=20
    &lt;[email-masked]&gt;, =
[email-masked]</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--

Delivery-date: Fri, 28 Jan 2005 21:07:52 +0000
To: Shahram Davari <[email-masked]>
Cc: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 22:06:27 +0100

Delivery-date: Fri, 28 Jan 2005 20:12:51 +0000
From: Shahram Davari <[email-masked]>
To: Shahram Davari <[email-masked]>, "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 12:12:19 -0800

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: [email-masked] [mailto:[email-masked]]On Behalf Of Shahram Davari
Sent: Friday, January 28, 2005 2:50 PM
To: [email-masked]'; David Allan
Cc: [email-masked]'; 'Adrian Farrel'; [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

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

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
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> [email-masked] 
  [mailto:[email-masked]]<B>On Behalf Of </B>Shahram 
  Davari<BR><B>Sent:</B> Friday, January 28, 2005 2:50 PM<BR><B>To:</B> 
  [email-masked]'; David Allan<BR><B>Cc:</B> 
  [email-masked]'; 'Adrian Farrel'; 
  [email-masked]<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> 
    [email-masked] 
    [mailto:[email-masked]]<BR><B>Sent:</B> Friday, January 
    28, 2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
    [email-masked]'; [email-masked]'; 'Adrian 
    Farrel'; Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
    [email-masked]</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>"[email-masked]'" &lt;[email-masked]&gt;, "'Adrian 
    Farrel'" &lt;[email-masked]&gt;, "'Shahram Davari'" 
    &lt;[email-masked]&gt;, [email-masked]</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--

Delivery-date: Fri, 28 Jan 2005 19:51:29 +0000
From: Shahram Davari <[email-masked]>
To: "[email-masked]'" <[email-masked]>, David Allan <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 11:50:27 -0800

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: [email-masked] [mailto:[email-masked]]
Sent: Friday, January 28, 2005 2:18 PM
To: David Allan
Cc: [email-masked]'; [email-masked]'; 'Adrian Farrel'; Shahram Davari; [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs

dave - see in-line 

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

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
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> 
  [email-masked] 
  [mailto:[email-masked]]<BR><B>Sent:</B> Friday, January 28, 
  2005 2:18 PM<BR><B>To:</B> David Allan<BR><B>Cc:</B> 
  [email-masked]'; [email-masked]'; 'Adrian Farrel'; 
  Shahram Davari; [email-masked]<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;[email-masked]&gt;</B></FONT><BR><FONT size=2>Sent by: 
  [email-masked]</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>"[email-masked]'" &lt;[email-masked]&gt;, "'Adrian 
  Farrel'" &lt;[email-masked]&gt;, "'Shahram Davari'" 
  &lt;[email-masked]&gt;, [email-masked]</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: [email-masked]
Delivery-date: Fri, 28 Jan 2005 19:31:26 +0000
Message-ID: <[email-masked]>
From: "David Allan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
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

Delivery-date: Fri, 28 Jan 2005 19:18:31 +0000
To: "David Allan" <[email-masked]>
Cc: "[email-masked]'"	 <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 20:17:44 +0100

Delivery-date: Fri, 28 Jan 2005 18:55:48 +0000
From: "David Allan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 13:54:59 -0500

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

Delivery-date: Fri, 28 Jan 2005 18:41:07 +0000
From: "David Allan" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 13:39:42 -0500

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" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>; "'Shahram 
> Davari'" <[email-masked]>
> Cc: <[email-masked]>
> 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;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;'Adrian Farrel'&quot; =
&lt;[email-masked]&gt;; &quot;'Shahram </FONT>
<BR><FONT SIZE=3D2>&gt; Davari'&quot; =
&lt;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: &lt;[email-masked]&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--

Delivery-date: Fri, 28 Jan 2005 17:27:46 +0000
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
From: [email-masked]
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

Delivery-date: Fri, 28 Jan 2005 16:42:41 +0000
To: Shahram Davari <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, [email-masked], "[email-masked]'"	 <[email-masked]>
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 17:41:46 +0100

Delivery-date: Fri, 28 Jan 2005 16:08:07 +0000
From: Shahram Davari <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, [email-masked]
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 08:07:27 -0800

Dimitri,

Could you please clarify this question.

Thanks,
Shahram

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, January 27, 2005 3:30 PM
> To: Shahram Davari; [email-masked]
> 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" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]]On
> > > Behalf Of Adrian Farrel
> > > Sent: Sunday, January 23, 2005 6:46 AM
> > > To: [email-masked]
> > > 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
> > >
> > >
> >
> >
> >
> 

Delivery-date: Fri, 28 Jan 2005 16:08:00 +0000
From: Shahram Davari <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, David Allan <[email-masked]>
Cc: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 08:06:30 -0800

What do you mean by just two sites?

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Friday, January 28, 2005 7:15 AM
> To: David Allan; Shahram Davari
> Cc: [email-masked]
> 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" <[email-masked]>
> To: "'Adrian Farrel'" <[email-masked]>; "'Shahram Davari'"
> <[email-masked]>
> Cc: <[email-masked]>
> 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
> >
> >
> >
> 

Delivery-date: Fri, 28 Jan 2005 15:49:04 +0000
To: "David Allan" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
From: [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 16:48:28 +0100

Delivery-date: Fri, 28 Jan 2005 15:39:51 +0000
From: "David Allan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 10:38:01 -0500

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

Delivery-date: Fri, 28 Jan 2005 14:59:33 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
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

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: <[email-masked]>
To: <[email-masked]>
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
> [email-masked] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-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:
> [email-masked].
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

Delivery-date: Fri, 28 Jan 2005 12:20:19 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "David Allan" <[email-masked]>, "'Shahram Davari'" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Layer 2 Switching Caps LSPs
Date: Fri, 28 Jan 2005 12:15:26 -0000

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" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; "'Shahram Davari'"
<[email-masked]>
Cc: <[email-masked]>
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
>
>
>

Delivery-date: Fri, 28 Jan 2005 00:36:22 +0000
Date: Fri, 28 Jan 2005 01:35:03 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: David Allan <[email-masked]>
CC: 'Adrian Farrel' <[email-masked]>,  'Shahram Davari' <[email-masked]>, [email-masked]
Subject: Re: Layer 2 Switching Caps LSPs

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: [email-masked]
Delivery-date: Thu, 27 Jan 2005 21:38:08 +0000
Message-ID: <[email-masked]>
From: "David Allan" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "'Shahram Davari'" <[email-masked]>
Cc: [email-masked]
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

Delivery-date: Thu, 27 Jan 2005 21:18:14 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Shahram Davari" <[email-masked]>, <[email-masked]>
Subject: Re: Layer 2 Switching Caps LSPs
Date: Thu, 27 Jan 2005 20:30:20 -0000

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" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>; <[email-masked]>
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: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Adrian Farrel
> > Sent: Sunday, January 23, 2005 6:46 AM
> > To: [email-masked]
> > 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
> >
> >
>
>
>

Delivery-date: Wed, 26 Jan 2005 09:32:04 +0000
From: [email-masked]
Subject: Re: Layer 2 Switching Caps LSPs
To: [email-masked]
Date: Wed, 26 Jan 2005 10:31:03 +0100

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 <[email-masked]>
To: <[email-masked]>

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

.

Delivery-date: Wed, 26 Jan 2005 07:52:31 +0000
Reply-To: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
From: =?ks_c_5601-1987?B?wbbA58f8?= <[email-masked]>
To: <[email-masked]>
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=?=
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

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

Delivery-date: Tue, 25 Jan 2005 21:26:56 +0000
From: Shahram Davari <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, [email-masked]
Subject: RE: Layer 2 Switching Caps LSPs
Date: Tue, 25 Jan 2005 13:25:36 -0800

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: [email-masked] [mailto:[email-masked]]On
> Behalf Of Adrian Farrel
> Sent: Sunday, January 23, 2005 6:46 AM
> To: [email-masked]
> 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
> 
> 

Delivery-date: Tue, 25 Jan 2005 19:36:39 +0000
Cc: <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 25 Jan 2005 14:33:45 -0500
To: "Adrian Farrel" <[email-masked]>

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

Delivery-date: Tue, 25 Jan 2005 19:36:29 +0000
Cc: <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Tue, 25 Jan 2005 14:34:06 -0500
To: "Adrian Farrel" <[email-masked]>

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" <[email-masked]>
> To: <[email-masked]>
> 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
>>
>>
>>
>>
>

Delivery-date: Mon, 24 Jan 2005 09:39:36 +0000
Cc: Adrian Farrel <[email-masked]>, [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:39:08 -0500
To: Arthi Ayyangar <[email-masked]>

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

Delivery-date: Mon, 24 Jan 2005 09:32:18 +0000
Cc: [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:32:14 -0500
To: "Stephen Shew" <[email-masked]>

--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: [email-masked]
>  > [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > Sent: Wednesday, January 05, 2005 13:41
> > To: [email-masked]
> > 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:
[email-masked]</x-tad-smaller></smaller></excerpt><excerpt>=20

 <smaller><x-tad-smaller>>
=
[</x-tad-smaller><color><param>0000,0000,EEEE</param><x-tad-smaller>mailto=
:[email-masked]</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:
[email-masked]</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--

Delivery-date: Mon, 24 Jan 2005 09:24:22 +0000
Cc: Adrian Farrel <[email-masked]>, [email-masked]
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Mon, 24 Jan 2005 04:22:45 -0500
To: [email-masked], [email-masked]

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

Delivery-date: Sun, 23 Jan 2005 17:54:24 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Layer 2 Switching Caps LSPs
Date: Sun, 23 Jan 2005 11:46:16 -0000

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

Delivery-date: Fri, 21 Jan 2005 23:08:24 +0000
Cc: <[email-masked]>
From: JP Vasseur <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 21 Jan 2005 18:06:29 -0500
To: "Adrian Farrel" <[email-masked]>

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" <[email-masked]>
> To: <[email-masked]>
> 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
>>
>>
>>
>>
>

Delivery-date: Fri, 21 Jan 2005 12:25:39 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Igor Bryskin" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Dimitri Papadimitriou" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Draft ready for ADs : draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Fri, 21 Jan 2005 11:52:38 -0000

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

Delivery-date: Fri, 21 Jan 2005 12:25:34 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 21 Jan 2005 11:37:43 -0000

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" <[email-masked]>
To: <[email-masked]>
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

Delivery-date: Thu, 20 Jan 2005 19:53:51 +0000
Date: Thu, 20 Jan 2005 11:51:23 -0800 (PST)
From: Arthi Ayyangar <[email-masked]>
To: Adrian Farrel <[email-masked]>
cc: [email-masked]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

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

Delivery-date: Mon, 17 Jan 2005 21:08:00 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
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 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 17 Jan 2005 03:34:50 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>, Scott Bradner <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Response to Liaison Concerning the Comparison of LMP and ASON Discovery
Date: Sun, 16 Jan 2005 22:33:21 -0500

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:[email-masked]]
> Sent: Sunday, January 16, 2005 12:52 PM
> To: Lam, Hing-Kam (Kam)
> Cc: 'Kireeti Kompella'; [email-masked]; Bill Fenner; Scott Bradner;
> [email-masked]; [email-masked]
> 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,
> >[email-masked]) 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
> 

Delivery-date: Sun, 16 Jan 2005 17:55:03 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>, "Scott Bradner" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Response to Liaison Concerning the Comparison of LMP and ASON Discovery
Date: Sun, 16 Jan 2005 17:52:28 -0000

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,
>[email-masked]) 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

Delivery-date: Sun, 16 Jan 2005 04:06:07 +0000
From: "Lam, Hing-Kam (Kam)" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: [email-masked], Scott Bradner <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, [email-masked], [email-masked], Bill Fenner <[email-masked]>
Subject: RE: Response to ITU-T Q14/15 Liaison about CCAMP Crankback Draft
Date: Sat, 15 Jan 2005 23:02:31 -0500

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:[email-masked]]
Sent: Saturday, January 15, 2005 6:55 AM
To: Lam, Hing-Kam (Kam)
Cc: [email-masked]; Scott Bradner; 'Kireeti Kompella'; [email-masked]; [email-masked]; 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:[email-masked]]<BR><B>Sent:</B> Saturday, January 15, 2005 6:55 
  AM<BR><B>To:</B> Lam, Hing-Kam (Kam)<BR><B>Cc:</B> [email-masked]; Scott 
  Bradner; 'Kireeti Kompella'; [email-masked]; [email-masked]; 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--

Delivery-date: Sat, 15 Jan 2005 12:25:59 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: "Lam, Hing-Kam (Kam)" <[email-masked]>
Cc: <[email-masked]>, "Scott Bradner" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: Response to ITU-T Q14/15 Liaison about CCAMP Crankback Draft
Date: Sat, 15 Jan 2005 11:54:42 -0000

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

Delivery-date: Sat, 15 Jan 2005 12:25:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Updated Draft Response to Incoming liaison (2) from ITU-T SG15
Date: Sat, 15 Jan 2005 11:54:24 -0000

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,
>[email-masked]) 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;[email-masked]) =
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--

Delivery-date: Sat, 15 Jan 2005 12:25:42 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN
Date: Fri, 14 Jan 2005 22:33:12 -0000

FYI
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
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 [email-masked].
>
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>

Delivery-date: Fri, 14 Jan 2005 22:12:02 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, "Bill Fenner" <[email-masked]>
Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-01.txt
Date: Fri, 14 Jan 2005 21:17:55 -0000

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>

Delivery-date: Fri, 14 Jan 2005 12:00:17 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Fri, 14 Jan 2005 11:43:28 -0000

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

Delivery-date: Fri, 14 Jan 2005 04:50:05 +0000
Date: Fri, 14 Jan 2005 13:47:33 +0900
From: "K. Miyazaki" <[email-masked]>
To: [email-masked]
Subject: CALL FOR PARTICIPATION: iPOP 2005

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

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.

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

Delivery-date: Thu, 13 Jan 2005 13:46:40 +0000
Date: Thu, 13 Jan 2005 07:45:44 -0600
From: Jim Jones <[email-masked]>
Organization: Alcatel USA
To: Adrian Farrel <[email-masked]>
CC: "'Kireeti Kompella'" <[email-masked]>, [email-masked], Bill Fenner <[email-masked]>, [email-masked]
Subject: Re: Communication on Procedures for Modifying the Resource reSerVation Protocol (RSVP)

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

Delivery-date: Thu, 13 Jan 2005 13:41:53 +0000
From: "Don Fedyk" <[email-masked]>
To: [email-masked]
Cc: "Don Fedyk" <[email-masked]>, [email-masked], Adrian Farrel <[email-masked]>, [email-masked], "Brungard, Deborah A, ALABS" <[email-masked]>, "Osama Aboul-Magd" <[email-masked]>, Jonathan Lang <[email-masked]>
Subject: Draft Response to Incoming liaison (2) from ITU-T SG15
Date: Thu, 13 Jan 2005 08:39:41 -0500

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,
>[email-masked]) 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;[email-masked]) 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--

Delivery-date: Thu, 13 Jan 2005 12:01:06 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Fw: WG Last Call for "Extensions to OSPF for Advertising Optional Router"
Date: Thu, 13 Jan 2005 10:50:24 -0000

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" <[email-masked]>
To: <[email-masked]>
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
>
>

Delivery-date: Wed, 12 Jan 2005 23:35:38 +0000
To: Mailing List <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Date: Wed, 12 Jan 2005 18:14:19 -0500
Cc: 
Subject: [mpls] Fwd: WG Action: Path Computation Element (pce)

--===============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 <[email-masked]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [email-masked]
> Cc: [email-masked], Adrian Farrel <[email-masked]>, JP Vasseur 
> <[email-masked]>
> 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 <[email-masked]>
> JP Vasseur <[email-masked]>
>
> Routing Area Director(s):
> Bill Fenner <[email-masked]>
> Alex Zinin <[email-masked]>
>
> Routing Area Advisor:
> Alex Zinin <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> 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 <<[email-masked]>

<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>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked], Adrian Farrel <<[email-masked]>, JP
Vasseur <<[email-masked]>

<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 <<[email-masked]>

JP Vasseur <<[email-masked]>

Routing Area Director(s):

Bill Fenner <<[email-masked]>

Alex Zinin <<[email-masked]>

Routing Area Advisor:

Alex Zinin <<[email-masked]>

Mailing Lists:

General Discussion: [email-masked]

To Subscribe: [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0288458767==--

Delivery-date: Wed, 12 Jan 2005 23:35:20 +0000
To: Mailing List <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
Date: Wed, 12 Jan 2005 18:14:19 -0500
Cc: 
Subject: [mpls] Fwd: WG Action: Path Computation Element (pce)

--===============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 <[email-masked]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [email-masked]
> Cc: [email-masked], Adrian Farrel <[email-masked]>, JP Vasseur 
> <[email-masked]>
> 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 <[email-masked]>
> JP Vasseur <[email-masked]>
>
> Routing Area Director(s):
> Bill Fenner <[email-masked]>
> Alex Zinin <[email-masked]>
>
> Routing Area Advisor:
> Alex Zinin <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> 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 <<[email-masked]>

<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>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked], Adrian Farrel <<[email-masked]>, JP
Vasseur <<[email-masked]>

<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 <<[email-masked]>

JP Vasseur <<[email-masked]>

Routing Area Director(s):

Bill Fenner <<[email-masked]>

Alex Zinin <<[email-masked]>

Routing Area Advisor:

Alex Zinin <<[email-masked]>

Mailing Lists:

General Discussion: [email-masked]

To Subscribe: [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

--===============0288458767==--

Delivery-date: Wed, 12 Jan 2005 23:16:09 +0000
To: Mailing List <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
From: JP Vasseur <[email-masked]>
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 <[email-masked]>
> Date: January 12, 2005 3:39:31 PM EST
> To: [email-masked]
> Cc: [email-masked], Adrian Farrel <[email-masked]>, JP Vasseur 
> <[email-masked]>
> 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 <[email-masked]>
> JP Vasseur <[email-masked]>
>
> Routing Area Director(s):
> Bill Fenner <[email-masked]>
> Alex Zinin <[email-masked]>
>
> Routing Area Advisor:
> Alex Zinin <[email-masked]>
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> 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 <<[email-masked]>

<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>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked], Adrian Farrel <<[email-masked]>, JP
Vasseur <<[email-masked]>

<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 <<[email-masked]>

JP Vasseur <<[email-masked]>

Routing Area Director(s):

Bill Fenner <<[email-masked]>

Alex Zinin <<[email-masked]>

Routing Area Advisor:

Alex Zinin <<[email-masked]>

Mailing Lists:

General Discussion: [email-masked]

To Subscribe: [email-masked]

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

Delivery-date: Tue, 11 Jan 2005 20:33:21 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Liaison received from ITU-T SG13 Question 12
Date: Tue, 11 Jan 2005 13:15:15 -0000

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: +1 919 807 0023
Email: [email-masked]

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.

Delivery-date: Thu, 06 Jan 2005 23:51:56 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Last Call: 'Link Bundling in MPLS Traffic Engineering' to Proposed  Standard 
Date: Thu, 6 Jan 2005 23:48:47 -0000

FYI
----- Original Message ----- 
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Cc: <[email-masked]>
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
> [email-masked] or [email-masked] 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
>

Delivery-date: Thu, 06 Jan 2005 20:04:24 +0000
Date: Thu, 06 Jan 2005 18:03:00 -0200
From: Daniela Cunha <[email-masked]>
To:  [email-masked]
Subject: Label set model

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

Delivery-date: Thu, 06 Jan 2005 17:20:24 +0000
From: "Stephen Shew" <[email-masked]>
To: [email-masked]
Subject: RE: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Thu, 6 Jan 2005 12:18:20 -0500 

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, January 05, 2005 13:41
> To: [email-masked]
> 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: [email-masked] </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]=
</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: [email-masked]</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--

Delivery-date: Thu, 06 Jan 2005 11:18:03 +0000
Date: Thu, 06 Jan 2005 12:15:30 +0100
From: dimitri papadimitriou <[email-masked]>
Reply-To:  [email-masked],  [email-masked]
To: Adrian Farrel <[email-masked]>
CC:  [email-masked]
Subject: Re: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-

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

Delivery-date: Thu, 06 Jan 2005 03:23:11 +0000
Date: Wed, 5 Jan 2005 19:21:47 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Fwd: Review Call: draft-andersson-rtg-gmpls-change-00.txt

fyi
-- 
Alex
http://www.psg.com/~zinin

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

===8<===========End of original message text===========

Delivery-date: Thu, 06 Jan 2005 01:41:51 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Proposed response to ITU-T liaison about Crankback
Date: Thu, 6 Jan 2005 01:36:36 -0000

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

Delivery-date: Wed, 05 Jan 2005 18:56:50 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Working Group Last Call draft-ietf-ccamp-loose-path-reopt-
Date: Wed, 5 Jan 2005 18:40:30 -0000

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

Delivery-date: Wed, 05 Jan 2005 11:11:22 +0000
Reply-To: "Adrian Farrel" <[email-masked]>
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Subject: Fw: Submission of individual draft to CCAMP
Date: Wed, 5 Jan 2005 11:04:12 -0000

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 :       042) 860-5514
> oversea: +82-42-860-5514
> fax:         +82-42-861-5550