Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-02.txt

["Adrian Farrel" <[e-mail]>]

FYI the changes to this version are relatively minor.

- Update boilerplate
- Change "Network controller" to "Controller"
- Clarify that in GMPLS a connection is usually termed an LSP
- Strengthen the definition of a hierarchical LSP and introduce the
   abbreviation H-LSP.
- Remove confusing text about the discovery of component link
   ends through routing protocols.
- Note that a "TE region" is often called an "LSP region" or just
  a "Region".
- Re-order references.

I plan to liaise this version of the draft to SG15 question 14 (main ASON
protocol question) and question 3 (terminology) for their input, in
particular since much of the text was contributed by SG15 folks at the
meeting in Holmdel earlier this year.

We would also appreciate further feedback from CCAMP on the accuracy of
the draft and its structure. In particular, the draft introduces some
terminology that is not defined in existing I-Ds or RFCs (sometimes it is
used w/o definition, but more often it is a concept that is well-known in
GMPLS but for which there is no term) - should we leave these terms
embedded within the draft as currently, or should we pull them out to an
early section to high-light them?

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, April 29, 2005 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-02.txt


> 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 : A Lexicography for the Interpretation of Generalized
>   Multiprotocol Label Switching (GMPLS) Terminology within
>   The Context of the ITU-T's Automatically Switched Optical
>   Network (ASON) Architecture
> Author(s) : I. Bryskin, A. Farrel
> Filename : draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
> Pages : 15
> Date : 2005-4-29
>
> Generalized Multiprotocol Label Switching (GMPLS) has been developed
>    by the IETF to facilitate the establishment of Label Switched Paths
>    (LSPs) in a variety of physical technologies and across several
>    architectural models. The ITU-T has specified an architecture for
>    the management of Automatically Switched Optical Networks (ASON).
>
>    This document provides a lexicography for the interpretation of GMPLS
>    terminology within the context of the ASON architecture.
>
>    It is important to note that GMPLS is applicable in a far wider set
>    of contexts than just ASON. Thus the definitions presented in this
>    document do not provide exclusive or complete interpretations of the
>    GMPLS concepts. The intention of this document is simply to allow the
>    GMPLS terms to be applied within the ASON context.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-gmpls-ason-lexicography-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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.
>





Envelope-to: [e-mail]
Delivery-date: Sat, 30 Apr 2005 12:36:21 +0000
Message-ID: <072201c54d81$2bc2bdf0$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Igor Bryskin" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
Date: Sat, 30 Apr 2005 13:35:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI the changes to this version are relatively minor.

- Update boilerplate
- Change "Network controller" to "Controller"
- Clarify that in GMPLS a connection is usually termed an LSP
- Strengthen the definition of a hierarchical LSP and introduce the
   abbreviation H-LSP.
- Remove confusing text about the discovery of component link
   ends through routing protocols.
- Note that a "TE region" is often called an "LSP region" or just
  a "Region".
- Re-order references.

I plan to liaise this version of the draft to SG15 question 14 (main ASON
protocol question) and question 3 (terminology) for their input, in
particular since much of the text was contributed by SG15 folks at the
meeting in Holmdel earlier this year.

We would also appreciate further feedback from CCAMP on the accuracy of
the draft and its structure. In particular, the draft introduces some
terminology that is not defined in existing I-Ds or RFCs (sometimes it is
used w/o definition, but more often it is a concept that is well-known in
GMPLS but for which there is no term) - should we leave these terms
embedded within the draft as currently, or should we pull them out to an
early section to high-light them?

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, April 29, 2005 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-02.txt


> 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 : A Lexicography for the Interpretation of Generalized
>   Multiprotocol Label Switching (GMPLS) Terminology within
>   The Context of the ITU-T's Automatically Switched Optical
>   Network (ASON) Architecture
> Author(s) : I. Bryskin, A. Farrel
> Filename : draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
> Pages : 15
> Date : 2005-4-29
>
> Generalized Multiprotocol Label Switching (GMPLS) has been developed
>    by the IETF to facilitate the establishment of Label Switched Paths
>    (LSPs) in a variety of physical technologies and across several
>    architectural models. The ITU-T has specified an architecture for
>    the management of Automatically Switched Optical Networks (ASON).
>
>    This document provides a lexicography for the interpretation of GMPLS
>    terminology within the context of the ASON architecture.
>
>    It is important to note that GMPLS is applicable in a far wider set
>    of contexts than just ASON. Thus the definitions presented in this
>    document do not provide exclusive or complete interpretations of the
>    GMPLS concepts. The intention of this document is simply to allow the
>    GMPLS terms to be applied within the ASON context.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [e-mail] with the word unsubscribe in the body of
the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ccamp-gmpls-ason-lexicography-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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.
>




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Apr 2005 19:51:21 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
Date: Fri, 29 Apr 2005 15:50:10 -0400

--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		: A Lexicography for the Interpretation of Generalized 
			  Multiprotocol Label Switching (GMPLS) Terminology within 
			  The Context of the ITU-T's Automatically Switched Optical
			  Network (ASON) Architecture
	Author(s)	: I. Bryskin, A. Farrel
	Filename	: draft-ietf-ccamp-gmpls-ason-lexicography-02.txt
	Pages		: 15
	Date		: 2005-4-29
	
Generalized Multiprotocol Label Switching (GMPLS) has been developed
   by the IETF to facilitate the establishment of Label Switched Paths
   (LSPs) in a variety of physical technologies and across several
   architectural models. The ITU-T has specified an architecture for
   the management of Automatically Switched Optical Networks (ASON).

   This document provides a lexicography for the interpretation of GMPLS
   terminology within the context of the ASON architecture.

   It is important to note that GMPLS is applicable in a far wider set
   of contexts than just ASON. Thus the definitions presented in this
   document do not provide exclusive or complete interpretations of the
   GMPLS concepts. The intention of this document is simply to allow the
   GMPLS terms to be applied within the ASON context.

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

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-lexicography-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-lexicography-02.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Fri, 29 Apr 2005 15:25:42 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Document Action: 'Framework for GMPLS-based Control of  SDH/SONET Networks' to Informational RFC 
Message-Id: <[e-mail]>
Date: Fri, 29 Apr 2005 11:22:56 -0400

The IESG has approved the following document:

- 'Framework for GMPLS-based Control of SDH/SONET Networks '
   <draft-ietf-ccamp-sdhsonet-control-05.txt> as an Informational RFC

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

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   GMPLS consists of a suite of protocol extensions to MPLS to make 
   these protocols more generally applicable, to include - for example
   - control of non-packet based switching, and particularly, optical 
   switching.  One area of prime consideration is to use Generalized 
   MPLS (GMPLS) protocols in upgrading the control plane of optical 
   transport networks.  This document illustrates this process by 
   describing those extensions to GMPLS protocols that are directed 
   towards controlling SDH/SONET networks.  SDH/SONET networks make 
   very good examples of this process since they possess a rich 
   multiplex structure, a variety of protection/restoration options, 
   are well defined, and are widely deployed. The document discusses 
   extensions to GMPLS routing protocols to disseminate information 
   needed in transport path computation and network operations, 
   together with the extensions to GMPLS label distribution protocols 
   needed for the provisioning of transport circuits. New capabilities 
   that an GMPLS control plane would bring to SDH/SONET networks, such 
   as new restoration methods and multi-layer circuit establishment, 
   are also discussed.  
 
Working Group Summary
 
   The CCAMP WG had a consensus on advancing this document.
 
Protocol Quality
 
   The document has been reviewed by the RTG area directorate and Alex Zinin.

RFC Editor Note

Section 1.1 para 2

OLD
   An MPLS network consists of MPLS nodes called Label Switch Routers
   (LSRs) connected via circuits called Label Switched Paths (LSPs). An
   LSP is unidirectional and could be of several different types such
   as point-to-point, point-to-multipoint, and multipoint-to-point.
NEW
   An MPLS network consists of MPLS nodes called Label Switch Routers
   (LSRs) connected via Label Switched Paths (LSPs). An
   LSP is unidirectional and could be of several different types such
   as point-to-point, point-to-multipoint, and multipoint-to-point.
 
Replace text in section 7 (Security Considerations) with the following.

 NEW:

  The use of a control plane to provision connectivity through a SONET/SDH
  network shifts the security burden significantly from the management plane
  to the control plane. Before the introduction of a control plane, the
  communications that had to be secured were between the management stations
  (Element Management Systems or Network Management Systems) and each
  network element that participated in the network connection. After the
  introduction of the control plane, the only management plane communication
  that needs to be secured is that to the head-end (ingress) network node as
  the end-to-end service is requested. On the other hand, the control plane
  introduces a new requirement to secure signaling and routing
  communications between adjacent nodes in the network plane.

  The security risk from impersonated management stations is significantly
  reduced by the use of a control plane. In particular, where unsecure
  versions of network management protocols such as SNMP versions 1 and 2
  were popular configuration tools in transport networks, the use of a
  control plane may significantly reduce the security risk of malicious and
  false assignment of network resources that could cause the interception or
  disruption of data traffic.

  On the other hand, the control plane may increase the number of security
  relationships that each network node must maintain. Instead of a single
  security relationship with its management element, each network node must
  now maintain a security relationship with each of its signaling and
  routing neighbors in the control plane.

  There is a strong requirement for singaling and control plane exchanges to
  be secured, and any protocols proposed for this purpose must be capable of
  secure message exchanges. This is already the case for the existing GMPLS
  routing and signaling protocols.




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Apr 2005 12:48:53 +0000
Message-ID: <069301c54cba$10249c70$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Working group last call on draft-ietf-ccamp-rsvp-restart-ext-02.txt
Date: Fri, 29 Apr 2005 13:47:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Sorry that the WG last calls are coming thick and fast.

We are trying to limit them to have just one or two open at any one time
to give you a chance.

This email starts a two week last call on
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-02.txt

Please send your comments to the mailing list by 12 noon (GMT) on Friday
13th May 2005.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 29 Apr 2005 12:45:04 +0000
Message-ID: <069201c54cb9$7ec46cb0$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call complete on GMPLS MIBs
Date: Fri, 29 Apr 2005 13:44:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks for comments received off the list.

The main work we have to do is to address Tom Petch's useful input.

Expect new revisions relatively soon.

Thanks,
Adrian



Envelope-to: [e-mail]
Delivery-date: Fri, 29 Apr 2005 12:25:48 +0000
Message-ID: <067301c54cb6$87e2e540$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Kohei Shiomoto" <[e-mail]>, "Richard Rabbat" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>
Subject: Decission on Addressing draft
Date: Fri, 29 Apr 2005 13:07:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

The opinion seems to be in favor.

There were some doubts raised, but these do appear to have been resolved
by agreements to modify the wording in a future revision.

Therefore, editors, please...
- Submit draft-ietf-ccamp-gmpls-addressing-00.txt
   Please do not make any changes to this version except
   - name and date
   - boilerplate to conform to idnits
- Please prepare a new revision of the draft *soon* that
   handles the textual changes recently discussed and agreed
- Continue to drive discussion and debate on the list about
   individual subsections.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 27 Apr 2005 17:54:22 +0000
From: "Rajiv Papneja" <[e-mail]>
To: "'Diego Caviglia'" <[e-mail]>
Cc: "'\"\"'ccamp'\" <ccamp\"'" <[e-mail]>, "'\"\"'Kohei Shiomoto'\" <shiomoto.kohei\"'" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Wed, 27 Apr 2005 13:52:05 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C54B30.4BF83BC0"
Thread-Index: AcVLP7+hYZ8OPjN6StyufABhHn0MgAAEdxiQ
Message-Id: <[e-mail]>

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01C54B30.4BF83BC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Diego,

 

 We will certainly add text for LMP  as mentioned in earlier email
exchanges. 

 

 /R

  _____  

From: Diego Caviglia [mailto:[e-mail]] 
Sent: Wednesday, April 27, 2005 11:42 AM
To: [e-mail]
Cc: ""'ccamp'" <ccamp"; ""'Kohei Shiomoto'" <shiomoto.kohei"; ""'Rajiv
Papneja'" <rpapneja"
Subject: RE: Addressing doc

 


Richiard, 
                     IMHO also a section (or sub-section) dedicated to LMP
usage could be very useful in order to clarify how LMP can help in
addressing resolution. 

BR 

D 

Sent by:        [e-mail] 

To:        "'ccamp'" <[e-mail]> 
cc:        "'Kohei Shiomoto'" <[e-mail]>, "'Richard
Rabbat'" <[e-mail]>, "'Rajiv Papneja'"
<[e-mail]> 

Subject:        RE: Addressing doc 



Hi all, 
  
The editors have been having various discussions  with people about some
oftheir issues  with this draft. In order to clarify a some  points here are
some of thechanges that  we plan tomake to the next version  of the draft.
We hope thiswill help  to clarify the draft. 
  
1. In section 4.2.1,  previous text: 
   Alternatively, the tunnel end point  address MAY also be set to the
destination data plane address if the  ingress knows that address or the TE
Router ID. 
New  text: 
   Alternatively, the tunnel end point address MAY  also be set to
thedestination data plane  address if the ingress knows that address. 
  
2. In section 4.2.2 previous text: 
   Alternatively,  the tunnel sender address MAY also be set to thesender
data plane address or the TE Router ID. 
New  text: 
   Alternatively, the tunnel sender address MAY also  be set to thesender
data plane  address. 
  
3. at the end of the introduction, we will add  wording to the last line to
that effect: 
Various more complex deployment scenarios can be  constructed but these are
currently out of scope as the only GMPLS implementations encountered
ininteroperability testing or in deployment have  applied this relationship.
Whennew  implementations that include any other relationship between
controlplane and data plane entities are encountered,  this document would
beenhanced as  necessary. 





------=_NextPart_000_0030_01C54B30.4BF83BC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:sans-serif;
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;We will certainly add text =
for LMP &nbsp;as
mentioned in earlier email exchanges. <o:p></o:p></span></font></p>

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

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

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Diego =
Caviglia
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, April =
27, 2005
11:42 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
&quot;&quot;'ccamp'&quot;
&lt;ccamp&quot;; &quot;&quot;'Kohei Shiomoto'&quot; =
&lt;shiomoto.kohei&quot;;
&quot;&quot;'Rajiv Papneja'&quot; &lt;rpapneja&quot;<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Addressing =
doc</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'><br>
</span></font><font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;
font-family:sans-serif'>Richiard,</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp;IMHO also
a section (or sub-section) dedicated to LMP usage could be very useful =
in order
to clarify how LMP can help in addressing resolution.</span></font> <br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>BR</span></font>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>D</span></font>
<o:p></o:p></p>

<p><font size=3D1 color=3Dpurple face=3Dsans-serif><span =
style=3D'font-size:7.5pt;
font-family:sans-serif;color:purple'>Sent by: &nbsp; &nbsp; &nbsp; =
&nbsp;[e-mail]</span></font>
<o:p></o:p></p>

<p style=3D'margin-bottom:12.0pt'><font size=3D1 color=3Dpurple =
face=3Dsans-serif><span
style=3D'font-size:7.5pt;font-family:sans-serif;color:purple'>To: &nbsp; =
&nbsp; &nbsp;
&nbsp;</span></font><font size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;
font-family:sans-serif'>&quot;'ccamp'&quot; =
&lt;[e-mail]&gt;</span></font>
<br>
<font size=3D1 color=3Dpurple face=3Dsans-serif><span =
style=3D'font-size:7.5pt;
font-family:sans-serif;color:purple'>cc: &nbsp; &nbsp; &nbsp; =
&nbsp;</span></font><font
size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>&quot;'Kohei
Shiomoto'&quot; &lt;[e-mail]&gt;, &quot;'Richard
Rabbat'&quot; &lt;[e-mail]&gt;, &quot;'Rajiv
Papneja'&quot; &lt;[e-mail]&gt;<font color=3Dpurple><span
style=3D'color:purple'> </span></font></span></font><br>
<br>
<font size=3D1 color=3Dpurple face=3Dsans-serif><span =
style=3D'font-size:7.5pt;
font-family:sans-serif;color:purple'>Subject: &nbsp; &nbsp; &nbsp; =
&nbsp;</span></font><font
size=3D1 face=3Dsans-serif><span =
style=3D'font-size:7.5pt;font-family:sans-serif'>RE:
Addressing doc</span></font> <br>
<br>
<br>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Hi&nbsp;all,</span></fo=
nt>
<br>
<font face=3Dsans-serif><span =
style=3D'font-family:sans-serif'>&nbsp;</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>The
editors have been having various discussions &nbsp;with people about =
some
oftheir issues &nbsp;with this draft.&nbsp;In order to clarify a some =
&nbsp;points
here are some of thechanges that &nbsp;we plan tomake to the next =
version &nbsp;of
the draft. We hope thiswill help &nbsp;to&nbsp;clarify the =
draft.</span></font>
<br>
<font face=3Dsans-serif><span =
style=3D'font-family:sans-serif'>&nbsp;</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>1.
In section 4.2.1, &nbsp;previous text:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;&nbsp;
Alternatively, the tunnel end point &nbsp;address MAY also be set to =
the&nbsp;destination
data plane address if the &nbsp;ingress knows that address or the TE =
Router ID.</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>New
&nbsp;text:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;&nbsp;
Alternatively, the tunnel end point address MAY &nbsp;also be set to
thedestination data plane &nbsp;address if the ingress knows that =
address.</span></font>
<br>
<font face=3Dsans-serif><span =
style=3D'font-family:sans-serif'>&nbsp;</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>2.
In section 4.2.2&nbsp;previous text:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;&nbsp;
Alternatively, &nbsp;the tunnel sender address MAY also be set to =
thesender
data plane address or the TE Router ID.</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>New
&nbsp;text:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>&nbsp;&nbsp;
Alternatively, the tunnel sender address MAY also &nbsp;be set to =
thesender
data plane &nbsp;address.</span></font> <br>
<font face=3Dsans-serif><span =
style=3D'font-family:sans-serif'>&nbsp;</span></font>
<br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>3.&nbsp;at
the end of the introduction,&nbsp;we will add &nbsp;wording to the last =
line to
that effect:</span></font> <br>
<font size=3D2 face=3Dsans-serif><span =
style=3D'font-size:10.0pt;font-family:sans-serif'>Various
more complex deployment scenarios can be &nbsp;constructed but these are
currently out of scope&nbsp;as the only&nbsp;GMPLS implementations =
encountered
ininteroperability testing or in deployment have &nbsp;applied this
relationship.&nbsp;Whennew &nbsp;implementations that include any other
relationship between controlplane and data plane entities are =
encountered, &nbsp;this
document&nbsp;would beenhanced as &nbsp;necessary.</span></font> <br>
<br>
<br>
<o:p></o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0030_01C54B30.4BF83BC0--





Envelope-to: [e-mail]
Delivery-date: Wed, 27 Apr 2005 15:44:55 +0000
MIME-Version: 1.0
Sensitivity: 
To: [e-mail]
Cc: "\"\"'ccamp'\" <ccamp\"" <[e-mail]>, "\"\"'Kohei Shiomoto'\" <shiomoto.kohei\"" <[e-mail]>, "\"\"'Rajiv Papneja'\" <rpapneja\"" <[e-mail]>
Subject: RE: Addressing doc
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 27 Apr 2005 17:42:14 +0200
Content-Type: multipart/alternative; boundary="=_alternative 005650ECC1256FF0_="

This is a multipart message in MIME format.
--=_alternative 005650ECC1256FF0_=
Content-Type: text/plain; charset="us-ascii"

Richiard,
                     IMHO also a section (or sub-section) dedicated to LMP 
usage could be very useful in order to clarify how LMP can help in 
addressing resolution.

BR

D


Sent by:        [e-mail]
To:     "'ccamp'" <[e-mail]>
cc:     "'Kohei Shiomoto'" <[e-mail]>, "'Richard Rabbat'" 
<[e-mail]>, "'Rajiv Papneja'" <[e-mail]> 

Subject:        RE: Addressing doc



Hi all,
 
The editors have been having various discussions  with people about some 
oftheir issues  with this draft. In order to clarify a some  points here 
are some of thechanges that  we plan tomake to the next version  of the 
draft. We hope thiswill help  to clarify the draft.
 
1. In section 4.2.1,  previous text:
   Alternatively, the tunnel end point  address MAY also be set to 
the destination data plane address if the  ingress knows that address or 
the TE Router ID.
New  text:
   Alternatively, the tunnel end point address MAY  also be set to 
thedestination data plane  address if the ingress knows that address.
 
2. In section 4.2.2 previous text:
   Alternatively,  the tunnel sender address MAY also be set to thesender 
data plane address or the TE Router ID.
New  text:
   Alternatively, the tunnel sender address MAY also  be set to thesender 
data plane  address.
 
3. at the end of the introduction, we will add  wording to the last line 
to that effect:
Various more complex deployment scenarios can be  constructed but these 
are currently out of scope as the only GMPLS implementations encountered 
ininteroperability testing or in deployment have  applied this 
relationship. Whennew  implementations that include any other relationship 
between controlplane and data plane entities are encountered,  this 
document would beenhanced as  necessary.




--=_alternative 005650ECC1256FF0_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Richiard,</font>
<br><font size=2 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;IMHO also a section (or sub-section) dedicated to LMP usage could be very useful in order to clarify how LMP can help in addressing resolution.</font>
<br>
<br><font size=2 face="sans-serif">BR</font>
<br>
<br><font size=2 face="sans-serif">D</font>
<br>
<br>
<p><font size=1 color=#800080 face="sans-serif">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</font>
<p><font size=1 color=#800080 face="sans-serif">To: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;'ccamp'&quot; &lt;[e-mail]&gt;</font>
<br><font size=1 color=#800080 face="sans-serif">cc: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">&quot;'Kohei Shiomoto'&quot; &lt;[e-mail]&gt;, &quot;'Richard Rabbat'&quot; &lt;[e-mail]&gt;, &quot;'Rajiv Papneja'&quot; &lt;[e-mail]&gt;</font><font size=1 color=#800080 face="sans-serif"> </font>
<br>
<br><font size=1 color=#800080 face="sans-serif">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</font><font size=1 face="sans-serif">RE: Addressing doc</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Hi&nbsp;all,</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">The editors have been having various discussions &nbsp;with people about some oftheir issues &nbsp;with this draft.&nbsp;In order to clarify a some &nbsp;points here are some of thechanges that &nbsp;we plan tomake to the next version &nbsp;of the draft. We hope thiswill help &nbsp;to&nbsp;clarify the draft.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">1. In section 4.2.1, &nbsp;previous text:</font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; Alternatively, the tunnel end point &nbsp;address MAY also be set to the&nbsp;destination data plane address if the &nbsp;ingress knows that address or the TE Router ID.</font>
<br><font size=2 face="sans-serif">New &nbsp;text:</font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; Alternatively, the tunnel end point address MAY &nbsp;also be set to thedestination data plane &nbsp;address if the ingress knows that address.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">2. In section 4.2.2&nbsp;previous text:</font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; Alternatively, &nbsp;the tunnel sender address MAY also be set to thesender data plane address or the TE Router ID.</font>
<br><font size=2 face="sans-serif">New &nbsp;text:</font>
<br><font size=2 face="sans-serif">&nbsp;&nbsp; Alternatively, the tunnel sender address MAY also &nbsp;be set to thesender data plane &nbsp;address.</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">3.&nbsp;at the end of the introduction,&nbsp;we will add &nbsp;wording to the last line to that effect:</font>
<br><font size=2 face="sans-serif">Various more complex deployment scenarios can be &nbsp;constructed but these are currently out of scope&nbsp;as the only&nbsp;GMPLS implementations encountered ininteroperability testing or in deployment have &nbsp;applied this relationship.&nbsp;Whennew &nbsp;implementations that include any other relationship between controlplane and data plane entities are encountered, &nbsp;this document&nbsp;would beenhanced as &nbsp;necessary.</font>
<br>
<br>
<br>
<br>
--=_alternative 005650ECC1256FF0_=--



Envelope-to: [e-mail]
Delivery-date: Tue, 26 Apr 2005 17:46:15 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'ccamp'" <[e-mail]>, "'Kohei Shiomoto'" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>
Subject: RE: Addressing doc
Date: Tue, 26 Apr 2005 13:43:37 -0400
Message-ID: <000601c54a87$7d2eb2e0$0d10a485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dimitri,

Yes, this will sync up the language.

As for "complex", the Merriam-Webster dictionary says:
Complex: 
1: a whole made up of complicated or interrelated parts 

In this draft, interrelated parts. 

The complex case may still be simple :)

Richard.

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] 
> Sent: Tuesday, April 26, 2005 12:54 PM
> To: Richard Rabbat
> Cc: 'ccamp'; 'Kohei Shiomoto'; 'Richard Rabbat'; 'Rajiv Papneja'
> Subject: RE: Addressing doc
> 
> 
> 
> richard, would it be possible to adapt the following sentence 
> as well ?
> 
> "  A Path message is sent to the next hop node.  It is 
> RECOMMENDED that
>    the TE router ID of the next hop node be used as an IP destination
>    address in the packet that carries the RSVP-TE message. "
> 
> as
> 
> "  A Path message is sent to the next hop node.  It is 
> RECOMMENDED that
>    a stable IP address of the next hop node be used as the IP 
> destination
>    address of the packet that carries the RSVP-TE message. 
> This address
>    MAY be the TE router ID of the next hop node or a 
> reachable next-hop
>    (stable) IP address."
> 
> Resv message destination address should be adapted along the 
> same line, ...
> 
> by the way why scenarios that were not tested during this event are
> de-facto "more complex" ?
> 
> ---
> 
> Hi all,
> 
> The editors have been having various discussions with people 
> about some of
> their issues with this draft. In order to clarify a some 
> points here are
> some of the changes that we plan to make to the next version 
> of the draft.
> We hope this will help to clarify the draft.
> 
> 1. In section 4.2.1, previous text:
>    Alternatively, the tunnel end point address MAY also be set to the
> destination data plane address if the ingress knows that 
> address or the TE
> Router ID.
> New text:
>    Alternatively, the tunnel end point address MAY also be set to the
> destination data plane address if the ingress knows that address.
> 
> 2. In section 4.2.2 previous text:
>    Alternatively, the tunnel sender address MAY also be set 
> to the sender
> data plane address or the TE Router ID.
> New text:
>    Alternatively, the tunnel sender address MAY also be set 
> to the sender
> data plane address.
> 
> 3. at the end of the introduction, we will add wording to the 
> last line to
> that effect:
> Various more complex deployment scenarios can be constructed 
> but these are
> currently out of scope as the only GMPLS implementations 
> encountered in
> interoperability testing or in deployment have applied this 
> relationship.
> When new implementations that include any other relationship between
> control plane and data plane entities are encountered, this 
> document would
> be enhanced as necessary.
> 
> 
> 




Envelope-to: [e-mail]
Delivery-date: Tue, 26 Apr 2005 16:54:45 +0000
To: "Richard Rabbat" <[e-mail]>
Cc: "'ccamp'" <[e-mail]>, "'Kohei Shiomoto'" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>
From: [e-mail]
Subject: RE: Addressing doc
MIME-Version: 1.0
Date: Tue, 26 Apr 2005 18:54:12 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

richard, would it be possible to adapt the following sentence as well ?

"  A Path message is sent to the next hop node.  It is RECOMMENDED that
   the TE router ID of the next hop node be used as an IP destination
   address in the packet that carries the RSVP-TE message. "

as

"  A Path message is sent to the next hop node.  It is RECOMMENDED that
   a stable IP address of the next hop node be used as the IP destination
   address of the packet that carries the RSVP-TE message. This address
   MAY be the TE router ID of the next hop node or a reachable next-hop
   (stable) IP address."

Resv message destination address should be adapted along the same line, ...

by the way why scenarios that were not tested during this event are
de-facto "more complex" ?

---

Hi all,

The editors have been having various discussions with people about some of
their issues with this draft. In order to clarify a some points here are
some of the changes that we plan to make to the next version of the draft.
We hope this will help to clarify the draft.

1. In section 4.2.1, previous text:
   Alternatively, the tunnel end point address MAY also be set to the
destination data plane address if the ingress knows that address or the TE
Router ID.
New text:
   Alternatively, the tunnel end point address MAY also be set to the
destination data plane address if the ingress knows that address.

2. In section 4.2.2 previous text:
   Alternatively, the tunnel sender address MAY also be set to the sender
data plane address or the TE Router ID.
New text:
   Alternatively, the tunnel sender address MAY also be set to the sender
data plane address.

3. at the end of the introduction, we will add wording to the last line to
that effect:
Various more complex deployment scenarios can be constructed but these are
currently out of scope as the only GMPLS implementations encountered in
interoperability testing or in deployment have applied this relationship.
When new implementations that include any other relationship between
control plane and data plane entities are encountered, this document would
be enhanced as necessary.





Envelope-to: [e-mail]
Delivery-date: Tue, 26 Apr 2005 16:26:24 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'ccamp'" <[e-mail]>
Cc: "'Kohei Shiomoto'" <[e-mail]>, "'Richard Rabbat'" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>
Subject: RE: Addressing doc
Date: Tue, 26 Apr 2005 12:22:52 -0400
Message-ID: <000001c54a7c$32ed9bc0$0810a485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C54A5A.ABDBFBC0"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C54A5A.ABDBFBC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
The editors have been having various discussions with people about some =
of
their issues with this draft. In order to clarify a some points here are
some of the changes that we plan to make to the next version of the =
draft.
We hope this will help to clarify the draft.
=20
1. In section 4.2.1, previous text:
   Alternatively, the tunnel end point address MAY also be set to the
destination data plane address if the ingress knows that address or the =
TE
Router ID.
New text:
   Alternatively, the tunnel end point address MAY also be set to the
destination data plane address if the ingress knows that address.
=20
2. In section 4.2.2 previous text:
   Alternatively, the tunnel sender address MAY also be set to the =
sender
data plane address or the TE Router ID.
New text:
   Alternatively, the tunnel sender address MAY also be set to the =
sender
data plane address.
=20
3. at the end of the introduction, we will add wording to the last line =
to
that effect:
Various more complex deployment scenarios can be constructed but these =
are
currently out of scope as the only GMPLS implementations encountered in
interoperability testing or in deployment have applied this =
relationship.
When new implementations that include any other relationship between =
control
plane and data plane entities are encountered, this document would be
enhanced as necessary.



------=_NextPart_000_0001_01C54A5A.ABDBFBC0
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.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D948020716-26042005>Hi&nbsp;all,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D948020716-26042005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The editors have been having various =
discussions=20
with people about some of<SPAN class=3D948020716-26042005> </SPAN>their =
issues=20
with this draft.&nbsp;<SPAN class=3D948020716-26042005>In order to =
clarify a some=20
points here are some of the</SPAN><SPAN class=3D948020716-26042005> =
</SPAN><SPAN=20
class=3D948020716-26042005>changes </SPAN><SPAN =
class=3D948020716-26042005>that=20
</SPAN>we plan to<SPAN class=3D948020716-26042005> </SPAN>make to the =
next version=20
of the draft. We hope this<SPAN class=3D948020716-26042005> </SPAN>will =
help=20
to&nbsp;<SPAN class=3D948020716-26042005>clarify </SPAN>the =
draft.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. In section 4.2.1<SPAN =
class=3D948020716-26042005>,=20
previous text:</SPAN><BR>&nbsp;&nbsp; Alternatively, the tunnel end =
point=20
address MAY also be set to the<SPAN=20
class=3D948020716-26042005>&nbsp;</SPAN>destination data plane address =
if the=20
ingress knows that address or the TE Router ID.<BR><SPAN=20
class=3D948020716-26042005></SPAN>N<SPAN class=3D948020716-26042005>ew=20
text:</SPAN><BR>&nbsp;&nbsp; Alternatively, the tunnel end point address =
MAY=20
also be set to the<SPAN class=3D948020716-26042005> </SPAN>destination =
data plane=20
address if the ingress knows that address.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. In section 4.2.2&nbsp;<SPAN=20
class=3D948020716-26042005>previous text:</SPAN><BR>&nbsp;&nbsp; =
Alternatively,=20
the tunnel sender address MAY also be set to the<SPAN =
class=3D948020716-26042005>=20
</SPAN>sender data plane address or the TE Router ID.<BR><SPAN=20
class=3D948020716-26042005></SPAN>N<SPAN class=3D948020716-26042005>ew=20
text:</SPAN><BR>&nbsp;&nbsp; Alternatively, the tunnel sender address =
MAY also=20
be set to the<SPAN class=3D948020716-26042005> </SPAN>sender data plane=20
address.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT><FONT face=3DArial><FONT size=3D2>3.&nbsp;<SPAN=20
class=3D948020716-26042005>at the end of the </SPAN><SPAN=20
class=3D948020716-26042005>introduction,&nbsp;</SPAN><SPAN=20
class=3D948020716-26042005>w</SPAN><SPAN class=3D948020716-26042005>e =
will add=20
wording to the last line to that effect:</SPAN><BR><SPAN=20
class=3D948020716-26042005>Various more complex deployment scenarios can =
be=20
constructed but these are currently out of scope&nbsp;</SPAN><SPAN=20
class=3D948020716-26042005>as </SPAN>the only&nbsp;<SPAN=20
class=3D948020716-26042005>GMPLS </SPAN>implementations encountered =
in<SPAN=20
class=3D948020716-26042005> </SPAN>interoperability testing or in =
deployment have=20
applied this relationship.<SPAN =
class=3D948020716-26042005>&nbsp;When</SPAN> new=20
implementations that include any other relationship between control<SPAN =

class=3D948020716-26042005> </SPAN>plane and data plane entities are =
encountered,=20
this document&nbsp;<SPAN class=3D948020716-26042005>would </SPAN>be<SPAN =

class=3D948020716-26042005> </SPAN>enhanced as=20
necessary.<BR><BR></FONT></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0001_01C54A5A.ABDBFBC0--




Envelope-to: [e-mail]
Delivery-date: Mon, 25 Apr 2005 20:22:51 +0000
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
Cc: Adrian Farrel <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
Subject: Re: Addressing doc
Date: Mon, 25 Apr 2005 16:18:24 -0400
To: [e-mail]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


	I am in favor of this draft progressing.

	--Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCbVCQHwfkLUURkkwRAlVFAJ9AB0rxoOSlSoNxap5Zskrsn0iYKwCgp1Fw
9hFYZvRdZ7p8MzN499KxgA0=
=p8Ae
-----END PGP SIGNATURE-----



Envelope-to: [e-mail]
Delivery-date: Mon, 25 Apr 2005 15:58:39 +0000
Message-ID: <01e701c549af$a2b78dd0$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Amit 70405" <[e-mail]>, <[e-mail]>
Subject: Re: About using LMP for Address translation
Date: Mon, 25 Apr 2005 16:47:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Amit,

> > Below are the steps involved in signaling:
> >
> > - When a PATH message is received with a ERO(containing data plane
> > hops) the outgoing PATH message should be double IP encapsulated.
> > The top IP header destination should be TE router Id of the data next
> > hop.
>
> 1. See above for double encapsulation.
>
> 2. The use of the TE Router ID here is the basis for the debate.
> The authors of the addressing draft are suggesting that the use of the
> TE Router ID provides a well-known and stable routable control plane
> address and are suggesting that its use be RECOMMENDED.
> Dimitri has pointed out that *any* control plane address is adequate but
> that it is sensible to use a stable routable control plane address.
>
> <Amit> TE Router Id is the only common IP shared by Data and control
> plane. If we have to use anyother control plane IP, then resolving the
> TE-Link to Control plane IP(using TEDB) would be a bit impossible. As
> TEDB will most probably have TE router Id info, and no any other control
> plane IP.

I like "a bit impossible" :-)
If the information is not in the TED, then you clearly can't use the TED.
However, the information can be deduced from IGP advertisements.
Further, it could come from other sources.

No-one is saying that you MUST use a different address.
Dimitiri is just saying that there is no reason to prohibit the use of
another address.


> > - Once the TE Router ID has been determined, the RSVP message can be
> > sent out (based on the routing table entry for the data next hop TE
> > Router ID) through the control channel.
>
> Basically right, but I'd pick up on a few of your words. You say "based
> on the routing table entry for the data next hop TE Router ID" and this
may
> be confusing. I think what you mean is "based on the (control plane)
> routing table entry for the TE Router ID of the data next hop".
>
> <Amit> According to me, routing table is necessary only for Control
> Plane network in case of out-of-band signaling.

You are welcome to hold that opinion.

Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 25 Apr 2005 08:59:18 +0000
Date: Mon, 25 Apr 2005 14:27:44 +0530
From: Amit G <[e-mail]>
Subject: RE: About using LMP for Address translation
To: 'Adrian Farrel' <[e-mail]>, [e-mail]
Reply-to: [e-mail]
Message-id: <00ce01c54974$d8cc9f90$[e-mail]>
Organization: Huawei
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Adrian,
	Thanks for your reply.
	Plz see below my inline reply.
Thanks,
Amit.


-----Original Message-----
From: Adrian Farrel [mailto:[e-mail]] 
Sent: Saturday, April 23, 2005 7:55 PM
To: Amit 70405; [e-mail]
Subject: Re: About using LMP for Address translation

Hi Amit,

Sorry that your email got a bit lost in the background noise :-)

> Looking at the current discussion on Addressing I am bit confused
about
the Addressing in GMPLS.

You are not the only one!


> According to me in out-of-band signaling, RSVP messages should be
double
IP encapsulated with destination the as the data next hop TE router id.

"Double IP encapsulated"???
Do you mean RSVP in IP in IP? If that is what you mean, you are wrong.
You MAY use any encapsulation you like, but it is wrong to say SHOULD.
It is adequate to use RSVP in IP.

<Amit> Agreed.

> Below are the steps involved in signaling:
>
> - When a PATH message is received with a ERO(containing data plane
hops)
the outgoing PATH message should be double IP encapsulated.
> The top IP header destination should be TE router Id of the data next
hop.

1. See above for double encapsulation.

2. The use of the TE Router ID here is the basis for the debate.
The authors of the addressing draft are suggesting that the use of the
TE
Router ID provides a well-known and stable routable control plane
address
and are suggesting that its use be RECOMMENDED.
Dimitri has pointed out that *any* control plane address is adequate but
that it is sensible to use a stable routable control plane address.

<Amit> TE Router Id is the only common IP shared by Data and control
plane. If we have to use anyother control plane IP, then resolving the
TE-Link to Control plane IP(using TEDB) would be a bit impossible. As
TEDB will most probably have TE router Id info, and no any other control
plane IP.


> - The data next hop TE router ID can be obtained by resolving the data
hop in the ER0. This can be done by using TEDB.

It is certainly true that the TE Router ID has been advertised in close
conjunction to the TE link addresses. 

> - Once the TE Router ID has been determined, the RSVP message can be
sent out (based on the routing table entry for the data next hop TE
Router
ID) through the control channel.

Basically right, but I'd pick up on a few of your words. You say "based
on
the routing table entry for the data next hop TE Router ID" and this may
be confusing. I think what you mean is "based on the (control plane)
routing table entry for the TE Router ID of the data next hop".

<Amit> According to me, routing table is necessary only for Control
Plane network in case of out-of-band signaling.

Cheers,
Adrian


> If LMP is used for resolving the translation from data plane address
to
Control plane address, there has to be a 1:1 correspondance between
control & data Plane.
>
> If the translation is done based on the Routing table as I mentioned
above, there need not be any 1:1 correspondance.
>
> Plz let me know your views on this.
>
> Thanks and Regards,
> Amit.




Envelope-to: [e-mail]
Delivery-date: Sun, 24 Apr 2005 14:57:43 +0000
Message-ID: <011e01c548dd$f1b01bf0$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Proposed liaison to ITU-T SG15
Date: Sun, 24 Apr 2005 15:52:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

ITU-T SG15 is meeting in May and we should let them know about the work of
the "joint" design team on ASON Routing. This DT has just produced
draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt, and we would (of course)
welcome the input of the ITU-T.

Below is a liaison I propose to send. Please comment on the list or
privately within the next week.

Thanks,
Adrian
---
To: Kam Lam, Rapporteur of ITU-T Question 14/15
From: Adrian Farrel and Kireeti Kompella, IETF CCAMP Co-Chairs
Subject: Evaluation of IETF Routing Protocols in the Context of ASON
Routing Requirements
For: Action
Deadline: 30th May 2005

Dear Kam,

As you will be aware a Design Team has been working to evaluate the
existing IP-based routing protocols with a view to discovering their
applicability to the requirements of the ASON architecture and
establishing what, if any protocol extensions are required. This design
team operates under the umbrella of the CCAMP working group within the
IETF and is made up of people drawn equally from the IETF and ITU-T
communities.

The purpose of this liaison is to make you aware of the progress of the
Design Team, and to solicit input from Q14/15 in the form of review
feedback on the latest output of the Design Team which can be found at
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt.

The CCAMP working group will soon consider collaborating with other IETF
working groups within the Routing Area to provide adequate solutions for
the identified ASON routing capabilities.

Best regards,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 23 Apr 2005 14:46:21 +0000
Message-ID: <001c01c54813$1bedb970$1c849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Amit 70405" <[e-mail]>, <[e-mail]>
Subject: Re: About using LMP for Address translation
Date: Sat, 23 Apr 2005 15:25:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Amit,

Sorry that your email got a bit lost in the background noise :-)

> Looking at the current discussion on Addressing I am bit confused about
the Addressing in GMPLS.

You are not the only one!

> According to me in out-of-band signaling, RSVP messages should be double
IP encapsulated with destination the as the data next hop TE router id.

"Double IP encapsulated"???
Do you mean RSVP in IP in IP? If that is what you mean, you are wrong.
You MAY use any encapsulation you like, but it is wrong to say SHOULD.
It is adequate to use RSVP in IP.

> Below are the steps involved in signaling:
>
> - When a PATH message is received with a ERO(containing data plane hops)
the outgoing PATH message should be double IP encapsulated.
> The top IP header destination should be TE router Id of the data next
hop.

1. See above for double encapsulation.

2. The use of the TE Router ID here is the basis for the debate.
The authors of the addressing draft are suggesting that the use of the TE
Router ID provides a well-known and stable routable control plane address
and are suggesting that its use be RECOMMENDED.
Dimitri has pointed out that *any* control plane address is adequate but
that it is sensible to use a stable routable control plane address.

> - The data next hop TE router ID can be obtained by resolving the data
hop in the ER0. This can be done by using TEDB.

It is certainly true that the TE Router ID has been advertised in close
conjunction to the TE link addresses.

> - Once the TE Router ID has been determined, the RSVP message can be
sent out (based on the routing table entry for the data next hop TE Router
ID) through the control channel.

Basically right, but I'd pick up on a few of your words. You say "based on
the routing table entry for the data next hop TE Router ID" and this may
be confusing. I think what you mean is "based on the (control plane)
routing table entry for the TE Router ID of the data next hop".

Cheers,
Adrian


> If LMP is used for resolving the translation from data plane address to
Control plane address, there has to be a 1:1 correspondance between
control & data Plane.
>
> If the translation is done based on the Routing table as I mentioned
above, there need not be any 1:1 correspondance.
>
> Plz let me know your views on this.
>
> Thanks and Regards,
> Amit.




Envelope-to: [e-mail]
Delivery-date: Sat, 23 Apr 2005 01:12:23 +0000
Message-Id: <[e-mail]>
Date: Sat, 23 Apr 2005 10:10:05 +0900
To: Kireeti Kompella <[e-mail]>
From: Wataru Imajuku <[e-mail]>
Subject: Re: Addressing doc
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Kiretti

  Yes.

W. Imajuku

A new version of this draft has been posted as
draft-shiomoto-ccamp-gmpls-addressing-01.txt .
Please reply to this email on whether or not you think this should be
a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
received until Fri April 22, 23:59 UTC.
Thanks,
Kireeti.
-------

---------------------------------
Wataru Imajuku
@NTT Network Innovation Labs.
TEL [phone]
FAX [phone] 




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 19:51:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Fri, 22 Apr 2005 15:49:53 -0400
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAu10cAAWOkqoAABeLbg
From: "Ong, Lyndon" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Deborah,

?? happy that you chose to keep a copy of the iw draft around,
given that it expired last fall :o)  However, your copy may
be different from mine, mine only has a reference to 3209 when
discussing the extended tunnel ID in the SESSION object, not the=20
end point address.  Not sure what you see being paraphrased.

Also I suspect that RFC 3209 is referenced in the
addressing draft because it gives the format and rules for using=20
the SESSION object, while RFC 3473 does not discuss the SESSION object.  =

Maybe you're thinking of the RSVP_HOP object?

I did not think that "data plane" was used to reference anything
in the GMPLS control plane within the addressing draft, but
if you've found points where you think "control plane" and "data
plane" are being used incorrectly, please point them out to the
authors so that these can be clarified in the next version.  It
can get very confusing in GMPLS.

Cheers,

Lyndon=20



-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
Sent: Friday, April 22, 2005 11:55 AM
To: Ong, Lyndon; Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Lyndon,

Glad to hear it is not on G7713.1 INNI. As I noted the terminology is
confusing on it's references to control plane (when referencing the
control channel) and data plane (when referencing the GMPLS control
plane) e.g. as the following in 4.2.1 on the Session Object:
"It is recommended that the ..end point address in the Session Object
[RFC3209] be set to the TE Router ID of the egress...alternatively, the
tunnel end point address MAY also be set to the destination data plane
address if the ingress knows that address or the TE Router ID."

Which is a paraphrase of the recommendation in
draft-ong-ccamp-3473-3474-iw-01. Including the reference to [RFC3209]
instead of RFC3473 (which recommends the use of the destination data
plane address in the Session). Hopefully this text will be aligned with
3473 in it's respin.

Thanks,
Deborah



-----Original Message-----
From: Ong, Lyndon [mailto:[e-mail]]=20
Sent: Thursday, April 21, 2005 12:56 AM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Deborah,

Oh no! :-0  The discussion has been contaminated by OIF!

Seriously, the draft does not mention "OIF" anywhere - you're welcome to
search through it.   The terminology (and any confusion)is all GMPLS, as
is 99% of the testing at Isocore.  I would also note that the authors of
the draft talked to a number of people within CCAMP to try and pin
down the usage of the TE Router ID and this appeared to be the most
common
view at the time (however it was an incomplete sample, and importantly
did not include Dimitri and Igor's input).

The issue has nothing to do with the Gen_UNI, as far as I know, as this
is
for separation of user and network addressing spaces (as Jonathan points
out).

Cheers,

Lyndon

 =20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 2:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel =
names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]













Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 18:55:46 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Fri, 22 Apr 2005 13:54:57 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAu10cAAWOkqoA==
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Ong, Lyndon" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Lyndon,

Glad to hear it is not on G7713.1 INNI. As I noted the terminology is
confusing on it's references to control plane (when referencing the
control channel) and data plane (when referencing the GMPLS control
plane) e.g. as the following in 4.2.1 on the Session Object:
"It is recommended that the ..end point address in the Session Object
[RFC3209] be set to the TE Router ID of the egress...alternatively, the
tunnel end point address MAY also be set to the destination data plane
address if the ingress knows that address or the TE Router ID."

Which is a paraphrase of the recommendation in
draft-ong-ccamp-3473-3474-iw-01. Including the reference to [RFC3209]
instead of RFC3473 (which recommends the use of the destination data
plane address in the Session). Hopefully this text will be aligned with
3473 in it's respin.

Thanks,
Deborah



-----Original Message-----
From: Ong, Lyndon [mailto:[e-mail]]=20
Sent: Thursday, April 21, 2005 12:56 AM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Deborah,

Oh no! :-0  The discussion has been contaminated by OIF!

Seriously, the draft does not mention "OIF" anywhere - you're welcome to
search through it.   The terminology (and any confusion)is all GMPLS, as
is 99% of the testing at Isocore.  I would also note that the authors of
the draft talked to a number of people within CCAMP to try and pin
down the usage of the TE Router ID and this appeared to be the most
common
view at the time (however it was an incomplete sample, and importantly
did not include Dimitri and Igor's input).

The issue has nothing to do with the Gen_UNI, as far as I know, as this
is
for separation of user and network addressing spaces (as Jonathan points
out).

Cheers,

Lyndon

 =20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 2:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel =
names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]













Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 18:39:44 +0000
Reply-To: <[e-mail]>
From: "Vishal Sharma" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Fri, 22 Apr 2005 11:38:29 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Kireeti,

Yes, this document should be taken under the wings of
the WG.

The issues of terminology etc. can be better ironed out
once it is a WG document.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Kireeti Kompella
> Sent: Friday, April 15, 2005 3:22 PM
> To: [e-mail]
> Subject: Addressing doc
> 
> 
> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 16:06:33 +0000
Message-ID: <[e-mail]>
Date: Sat, 23 Apr 2005 01:06:12 +0900
From: Hidetsugu Sugiyama <[e-mail]>
Reply-To:  [e-mail]
Organization: Juniper Networks
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC:  [e-mail]
Subject: Re: Addressing doc
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

yes,

-hidet

Kireeti Kompella wrote:

> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 15:43:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE : Addressing doc
Date: Fri, 22 Apr 2005 17:43:21 +0200
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVCCmsvzgOI0sfjRnOTJ1TdqqAUuQFR4Uhw
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
To: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

Hi,

This should be a WG doc.

Regards,

JL

>-----Message d'origine-----
>De : [e-mail]=20
>[mailto:[e-mail]] De la part de Kireeti Kompella
>Envoy=E9 : samedi 16 avril 2005 00:22
>=C0 : [e-mail]
>Objet : Addressing doc
>
>
>A new version of this draft has been posted as=20
>draft-shiomoto-ccamp-gmpls-addressing-01.txt .
>
>Please reply to this email on whether or not you think this=20
>should be a CCAMP WG doc.  Adrian and I will gauge consensus=20
>based on the mail received until Fri April 22, 23:59 UTC.
>
>Thanks,
>Kireeti.
>-------
>
>



Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 15:28:07 +0000
Message-Id: <[e-mail]>
From: "Yumiko Kawashima" <[e-mail]>
To: <[e-mail]>
Subject: RE: Addressing doc
Date: Sat, 23 Apr 2005 00:26:58 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcVCCghI+dM3xpmmTC+LXgfO0kjhGwESd6wgAD67wHA=

Yes.

I believe that this ID is necessary.

Best regards,
---
Yumiko KAWASHIMA
NTT Network Service Systems Lab.
Phone: [phone]

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Juniper - Kireeti Kompella
Sent: 15 April 2005 23:22
To: [e-mail]
Subject: Addressing doc

A new version of this draft has been posted as
draft-shiomoto-ccamp-gmpls-addressing-01.txt .

Please reply to this email on whether or not you think this should be a
CCAMP WG doc.  Adrian and I will gauge consensus based on the mail received
until Fri April 22, 23:59 UTC.

Thanks,
Kireeti.
-------




Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 15:12:04 +0000
Date: Sat, 23 Apr 2005 00:11:29 +0900
From: Eiji Oki <[e-mail]>
To: Kireeti Kompella <[e-mail]>
Subject: Re: Addressing doc
Cc: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes.

Thank you.
Eiji

On Fri, 15 Apr 2005 15:22:04 -0700 (PDT)
Kireeti Kompella <[e-mail]> wrote:

> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 





Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 14:28:09 +0000
Message-ID: <[e-mail]>
Date: Fri, 22 Apr 2005 23:27:42 +0900
From: Kohei Shiomoto <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: Addressing doc
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yes.

I believe that this id is worthy of WG doc as there seems a lot of
interest from the community.

Best regards,
--
Kohei


Kireeti Kompella wrote:

> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> 

-- 
Kohei Shiomoto
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]





Envelope-to: [e-mail]
Delivery-date: Fri, 22 Apr 2005 14:20:28 +0000
Message-Id: <[e-mail]>
Date: Fri, 22 Apr 2005 23:12:14 +0900
To: "Richard Rabbat" <[e-mail]>
From: "[e-mail]" <[e-mail]>
Subject: RE: Addressing doc
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed
Content-Transfer-Encoding: 7bit

I am also in favor of progress of the document as a WG draft
not because it is just an iterest of the WG, but because
I think we can make progress with promised modification,
as well as the quickness is a key here considering that
the contents are reflecting real experiences.

Ichiro Inoue


At 23:26 05/04/19 -0400, Richard Rabbat wrote:
>We mentioned in the discussion in Minneapolis that the objective was *NOT* 
>to standardize broken implementations interwork with the correct 
>implementations.
>Agree with Igor's and your comments.
>
>In the introduction, we said:
>For the purposes of this document it is assumed that there is a 
>one-to-one correspondence between control plane and data plane entities.
>I think we covered this well. As we mentioned in the draft, "Generally 
>speaking there is a need for a module/protocol that discovers and manages 
>control plane/data plane address bindings for the address spaces to be 
>completely separated.  In this case, the TE Router ID could be just a 
>network unique number.  Mandating that TE Router ID be a reachable IP 
>address eliminates the need of the mentioned above module $B!&(Bthe next hop 
>data plane TE Router ID could be used as a destination for IP packets 
>encapsulating the LSP setup (RSVP Path) message."
>
>We will update the draft to show that we are inclusive of both the simple 
>case and the more complex case that requires the mapping that we discussed 
>above.
>
>Based on that, why not to progress it to WG draft? Moving it to WG draft 
>means that the WG is interested in the topic and wants to address the topic.
>
>Richard.
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of [e-mail]
>Sent: Sunday, April 17, 2005 10:11 AM
>To: Igor Bryskin
>Cc: [e-mail]; Kireeti Kompella; [e-mail]
>Subject: Re: Addressing doc
>
>igor, i mentioned this because when some implement - for whatever purpose 
>- a subset of capabilities and draw recommendations from this partial set, 
>these should not by any means retrofit to the complete set of capabilities 
>this protocol suite delivers or imply recommendations that would prevent 
>from using its full set
>coming to the below you have been mentioned on what this so-called 
>separation does imply is that for constructing - and LMP can be used in 
>helping this construction but this is also not mandatory - the TE topology 
>make use of the TE router ID for the identification unnumbered interfaces 
>and (abstract) nodes, (numbered interfaces are also part of this class of 
>information - but obviously does not require the use of the TE Router ID) 
>afterwards any control plane message exchange can make use of the IP 
>control plane topology as long as these messages are exchanged between 
>control plane entities that have initially advertized (i.e. as owner of) 
>this information
>hope this clarifies,
>- dimitri.
>Igor Bryskin <[e-mail]>
>Sent by: [e-mail]
>04/17/2005 05:50 MST
>
>To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella 
><[e-mail]>, [e-mail]
>bcc:
>Subject: Re: Addressing doc
>
>
>Dimitri,
>I think we are in agreement here. The only thing I
>disagree with is your statement that the document is
>not ready to be WG document for the reasons you have
>provided. I am not the author of this document and I
>let the authors tell what they think. However, the
>whole point of the document, as far as I understand
>it, is not to mandate something, rather, to provide a
>set of recommendations based on the interop tests
>experience, so that interoperability between different
>vendors would be easier to achieve. Hence, they do not
>need to spell out word RECOMMEND in every clause.
>WRT TE Router ID. Of course, IFF there is some
>knowledge or mechanism to translate TE addresses into
>control plane IP addresses, any of next hop IP
>addresses could be used as destination in RSVP Path
>message IP packet. In this case IHMO  Te Router ID
>does not even have to be routable, and full separation
>between TE and control plane name spaces could be
>achieved. I think LMP could help to do this. However,
>one cannot mandate using LMP for every link in every
>layer, especially, for IP/MPLS layer(s).
>Igor
>--- [e-mail] wrote:
> >
> > igor, my point is that if you recommend
> >
> > "  A Path message is sent to the next hop node. It
> > is RECOMMENDED that
> >    the TE router ID of the next hop node be used as
> > an IP destination
> >    address in the packet that carries the RSVP-TE
> > message. "
> >
> > and
> >
> > "  ... an unnumbered link is identified by the
> > combination of TE Router
> >   ID and a node-unique Interface ID."
> >
> > then it is clear that the following occurs
> >
> > " The reason why the TE Router ID must be a
> > reachable IP address is
> >   because in GMPLS, control and data plane
> > names/addresses are not
> >   completely separated. "
> >
> > and the only change that needs to be done in this
> > document in section 4.3
> >
> > "It is RECOMMENDED that a stable
> >    control plane IP address of the next/previous hop
> > node be used as an
> >    IP destination address in RSVP-TE message.
> >
> >    A Path message is sent to the next hop node. It
> > is RECOMMENDED that
> >    the TE router ID of the next hop node be used as
> > an IP destination
> >    address in the packet that carries the RSVP-TE
> > message."
> >
> > is to remove the second paragraph, as there is
> > nothing that mandates that
> > communication between adjacent controllers should
> > achieved through TE
> > router ID (note: reading the document you will see
> > that the section 5.2.1
> > is indeed
> > not completed just for this reason)
> >
> > in fact, this boils down to say that the TE router
> > ID is not mandatorily
> > used for hop-by-hop exchange of control messages as
> > i can build adjacencies
> > between neighboring nodes using the base IP routing
> > topology, (by the way
> > from where all restrictions that are pointed here
> > below come from ?)
> >
> > thanks,
> > - dimitri.
> > ---
> >
> > Dimitri,
> >
> > Suppose a controller has just received an RSVP Path
> > message that contains an ERO describing a path
> > computed on the head-end (properly modified, of
> > course, along the path). ERO is specified in terms
> > of
> > numbered or/and unnumbered TE links (and not IP
> > addresses). Now the processing controller needs to
> > forward the message to the controller that manages
> > first non-local ERO sub-object. The question is what
> > to set as destination in the IP header of the RSVP
> > Path message? You are saying that it should a stable
> > IP address of the controller managing the next hop.
> > Where the processing controller is supposed to get
> > this stable IP address from? All that it has is a
> > numbered or unnumbered next hop TE link ID. It is
> > not
> > guaranteed that numbered TE link ID is a routable
> > address, however, it could be easily resolved to TE
> > Router ID. In case of unnumbered TE link the TE
> > Router
> > ID is a part of the link ID. It is also guaranteed
> > that TE Router ID is a stable routable IP address of
> > the controller advertising the TE link. Hence, the
> > recommendation makes a lot of sense to me ? extract
> > TE
> > Router ID from unnumbered link ID ERO subobject or
> > resolve numbered TE link ID into TE Router ID, set
> > it
> > as destination in IP header of the RSVP Path message
> > and forward the packet ?the message will arrive at
> > the
> > controller managing next hop no matter how many
> > actual
> > IP hops the packet will make. In fact, that's how
> > the
> > control plane and data plane separation needs to be
> > supported.
> >
> > Cheers,
> > Igor
> >
> > --- [e-mail] wrote:
> > >
> > > this document is not ready as it prevents usage of
> > > the control channel
> > > separation as defined in Section 8 of RFC 3473
> > (but
> > > also representation of
> > > complex nodes)
> > >
> > > i point out here the sentences from where this can
> > > be deduced:
> > >
> > > "  A Path message is sent to the next hop node.
> > It
> > > is RECOMMENDED that
> > >    the TE router ID of the next hop node be used
> > as
> > > an IP destination
> > >    address in the packet that carries the RSVP-TE
> > > message. "
> > >
> > > combined with the following statements
> > >
> > > "  ... an unnumbered link is identified by the
> > >    combination of TE Router ID and a node-unique
> > > Interface ID."
> > >
> > > "  It is RECOMMENDED that the IP tunnel endpoint
> > > address in the Session
> > >    Object [RFC3209] be set to the TE Router ID of
> > > the egress since the
> > >    TE Router ID is a unique routable ID per node."
> > >
> > > [...]
> > >
> > > "  It is RECOMMENDED that the IP tunnel sender
> > > address in the Sender
> > >    Template Object [RFC3209] specifies the TE
> > Router
> > > ID of the ingress
> > >    since the TE Router ID is a unique routable ID
> > > per node."
> > >
> > > therefore, usage of the TE Router ID should be
> > > reviewed, such that it does
> > > not recommends the source and destination of IP
> > > packets to be the TE Router
> > > ID but simply a stable reachable control plane IP
> > > address of the
> > > next/previous hop
> > >
> > > also, there is a sentence in this document
> > >
> > > "  The reason why the TE Router ID must be a
> > > reachable IP address is
> > >    because in GMPLS, control and data plane names
> > > /addresses are not
> > >    completely separated. "
> > >
> > > my response to this is of course if you use it
> > like
> > > proposed in this
> > > document this problem occurs
> > >
> > > ps:
> > >
> > > section 5.1.2 of this document is unclear wrt
> > > section 1.1 of
> > >
> >
><<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt> 
>
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Plan great trips with Yahoo! Travel: Now over 17,000
> > guides!
> > <http://travel.yahoo.com/p-travelguide>http://travel.yahoo.com/p-travelguide
> >
> >
> >
> >
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
><http://mail.yahoo.com>http://mail.yahoo.com




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 19:38:57 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
Date: Thu, 21 Apr 2005 15:37:50 -0400

--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		: Evaluation of existing Routing Protocols against ASON 
			  routing requirements
	Author(s)	: D. Papadimitriou, et al.
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt
	Pages		: 0
	Date		: 2005-4-21
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to 
   control different switching technologies as well as different 
   applications. These include support for requesting TDM connections 
   including SONET/SDH and Optical Transport Networks (OTNs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 15:18:54 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Ong, Lyndon'" <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>, "'Igor Bryskin'" <[e-mail]>, "'Diego Caviglia'" <[e-mail]>, "'Igor Bryskin <i_bryskin'" <[e-mail]>
Cc: "'ccamp'" <[e-mail]>
Subject: OIF topic
Date: Thu, 21 Apr 2005 11:17:22 -0400
Message-ID: <001101c54685$3868bcb0$0810a485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Deborah,
Thanks for reading our draft.

Kindly use this subject line to continue any discussion on the OIF =
topic.
Use the other subject line for a discussion of the addressing draft.=20

The addressing draft is not a product of the OIF and does not talk about =
OIF
signaling.
I hope Lyndon's email clarified it.
Richard.

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Ong, Lyndon
> Sent: Thursday, April 21, 2005 12:56 AM
> To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia;=20
> Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: RE: Addressing doc
>=20
>=20
> Hi Deborah,
>=20
> Oh no! :-0  The discussion has been contaminated by OIF!
>=20
> Seriously, the draft does not mention "OIF" anywhere - you're=20
> welcome to
> search through it.   The terminology (and any confusion)is=20
> all GMPLS, as
> is 99% of the testing at Isocore.  I would also note that the=20
> authors of
> the draft talked to a number of people within CCAMP to try and pin
> down the usage of the TE Router ID and this appeared to be=20
> the most common
> view at the time (however it was an incomplete sample, and importantly
> did not include Dimitri and Igor's input).
>=20
> The issue has nothing to do with the Gen_UNI, as far as I=20
> know, as this is
> for separation of user and network addressing spaces (as=20
> Jonathan points
> out).
>=20
> Cheers,
>=20
> Lyndon
>=20
>  =20
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Wednesday, April 20, 2005 2:17 PM
> To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: RE: Addressing doc
>=20
>=20
> Hi Igor, (and Kireeti, Adrian)
>=20
> A TE link with a routable control plane IP address? Routable within a
> GMPLS control plane context or within a control (channel)=20
> plane context?
> It's difficult to discuss as everyone is mixing terminology. GMPLS
> carefully distinguishes a GMPLS LSR Router ID and TE link=20
> addresses (and
> corresponding GMPLS routing) from control channel addressing (and
> corresponding routing). Adrian explained this in the email link below.
> Whereas OIF assumes a 1:1 association and flat routing of control
> channel and data topology, and resulting in an implementation of using
> the control channel addresses for their tunnel endpoints. Though then
> one would have the same issue as OIF identified, how to carry the
> "routable" network node address, resulting in Gen_UNI.
>=20
> And the difficulty with the draft is that it cycles about then to say:
> "The reason why the TE Router ID must be a reachable IP address is
> because in GMPLS, control and data plane names /addresses are not
> completely separated."
>=20
> When as Dimitri said, the draft choose this 1:1 limitation as it's
> implementation, it's not GMPLS.
>=20
> My concern with the draft is that it has several of these statements,
> mixing the discussion of control plane and data plane names/addresses
> when it is referring to control plane=3D"control channel=20
> names/addresses"
> and data plane names/addresses=3D"GMPLS control plane names/addresses =
of
> the data plane". Not using proper GMPLS terms is resulting in a repeat
> of last year's email discussion, and many other lengthy=20
> discussions e.g.
> ASON, all resulting from confusing (GMPLS TE) ERO routing and
> (signaling) control channel routing. And this draft's "mandate"
> precludes separation of the address space of a GMPLS routing plane and
> control channel routing plane which is the basis for GMPLS.
>=20
> I don't think it is ready to be used as a basis for a ccamp=20
> draft as it
> is not clear to me if this draft is based on OIF's signaling
> implementation or if it needs to be first updated to be aligned with
> GMPLS signaling terminology for readability. I'd prefer=20
> another re-spin
> before deciding.
>=20
> Deborah
>=20
>=20
> -----Original Message-----
> From: Igor Bryskin [mailto:[e-mail]]=20
> Sent: Wednesday, April 20, 2005 1:20 PM
> To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin=20
> <i_bryskin
> Cc: ccamp
> Subject: Re: Addressing doc
>=20
> Hi Deborah,
>=20
> An ERO describing a path dynamically computed on a graph built of TED
> contains TE link IDs (numbered and/or unnumbered) rather than control
> plane
> IP addresses.
> Hence, there are two choices:
> a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
> next
> hop controller IP address;
> b) use TE link IDs that are guaranteed to be routable=20
> addresses. TE Rtr
> ID
> is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
> could
> be resolved to its local TE Rtr ID. That's where (as far as I
> understand)
> the recommendation comes from.
>=20
> Igor
>=20
> ----- Original Message -----=20
> From: "Brungard, Deborah A, ALABS" <[e-mail]>
> To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
> <i_bryskin"
> <[e-mail]>
> Cc: "ccamp" <[e-mail]>
> Sent: Wednesday, April 20, 2005 11:57 AM
> Subject: RE: Addressing doc
>=20
>=20
> These threads are a return to one year ago and confusing control plane
> and (logical) data plane addressing:
> https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
> As the demo was on OIF UNI and GMPLS, the confusion is=20
> understandable as
> OIF uses different terminology, appendix 1 in the ason-signaling draft
> provides a comparison:
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
> te-ason-03
> .txt
>=20
> Below, not sure the context of your reference to non-local in this
> scenario? Is the ERO following 3473/3477? The IP header is set to the
> next hop IP controller. One doesn't need LMP for resolving TE=20
> addresses
> - they are control plane "logical" addresses.
>=20
> Deborah
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Diego Caviglia
> Sent: Wednesday, April 20, 2005 4:49 AM
> To: Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: Re: Addressing doc
>=20
>=20
> Igor,
>           my two cents to the discussion.
>=20
> In line.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
> Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26
>=20
> Sent by:    [e-mail]
>=20
>=20
> To:    [e-mail], Kireeti Kompella
>        <[e-mail]>
> cc:    [e-mail]
>=20
> Subject:    Re: Addressing doc
>=20
>=20
> Dimitri,
>=20
> Suppose a controller has just received an RSVP Path
> message that contains an ERO describing a path
> computed on the head-end (properly modified, of
> course, along the path). ERO is specified in terms of
> numbered or/and unnumbered TE links (and not IP
> addresses). Now the processing controller needs to
> forward the message to the controller that manages
> first non-local ERO sub-object. The question is what
> to set as destination in the IP header of the RSVP
> Path message?
> [dc] What about usage of the control channel addresses?  I mean having
> LMP
> running between the two nodes the TNE is able to associate one or more
> Control Channels to the TE Link.  In other words LMP is able=20
> to provide
> adress tanslation between the data plane addresses (TE Link)=20
> and control
> plane address (Control Channels).
> [CUT]
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 15:02:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Thu, 21 Apr 2005 09:59:11 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAXMYyAAATlZIAAjfS9w
From: "Sadler, Jonathan B." <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Deborah,

The GMPLS Tunnel ID is not an SNPP Name or a PC SCN Address -- it's used
to identify a connection instance, so it just needs to be a unique value
within the signaling context.

Please also understand that my comments are not related to the
addressing draft which is the real subject of this thread, but rather to
clarify the OIF protocol architecture.

Jonathan Sadler

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 5:02 PM
To: Sadler, Jonathan B.; Igor Bryskin; Diego Caviglia; Igor Bryskin
Cc: ccamp
Subject: RE: Addressing doc

Thanks Jonathan -

And what is used for the GMPLS tunnel ids? Controller IDs?

My interpretation also, the Gen_UNI provides for separation of signaling
and network addresses. Whereas using the addressing draft
recommendations prevents use of the corresponding GMPLS procedures.

Deborah

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 5:44 PM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Deborah,

Just a clarification on the OIF protocol architecture:

- the OIF does not assume a 1:1 association of Transport Names (called
SNPPs in ASON) and Control Addresses (called Protocol Controller SCN
Addresses in ASON).  The OIF protocols use Unnumbered mode objects
containing SNPP identifiers when referencing transport resources.  PC
SCN Addresses are only used to identify neighboring Protocol
Controllers, e.g. in IP headers.

- the TNAs in the Gen_UNI (called UNI Transport Resource Names in ASON)
separate the Transport Names used by Network Users to identify endpoints
from the Service Provider SNPPs.  This allows for many operational
scenarios to be supported, including allowing the Service Provider to
rearrange their signaling or transport network addressing, without
customer impact.

Hope this helps,

Jonathan Sadler

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 4:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 14:25:48 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Apr 2005 16:25:24 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
CC:  [e-mail],  Richard Rabbat <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>,  'Diego Caviglia' <[e-mail]>, 'ccamp' <[e-mail]>
Subject: Re: Addressing doc
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

igor

> I'd like to summarize a couple of simple points:
> 
> ·         It is a fact that TE Router Address advertised in the top-level TE
> RTR TLV must be a routable IP address;
 >
> ·         TE Router Address is a likely candidate to be used as TE RTR ID
> (as a part, for instance, of unnumbered TE link ERO sub-object). Indeed,
> what else can I use for this purpose if I compute a path over TE topology
> built of unnumbered TE links?

the two above point are not under discussion - what's your exact point ? 
these are consequence of the compliance to RFC 3630

> ·         The conclusion: TE RTR ID (a transport node name) is also a
> routable IP address (a controller address in DCN space). Hence, control
> plane and TE name (or data plane name space, because TE name is a data plane
> name as far as control plane is concerned) spaces are not completely
> separate in GMPLS, and this fact could be (and recommended  to be) taken
> advantage of. 

the notions of representation of a data plane endpoint in the control 
plane and data plane endpoints have been detailed in ASON documents and 
LMP transport, which very precisely explains the related aspects - the 
confusion in your text comes from the fact you are overlookng the fact 
that GMPLS does accommodate data plane technologies and operations 
providing their own addressing space or borrowing values from the one 
e.g. LMP provides based on the use of an IP-based control plane i.e. 
interface ID uses IPv4, IPv6, or unnumbered interface IDs.

> Having said that nothing mandates using TE RTR ID as a destination of RSVP 
> message IP packets. 

of course the above issues are decoupled, as explained here below

> If you have an entity/protocol like
> LMP which maintains control plane/TE name bindings, you can use any valid
> control plane name (IP address) to be used instead of TE RTR ID. 
> However, it is worth remembering that usage of LMP is not mandatory. 
> 
> The bottom line is that I don't understand what makes you draw such
> conclusions as:
> 
> (e.g. preclude complex node
> 
>>representation and/or allow exchanging IP control messages over channels
>>logically or physically disjoint from the data bearer channels)

examples have been remember to you by deborah, and are also detailed in
several documents provided that details several aspects of this problem

> Igor
> 
> 
> 
> ----- Original Message ----- 
> 
> From: "dimitri papadimitriou" <[e-mail]>
> 
> To: "Richard Rabbat" <[e-mail]>
> 
> Cc: "'Igor Bryskin'" <[e-mail]>; "'Brungard, Deborah A, ALABS'"
> <[e-mail]>; "'Diego Caviglia'" <[e-mail]>;
> "'ccamp'" <[e-mail]>
> 
> Sent: Thursday, April 21, 2005 7:11 AM
> 
> Subject: Re: Addressing doc
> 
> 
> 
> 
>>richard, all,
>>
>>just to clarify
>>
>>- the TE Router ID can be used to identify unnumbered reachable points,
>>in this case, the IP topology of the control plane, can for inst. be
>>built from the IP routing topology and the TE information exchanged
>>across this topology provides the needed information to retrieve the
>>next hop, the need for LMP is not mandatory, what, it delivers is the
>>facilitation of the construction, and injection into the local database
>>of the these TE links (note: the CC used by LMP can be common to RSVP
>>and the IGP) as well as all other goodies provided by LMP
>>
>>- the TE Router ID can also be used as source and destination for
>>RSVP-TE packets - for. inst. CCAMP produced a document on TE Router ID
>>based Hello messages - in this case the TE Router ID plays the same role
>>as for any MPLS LSR, as long as numbered interfaces can be reached from
>>this address (for unnumbered it is obviously the case) - in this context
>>the role of LMP is the same wrt level from which we speak about the
>>process here
>>
>>from this, the discussion point was simply that assuming the second
>>alternative it is indeed obvious that the statement made as part of the
>>document under discussion "The reason why the TE Router ID must be a
>>reachable IP address is because in GMPLS, control and data plane
>>names/addresses are not completely separated." is first assuming a
>>specific usage of the TE router ID and secondly it is not control vs
>>data plane address space separation issue but an IP control plane vs TE
>>information identification issue (e.g. preclude complex node
>>representation and/or allow exchanging IP control messages over channels
>>logically or physically disjoint from the data bearer channels)
>>
>>hope this clarifies,
>>- dimitri.
>>
>>Richard Rabbat wrote:
>>
>>
>>>Igor,
>>>
>>>That's what the draft wanted to say. Thanks for putting it so well.
>>>
>>>We didn't mention LMP because we wanted the draft not to be specific
> 
> only to
> 
>>>transport. We'll update the wording as I said in a next revision to
> 
> reflect
> 
>>>the 2 modes of operation.
>>>
>>>Best,
>>>Richard.
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>>[mailto:[e-mail]] On Behalf Of Igor Bryskin
>>>>Sent: Wednesday, April 20, 2005 1:20 PM
>>>>To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin
>>>><i_bryskin
>>>>Cc: ccamp
>>>>Subject: Re: Addressing doc
>>>>
>>>>
>>>>Hi Deborah,
>>>>
>>>>An ERO describing a path dynamically computed on a graph built of TED
>>>>contains TE link IDs (numbered and/or unnumbered) rather than
>>>>control plane
>>>>IP addresses.
>>>>Hence, there are two choices:
>>>>a) use some mechanism (e.g. LMP) to resolve next hop TE link
>>>>ID into next
>>>>hop controller IP address;
>>>>b) use TE link IDs that are guaranteed to be routable
>>>>addresses. TE Rtr ID
>>>>is guaranteed to be routable. Any TE link ID (numbered or
>>>>unnumbered) could
>>>>be resolved to its local TE Rtr ID. That's where (as far as I
>>>>understand)
>>>>the recommendation comes from.
>>>>
>>>>Igor
>>>>
>>>>----- Original Message ----- 
>>>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>>>To: "Diego Caviglia" <[e-mail]>; "Igor
>>>>Bryskin <i_bryskin"
>>>><[e-mail]>
>>>>Cc: "ccamp" <[e-mail]>
>>>>Sent: Wednesday, April 20, 2005 11:57 AM
>>>>Subject: RE: Addressing doc
>>>>
>>>>
>>>>These threads are a return to one year ago and confusing control plane
>>>>and (logical) data plane addressing:
>>>>https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
>>>>As the demo was on OIF UNI and GMPLS, the confusion is
>>>>understandable as
>>>>OIF uses different terminology, appendix 1 in the ason-signaling draft
>>>>provides a comparison:
>>>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
>>>>te-ason-03
>>>>.txt
>>>>
>>>>Below, not sure the context of your reference to non-local in this
>>>>scenario? Is the ERO following 3473/3477? The IP header is set to the
>>>>next hop IP controller. One doesn't need LMP for resolving TE
>>>>addresses
>>>>- they are control plane "logical" addresses.
>>>>
>>>>Deborah
>>>>
>>>>-----Original Message-----
>>>>From: [e-mail] [mailto:[e-mail]] On
>>>>Behalf Of Diego Caviglia
>>>>Sent: Wednesday, April 20, 2005 4:49 AM
>>>>To: Igor Bryskin <i_bryskin
>>>>Cc: ccamp
>>>>Subject: Re: Addressing doc
>>>>
>>>>
>>>>Igor,
>>>>         my two cents to the discussion.
>>>>
>>>>In line.
>>>>
>>>>Regards
>>>>
>>>>Diego
>>>>
>>>>
>>>>
>>>>Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26
>>>>
>>>>Sent by:    [e-mail]
>>>>
>>>>
>>>>To:    [e-mail], Kireeti Kompella
>>>>      <[e-mail]>
>>>>cc:    [e-mail]
>>>>
>>>>Subject:    Re: Addressing doc
>>>>
>>>>
>>>>Dimitri,
>>>>
>>>>Suppose a controller has just received an RSVP Path
>>>>message that contains an ERO describing a path
>>>>computed on the head-end (properly modified, of
>>>>course, along the path). ERO is specified in terms of
>>>>numbered or/and unnumbered TE links (and not IP
>>>>addresses). Now the processing controller needs to
>>>>forward the message to the controller that manages
>>>>first non-local ERO sub-object. The question is what
>>>>to set as destination in the IP header of the RSVP
>>>>Path message?
>>>>[dc] What about usage of the control channel addresses?  I mean having
>>>>LMP
>>>>running between the two nodes the TNE is able to associate one or more
>>>>Control Channels to the TE Link.  In other words LMP is able
>>>>to provide
>>>>adress tanslation between the data plane addresses (TE Link)
>>>>and control
>>>>plane address (Control Channels).
>>>>[CUT]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 13:47:09 +0000
Message-ID: <000d01c54678$6ca9bbd0$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "Richard Rabbat" <[e-mail]>
Cc: "'Brungard, Deborah A, ALABS'" <[e-mail]>, "'Diego Caviglia'" <[e-mail]>, "'ccamp'" <[e-mail]>
Subject: Re: Addressing doc
Date: Thu, 21 Apr 2005 09:45:46 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Dimitri,



I'd like to summarize a couple of simple points:

·         It is a fact that TE Router Address advertised in the top-level TE
RTR TLV must be a routable IP address;

·         TE Router Address is a likely candidate to be used as TE RTR ID
(as a part, for instance, of unnumbered TE link ERO sub-object). Indeed,
what else can I use for this purpose if I compute a path over TE topology
built of unnumbered TE links?

·         The conclusion: TE RTR ID (a transport node name) is also a
routable IP address (a controller address in DCN space). Hence, control
plane and TE name (or data plane name space, because TE name is a data plane
name as far as control plane is concerned) spaces are not completely
separate in GMPLS, and this fact could be (and recommended  to be) taken
advantage of. Having said that nothing mandates using TE RTR ID as a
destination of RSVP message IP packets. If you have an entity/protocol like
LMP which maintains control plane/TE name bindings, you can use any valid
control plane name (IP address) to be used instead of TE RTR ID. However, it
is worth remembering that usage of LMP is not mandatory.



The bottom line is that I don't understand what makes you draw such
conclusions as:

(e.g. preclude complex node
> representation and/or allow exchanging IP control messages over channels
> logically or physically disjoint from the data bearer channels)



Igor



----- Original Message ----- 

From: "dimitri papadimitriou" <[e-mail]>

To: "Richard Rabbat" <[e-mail]>

Cc: "'Igor Bryskin'" <[e-mail]>; "'Brungard, Deborah A, ALABS'"
<[e-mail]>; "'Diego Caviglia'" <[e-mail]>;
"'ccamp'" <[e-mail]>

Sent: Thursday, April 21, 2005 7:11 AM

Subject: Re: Addressing doc



> richard, all,
>
> just to clarify
>
> - the TE Router ID can be used to identify unnumbered reachable points,
> in this case, the IP topology of the control plane, can for inst. be
> built from the IP routing topology and the TE information exchanged
> across this topology provides the needed information to retrieve the
> next hop, the need for LMP is not mandatory, what, it delivers is the
> facilitation of the construction, and injection into the local database
> of the these TE links (note: the CC used by LMP can be common to RSVP
> and the IGP) as well as all other goodies provided by LMP
>
> - the TE Router ID can also be used as source and destination for
> RSVP-TE packets - for. inst. CCAMP produced a document on TE Router ID
> based Hello messages - in this case the TE Router ID plays the same role
> as for any MPLS LSR, as long as numbered interfaces can be reached from
> this address (for unnumbered it is obviously the case) - in this context
> the role of LMP is the same wrt level from which we speak about the
> process here
>
> from this, the discussion point was simply that assuming the second
> alternative it is indeed obvious that the statement made as part of the
> document under discussion "The reason why the TE Router ID must be a
> reachable IP address is because in GMPLS, control and data plane
> names/addresses are not completely separated." is first assuming a
> specific usage of the TE router ID and secondly it is not control vs
> data plane address space separation issue but an IP control plane vs TE
> information identification issue (e.g. preclude complex node
> representation and/or allow exchanging IP control messages over channels
> logically or physically disjoint from the data bearer channels)
>
> hope this clarifies,
> - dimitri.
>
> Richard Rabbat wrote:
>
> > Igor,
> >
> > That's what the draft wanted to say. Thanks for putting it so well.
> >
> > We didn't mention LMP because we wanted the draft not to be specific
only to
> > transport. We'll update the wording as I said in a next revision to
reflect
> > the 2 modes of operation.
> >
> > Best,
> > Richard.
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]] On Behalf Of Igor Bryskin
> >>Sent: Wednesday, April 20, 2005 1:20 PM
> >>To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin
> >><i_bryskin
> >>Cc: ccamp
> >>Subject: Re: Addressing doc
> >>
> >>
> >>Hi Deborah,
> >>
> >>An ERO describing a path dynamically computed on a graph built of TED
> >>contains TE link IDs (numbered and/or unnumbered) rather than
> >>control plane
> >>IP addresses.
> >>Hence, there are two choices:
> >>a) use some mechanism (e.g. LMP) to resolve next hop TE link
> >>ID into next
> >>hop controller IP address;
> >>b) use TE link IDs that are guaranteed to be routable
> >>addresses. TE Rtr ID
> >>is guaranteed to be routable. Any TE link ID (numbered or
> >>unnumbered) could
> >>be resolved to its local TE Rtr ID. That's where (as far as I
> >>understand)
> >>the recommendation comes from.
> >>
> >>Igor
> >>
> >>----- Original Message ----- 
> >>From: "Brungard, Deborah A, ALABS" <[e-mail]>
> >>To: "Diego Caviglia" <[e-mail]>; "Igor
> >>Bryskin <i_bryskin"
> >><[e-mail]>
> >>Cc: "ccamp" <[e-mail]>
> >>Sent: Wednesday, April 20, 2005 11:57 AM
> >>Subject: RE: Addressing doc
> >>
> >>
> >>These threads are a return to one year ago and confusing control plane
> >>and (logical) data plane addressing:
> >>https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
> >>As the demo was on OIF UNI and GMPLS, the confusion is
> >>understandable as
> >>OIF uses different terminology, appendix 1 in the ason-signaling draft
> >>provides a comparison:
> >>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
> >>te-ason-03
> >>.txt
> >>
> >>Below, not sure the context of your reference to non-local in this
> >>scenario? Is the ERO following 3473/3477? The IP header is set to the
> >>next hop IP controller. One doesn't need LMP for resolving TE
> >>addresses
> >>- they are control plane "logical" addresses.
> >>
> >>Deborah
> >>
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]] On
> >>Behalf Of Diego Caviglia
> >>Sent: Wednesday, April 20, 2005 4:49 AM
> >>To: Igor Bryskin <i_bryskin
> >>Cc: ccamp
> >>Subject: Re: Addressing doc
> >>
> >>
> >>Igor,
> >>          my two cents to the discussion.
> >>
> >>In line.
> >>
> >>Regards
> >>
> >>Diego
> >>
> >>
> >>
> >>Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26
> >>
> >>Sent by:    [e-mail]
> >>
> >>
> >>To:    [e-mail], Kireeti Kompella
> >>       <[e-mail]>
> >>cc:    [e-mail]
> >>
> >>Subject:    Re: Addressing doc
> >>
> >>
> >>Dimitri,
> >>
> >>Suppose a controller has just received an RSVP Path
> >>message that contains an ERO describing a path
> >>computed on the head-end (properly modified, of
> >>course, along the path). ERO is specified in terms of
> >>numbered or/and unnumbered TE links (and not IP
> >>addresses). Now the processing controller needs to
> >>forward the message to the controller that manages
> >>first non-local ERO sub-object. The question is what
> >>to set as destination in the IP header of the RSVP
> >>Path message?
> >>[dc] What about usage of the control channel addresses?  I mean having
> >>LMP
> >>running between the two nodes the TNE is able to associate one or more
> >>Control Channels to the TE Link.  In other words LMP is able
> >>to provide
> >>adress tanslation between the data plane addresses (TE Link)
> >>and control
> >>plane address (Control Channels).
> >>[CUT]
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> > .
> >
>




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 11:12:25 +0000
Message-ID: <[e-mail]>
Date: Thu, 21 Apr 2005 13:11:52 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To: Richard Rabbat <[e-mail]>
CC: 'Igor Bryskin' <[e-mail]>,  "'Brungard, Deborah A, ALABS'" <[e-mail]>, 'Diego Caviglia' <[e-mail]>,  'ccamp' <[e-mail]>
Subject: Re: Addressing doc
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

richard, all,

just to clarify

- the TE Router ID can be used to identify unnumbered reachable points, 
in this case, the IP topology of the control plane, can for inst. be 
built from the IP routing topology and the TE information exchanged 
across this topology provides the needed information to retrieve the 
next hop, the need for LMP is not mandatory, what, it delivers is the 
facilitation of the construction, and injection into the local database 
of the these TE links (note: the CC used by LMP can be common to RSVP 
and the IGP) as well as all other goodies provided by LMP

- the TE Router ID can also be used as source and destination for 
RSVP-TE packets - for. inst. CCAMP produced a document on TE Router ID 
based Hello messages - in this case the TE Router ID plays the same role 
as for any MPLS LSR, as long as numbered interfaces can be reached from 
this address (for unnumbered it is obviously the case) - in this context 
the role of LMP is the same wrt level from which we speak about the 
process here

from this, the discussion point was simply that assuming the second 
alternative it is indeed obvious that the statement made as part of the 
document under discussion "The reason why the TE Router ID must be a
reachable IP address is because in GMPLS, control and data plane
names/addresses are not completely separated." is first assuming a 
specific usage of the TE router ID and secondly it is not control vs 
data plane address space separation issue but an IP control plane vs TE 
information identification issue (e.g. preclude complex node 
representation and/or allow exchanging IP control messages over channels 
logically or physically disjoint from the data bearer channels)

hope this clarifies,
- dimitri.

Richard Rabbat wrote:

> Igor,
> 
> That's what the draft wanted to say. Thanks for putting it so well. 
> 
> We didn't mention LMP because we wanted the draft not to be specific only to
> transport. We'll update the wording as I said in a next revision to reflect
> the 2 modes of operation. 
> 
> Best,
> Richard.
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of Igor Bryskin
>>Sent: Wednesday, April 20, 2005 1:20 PM
>>To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin 
>><i_bryskin
>>Cc: ccamp
>>Subject: Re: Addressing doc
>>
>>
>>Hi Deborah,
>>
>>An ERO describing a path dynamically computed on a graph built of TED
>>contains TE link IDs (numbered and/or unnumbered) rather than 
>>control plane
>>IP addresses.
>>Hence, there are two choices:
>>a) use some mechanism (e.g. LMP) to resolve next hop TE link 
>>ID into next
>>hop controller IP address;
>>b) use TE link IDs that are guaranteed to be routable 
>>addresses. TE Rtr ID
>>is guaranteed to be routable. Any TE link ID (numbered or 
>>unnumbered) could
>>be resolved to its local TE Rtr ID. That's where (as far as I 
>>understand)
>>the recommendation comes from.
>>
>>Igor
>>
>>----- Original Message ----- 
>>From: "Brungard, Deborah A, ALABS" <[e-mail]>
>>To: "Diego Caviglia" <[e-mail]>; "Igor 
>>Bryskin <i_bryskin"
>><[e-mail]>
>>Cc: "ccamp" <[e-mail]>
>>Sent: Wednesday, April 20, 2005 11:57 AM
>>Subject: RE: Addressing doc
>>
>>
>>These threads are a return to one year ago and confusing control plane
>>and (logical) data plane addressing:
>>https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
>>As the demo was on OIF UNI and GMPLS, the confusion is 
>>understandable as
>>OIF uses different terminology, appendix 1 in the ason-signaling draft
>>provides a comparison:
>>ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
>>te-ason-03
>>.txt
>>
>>Below, not sure the context of your reference to non-local in this
>>scenario? Is the ERO following 3473/3477? The IP header is set to the
>>next hop IP controller. One doesn't need LMP for resolving TE 
>>addresses
>>- they are control plane "logical" addresses.
>>
>>Deborah
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of Diego Caviglia
>>Sent: Wednesday, April 20, 2005 4:49 AM
>>To: Igor Bryskin <i_bryskin
>>Cc: ccamp
>>Subject: Re: Addressing doc
>>
>>
>>Igor,
>>          my two cents to the discussion.
>>
>>In line.
>>
>>Regards
>>
>>Diego
>>
>>
>>
>>Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26
>>
>>Sent by:    [e-mail]
>>
>>
>>To:    [e-mail], Kireeti Kompella
>>       <[e-mail]>
>>cc:    [e-mail]
>>
>>Subject:    Re: Addressing doc
>>
>>
>>Dimitri,
>>
>>Suppose a controller has just received an RSVP Path
>>message that contains an ERO describing a path
>>computed on the head-end (properly modified, of
>>course, along the path). ERO is specified in terms of
>>numbered or/and unnumbered TE links (and not IP
>>addresses). Now the processing controller needs to
>>forward the message to the controller that manages
>>first non-local ERO sub-object. The question is what
>>to set as destination in the IP header of the RSVP
>>Path message?
>>[dc] What about usage of the control channel addresses?  I mean having
>>LMP
>>running between the two nodes the TNE is able to associate one or more
>>Control Channels to the TE Link.  In other words LMP is able 
>>to provide
>>adress tanslation between the data plane addresses (TE Link) 
>>and control
>>plane address (Control Channels).
>>[CUT]
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 10:30:20 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Thu, 21 Apr 2005 11:27:40 +0100
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVCCghI+dM3xpmmTC+LXgfO0kjhGwESd6wg
From: "Alan Davey" <[e-mail]>
To: "Juniper - Kireeti Kompella" <[e-mail]>, <[e-mail]>

Yes

Regards

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   [phone]      =20
Fax:   [phone]
Email: [e-mail] =20
Web:   http://www.dataconnection.com=20


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Juniper - Kireeti Kompella
Sent: 15 April 2005 23:22
To: [e-mail]
Subject: Addressing doc


A new version of this draft has been posted as
draft-shiomoto-ccamp-gmpls-addressing-01.txt .

Please reply to this email on whether or not you think this should be
a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
received until Fri April 22, 23:59 UTC.

Thanks,
Kireeti.
-------




Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 04:56:59 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Thu, 21 Apr 2005 00:55:52 -0400
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAu10cA=
From: "Ong, Lyndon" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Deborah,

Oh no! :-0  The discussion has been contaminated by OIF!

Seriously, the draft does not mention "OIF" anywhere - you're welcome to
search through it.   The terminology (and any confusion)is all GMPLS, as
is 99% of the testing at Isocore.  I would also note that the authors of
the draft talked to a number of people within CCAMP to try and pin
down the usage of the TE Router ID and this appeared to be the most =
common
view at the time (however it was an incomplete sample, and importantly
did not include Dimitri and Igor's input).

The issue has nothing to do with the Gen_UNI, as far as I know, as this =
is
for separation of user and network addressing spaces (as Jonathan points
out).

Cheers,

Lyndon

 =20

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 2:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc


Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel =
names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]












Envelope-to: [e-mail]
Delivery-date: Thu, 21 Apr 2005 03:28:44 +0000
Date: Thu, 21 Apr 2005 11:26:23 +0800
From: Amit 70405 <[e-mail]>
Subject: About using LMP for Address translation
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

HI All,
	Looking at the current discussion on Addressing I am bit confused about the Addressing in GMPLS.
	
	According to me in out-of-band signaling, RSVP messages should be double IP encapsulated with destination the as the data next hop TE router id.
	
	Below are the steps involved in signaling:

	- When a PATH message is received with a ERO(containing data plane hops) the outgoing PATH message should be double IP encapsulated.
	The top IP header destination should be TE router Id of the data next hop.

	- The data next hop TE router ID can be obtained by resolving the data hop in the ER0. This can be done by using TEDB.

	- Once the TE Router ID has been determined, the RSVP message can be sent out (based on the routing table entry for the data next hop TE Router ID) through the control channel.


	If LMP is used for resolving the translation from data plane address to Control plane address, ther has to be a 1:1 correspondance between control & data Plane.

	If the translation is done based on the Routing table as I mentioned above, there need not be any 1:1 correspondance.

	Plz let me know your views on this.

Thanks and Regards,
Amit.




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 22:02:12 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 17:01:31 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAXMYyAAATlZIA==
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Sadler, Jonathan B." <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Thanks Jonathan -

And what is used for the GMPLS tunnel ids? Controller IDs?

My interpretation also, the Gen_UNI provides for separation of signaling
and network addresses. Whereas using the addressing draft
recommendations prevents use of the corresponding GMPLS procedures.

Deborah

-----Original Message-----
From: Sadler, Jonathan B. [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 5:44 PM
To: Brungard, Deborah A, ALABS; Igor Bryskin; Diego Caviglia; Igor
Bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Deborah,

Just a clarification on the OIF protocol architecture:

- the OIF does not assume a 1:1 association of Transport Names (called
SNPPs in ASON) and Control Addresses (called Protocol Controller SCN
Addresses in ASON).  The OIF protocols use Unnumbered mode objects
containing SNPP identifiers when referencing transport resources.  PC
SCN Addresses are only used to identify neighboring Protocol
Controllers, e.g. in IP headers.

- the TNAs in the Gen_UNI (called UNI Transport Resource Names in ASON)
separate the Transport Names used by Network Users to identify endpoints
from the Service Provider SNPPs.  This allows for many operational
scenarios to be supported, including allowing the Service Provider to
rearrange their signaling or transport network addressing, without
customer impact.

Hope this helps,

Jonathan Sadler

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 4:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel =
names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 21:46:47 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 16:43:37 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EAAAXMYyA=
From: "Sadler, Jonathan B." <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Deborah,

Just a clarification on the OIF protocol architecture:

- the OIF does not assume a 1:1 association of Transport Names (called
SNPPs in ASON) and Control Addresses (called Protocol Controller SCN
Addresses in ASON).  The OIF protocols use Unnumbered mode objects
containing SNPP identifiers when referencing transport resources.  PC
SCN Addresses are only used to identify neighboring Protocol
Controllers, e.g. in IP headers.

- the TNAs in the Gen_UNI (called UNI Transport Resource Names in ASON)
separate the Transport Names used by Network Users to identify endpoints
from the Service Provider SNPPs.  This allows for many operational
scenarios to be supported, including allowing the Service Provider to
rearrange their signaling or transport network addressing, without
customer impact.

Hope this helps,

Jonathan Sadler

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Wednesday, April 20, 2005 4:17 PM
To: Igor Bryskin; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: RE: Addressing doc

Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]







=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 21:19:51 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 16:17:23 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFzSUGp9fyKZSGTYW0VME5Mn6VQwACk9EA
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Igor Bryskin" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

Hi Igor, (and Kireeti, Adrian)

A TE link with a routable control plane IP address? Routable within a
GMPLS control plane context or within a control (channel) plane context?
It's difficult to discuss as everyone is mixing terminology. GMPLS
carefully distinguishes a GMPLS LSR Router ID and TE link addresses (and
corresponding GMPLS routing) from control channel addressing (and
corresponding routing). Adrian explained this in the email link below.
Whereas OIF assumes a 1:1 association and flat routing of control
channel and data topology, and resulting in an implementation of using
the control channel addresses for their tunnel endpoints. Though then
one would have the same issue as OIF identified, how to carry the
"routable" network node address, resulting in Gen_UNI.

And the difficulty with the draft is that it cycles about then to say:
"The reason why the TE Router ID must be a reachable IP address is
because in GMPLS, control and data plane names /addresses are not
completely separated."

When as Dimitri said, the draft choose this 1:1 limitation as it's
implementation, it's not GMPLS.

My concern with the draft is that it has several of these statements,
mixing the discussion of control plane and data plane names/addresses
when it is referring to control plane=3D"control channel =
names/addresses"
and data plane names/addresses=3D"GMPLS control plane names/addresses of
the data plane". Not using proper GMPLS terms is resulting in a repeat
of last year's email discussion, and many other lengthy discussions e.g.
ASON, all resulting from confusing (GMPLS TE) ERO routing and
(signaling) control channel routing. And this draft's "mandate"
precludes separation of the address space of a GMPLS routing plane and
control channel routing plane which is the basis for GMPLS.

I don't think it is ready to be used as a basis for a ccamp draft as it
is not clear to me if this draft is based on OIF's signaling
implementation or if it needs to be first updated to be aligned with
GMPLS signaling terminology for readability. I'd prefer another re-spin
before deciding.

Deborah


-----Original Message-----
From: Igor Bryskin [mailto:[e-mail]]=20
Sent: Wednesday, April 20, 2005 1:20 PM
To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control
plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into
next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr
ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered)
could
be resolved to its local TE Rtr ID. That's where (as far as I
understand)
the recommendation comes from.

Igor

----- Original Message -----=20
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin
<i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]











Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 19:50:42 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Igor Bryskin'" <[e-mail]>, "'Brungard, Deborah A, ALABS'" <[e-mail]>, "'Diego Caviglia'" <[e-mail]>
Cc: "'ccamp'" <[e-mail]>
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 15:48:20 -0400
Message-ID: <001101c545e1$e8532b50$1c10a485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Igor,

That's what the draft wanted to say. Thanks for putting it so well.=20

We didn't mention LMP because we wanted the draft not to be specific =
only to
transport. We'll update the wording as I said in a next revision to =
reflect
the 2 modes of operation.=20

Best,
Richard.


> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Igor Bryskin
> Sent: Wednesday, April 20, 2005 1:20 PM
> To: Brungard, Deborah A, ALABS; Diego Caviglia; Igor Bryskin=20
> <i_bryskin
> Cc: ccamp
> Subject: Re: Addressing doc
>=20
>=20
> Hi Deborah,
>=20
> An ERO describing a path dynamically computed on a graph built of TED
> contains TE link IDs (numbered and/or unnumbered) rather than=20
> control plane
> IP addresses.
> Hence, there are two choices:
> a) use some mechanism (e.g. LMP) to resolve next hop TE link=20
> ID into next
> hop controller IP address;
> b) use TE link IDs that are guaranteed to be routable=20
> addresses. TE Rtr ID
> is guaranteed to be routable. Any TE link ID (numbered or=20
> unnumbered) could
> be resolved to its local TE Rtr ID. That's where (as far as I=20
> understand)
> the recommendation comes from.
>=20
> Igor
>=20
> ----- Original Message -----=20
> From: "Brungard, Deborah A, ALABS" <[e-mail]>
> To: "Diego Caviglia" <[e-mail]>; "Igor=20
> Bryskin <i_bryskin"
> <[e-mail]>
> Cc: "ccamp" <[e-mail]>
> Sent: Wednesday, April 20, 2005 11:57 AM
> Subject: RE: Addressing doc
>=20
>=20
> These threads are a return to one year ago and confusing control plane
> and (logical) data plane addressing:
> https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
> As the demo was on OIF UNI and GMPLS, the confusion is=20
> understandable as
> OIF uses different terminology, appendix 1 in the ason-signaling draft
> provides a comparison:
> ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-
> te-ason-03
> .txt
>=20
> Below, not sure the context of your reference to non-local in this
> scenario? Is the ERO following 3473/3477? The IP header is set to the
> next hop IP controller. One doesn't need LMP for resolving TE=20
> addresses
> - they are control plane "logical" addresses.
>=20
> Deborah
>=20
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Diego Caviglia
> Sent: Wednesday, April 20, 2005 4:49 AM
> To: Igor Bryskin <i_bryskin
> Cc: ccamp
> Subject: Re: Addressing doc
>=20
>=20
> Igor,
>           my two cents to the discussion.
>=20
> In line.
>=20
> Regards
>=20
> Diego
>=20
>=20
>=20
> Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26
>=20
> Sent by:    [e-mail]
>=20
>=20
> To:    [e-mail], Kireeti Kompella
>        <[e-mail]>
> cc:    [e-mail]
>=20
> Subject:    Re: Addressing doc
>=20
>=20
> Dimitri,
>=20
> Suppose a controller has just received an RSVP Path
> message that contains an ERO describing a path
> computed on the head-end (properly modified, of
> course, along the path). ERO is specified in terms of
> numbered or/and unnumbered TE links (and not IP
> addresses). Now the processing controller needs to
> forward the message to the controller that manages
> first non-local ERO sub-object. The question is what
> to set as destination in the IP header of the RSVP
> Path message?
> [dc] What about usage of the control channel addresses?  I mean having
> LMP
> running between the two nodes the TNE is able to associate one or more
> Control Channels to the TE Link.  In other words LMP is able=20
> to provide
> adress tanslation between the data plane addresses (TE Link)=20
> and control
> plane address (Control Channels).
> [CUT]
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 17:21:14 +0000
Message-ID: <00b501c545cd$20033320$[e-mail]>
From: "Igor Bryskin" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>
Subject: Re: Addressing doc
Date: Wed, 20 Apr 2005 13:19:35 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Deborah,

An ERO describing a path dynamically computed on a graph built of TED
contains TE link IDs (numbered and/or unnumbered) rather than control plane
IP addresses.
Hence, there are two choices:
a) use some mechanism (e.g. LMP) to resolve next hop TE link ID into next
hop controller IP address;
b) use TE link IDs that are guaranteed to be routable addresses. TE Rtr ID
is guaranteed to be routable. Any TE link ID (numbered or unnumbered) could
be resolved to its local TE Rtr ID. That's where (as far as I understand)
the recommendation comes from.

Igor

----- Original Message ----- 
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>; "Igor Bryskin <i_bryskin"
<[e-mail]>
Cc: "ccamp" <[e-mail]>
Sent: Wednesday, April 20, 2005 11:57 AM
Subject: RE: Addressing doc


These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]










Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 15:59:24 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 10:57:36 -0500
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVFhgSEHnqldiYoQJqVhbdevMRIJQAKIdSQ
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "Diego Caviglia" <[e-mail]>, "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>

These threads are a return to one year ago and confusing control plane
and (logical) data plane addressing:
https://psg.com/lists/ccamp/ccamp.2004/msg00335.html
As the demo was on OIF UNI and GMPLS, the confusion is understandable as
OIF uses different terminology, appendix 1 in the ason-signaling draft
provides a comparison:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-03
.txt=20

Below, not sure the context of your reference to non-local in this
scenario? Is the ERO following 3473/3477? The IP header is set to the
next hop IP controller. One doesn't need LMP for resolving TE addresses
- they are control plane "logical" addresses.

Deborah

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Diego Caviglia
Sent: Wednesday, April 20, 2005 4:49 AM
To: Igor Bryskin <i_bryskin
Cc: ccamp
Subject: Re: Addressing doc


Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having
LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]









Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 14:35:57 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=BIITkwb78ugVr59DPSYQCUI4dJm44UT8+vgKVgq1jbHnwhjBso2XaBvWXtOzffT55vWmfTcxQxquUFeOohWb+caTMvB9B5k9JdOO7ceyCNOuFK9e1KHRl6bNPv/k/zptwalVNlsfgWNPvJ+W1oeXg10FyQQ/p/mhibKHsb3CSjc=  ;
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 07:35:31 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: Addressing doc
To: Diego Caviglia <[e-mail]>
Cc: ccamp <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1239608287-1114007731=:57036"

--0-1239608287-1114007731=:57036
Content-Type: text/plain; charset=us-ascii


Hi, Diego,

See my comment in-line.

 

Igor

Diego Caviglia <[e-mail]> wrote: 


Igor, 
          my two cents to the discussion. 

In line. 

Regards 

Diego 

Sent by:        [e-mail] 

To:        [e-mail], Kireeti Kompella <[e-mail]> 
cc:        [e-mail] 

Subject:        Re: Addressing doc 


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message? 
[dc] What about usage of the control channel addresses?  I mean having LMP running between the two nodes the TNE is able to associate one or more  Control Channels to the TE Link.  In other words LMP is able to provide adress tanslation between the data plane addresses (TE Link) and control plane address (Control Channels). 
[CUT] 

IB>> You are absolutely right. However, as I said in one of previous emails, one cannot mandate using LMP for every link in every layer (especially, in PSC layer). Hence, taking advantage of the fact that TE Rtr ID is guaranteed to be routable IP address and the fact that any link ID (numbered or unnumbered) could be always resolved into the advertising TE Rtr ID, the recommendation to set the TE Rtr ID as the destination of the IP packet with the RSVP Path message is IHMO a good one. Having said that nothing prevents, of course, from using any IP address of the controller managing the next hop (which could be known via LMP, configuration, etc.)

Igor


 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
--0-1239608287-1114007731=:57036
Content-Type: text/html; charset=us-ascii

<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Hi, Diego,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">See my comment in-line.<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">&nbsp;<o:p></o:p></SPAN></P>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial">Igor<BR><BR><B><I>Diego Caviglia &lt;[e-mail]&gt;</I></B> wrote: </SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Arial Unicode MS'"><o:p></o:p></SPAN></P>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 3pt; PADDING-BOTTOM: 0in; BORDER-LEFT: #1010ff 1pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
<P class=MsoNormal style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0.5in 12pt 2.5pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-margin-top-alt: auto; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><BR></SPAN><SPAN style="COLOR: blue"><FONT face="Times New Roman" size=3>Igor,</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR></SPAN><SPAN style="COLOR: blue"><FONT face="Times New Roman" size=3>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; my two cents to the discussion.</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR><BR></SPAN><SPAN style="COLOR: blue"><FONT face="Times New Roman" size=3>In line.</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR><BR></SPAN><SPAN style="COLOR: blue"><FONT face="Times New Roman" size=3>Regards</FONT></SPAN><SPAN
 style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR><BR></SPAN><SPAN style="COLOR: blue"><FONT face="Times New Roman" size=3>Diego</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></P>
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;[e-mail]</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></P>
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; MARGIN-BOTTOM: 12pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">To: &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">[e-mail], Kireeti Kompella &lt;[e-mail]&gt;</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR></SPAN><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">cc: &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">[e-mail]<SPAN style="COLOR: purple"> </SPAN></SPAN><SPAN
 style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><BR><BR></SPAN><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">Subject: &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style="FONT-SIZE: 7.5pt; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">Re: Addressing doc</SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR><BR><BR></SPAN><TT><SPAN style="FONT-SIZE: 10pt">Dimitri,</SPAN></TT><SPAN style="FONT-SIZE: 10pt"><BR></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><BR></SPAN><TT><SPAN style="FONT-SIZE: 10pt">Suppose a controller has just received an RSVP Path</SPAN></TT><SPAN style="FONT-SIZE: 10pt"><BR><TT>message that contains an ERO describing a path</TT><BR><TT>computed on the head-end (properly modified, of</TT><BR><TT>course, along the path). ERO is specified in terms of</TT><BR><TT>numbered or/and unnumbered TE links (and not IP</TT><BR><TT>addresses). Now the processing controller needs to</TT><BR><TT>forward the
 message to the controller that manages</TT><BR><TT>first non-local ERO sub-object. The question is what</TT><BR><TT>to set as destination in the IP header of the RSVP</TT><BR><TT>Path message? </TT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"><BR></SPAN><SPAN style="COLOR: blue; FONT-FAMILY: 'Times New Roman'"><FONT size=3>[dc] What about usage of the control channel addresses? &nbsp;I mean having LMP running between the two nodes the TNE is able to associate one or more &nbsp;Control Channels to the TE Link. &nbsp;In other words LMP is able to provide adress tanslation between the data plane addresses (TE Link) and control plane address (Control Channels).</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <BR></SPAN><SPAN style="COLOR: blue; FONT-FAMILY: 'Times New Roman'"><FONT size=3>[CUT]</FONT></SPAN><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"> <o:p></o:p></SPAN></P>
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; MARGIN-BOTTOM: 12pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">IB&gt;&gt; </SPAN><SPAN style="COLOR: purple; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 7.5pt"><FONT size=3>You are absolutely right. However, as I said in one of previous emails, one cannot mandate using LMP for every link in every layer (especially, in PSC layer). Hence, taking advantage of the fact that TE Rtr ID is guaranteed to be routable IP address and the fact that any link ID (numbered or unnumbered) could be always resolved into the advertising TE Rtr ID, the recommendation to set the TE Rtr ID as the destination of the IP packet with the
 RSVP Path message is IHMO a good one. Having said that nothing prevents, of course, from using any IP address of the controller managing the next hop (which could be known via LMP, configuration, etc.)<o:p></o:p></FONT></SPAN></P>
<P style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 0in; MARGIN-BOTTOM: 12pt; PADDING-BOTTOM: 0in; MARGIN-LEFT: 2.5pt; BORDER-LEFT: medium none; MARGIN-RIGHT: 0.5in; PADDING-TOP: 0in; BORDER-BOTTOM: medium none; mso-border-left-alt: solid #1010FF 1.0pt; mso-padding-alt: 0in 0in 0in 3.0pt"><SPAN style="FONT-SIZE: 7.5pt; COLOR: purple; FONT-FAMILY: sans-serif; mso-bidi-font-family: Arial">Igor</SPAN><SPAN style="FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt"><o:p></o:p></SPAN></P></DIV>
<P class=MsoNormal style="MARGIN: 0in 0in 0pt"><FONT size=3><FONT face="Times New Roman">&nbsp;<o:p></o:p></FONT></FONT></P><p>__________________________________________________<br>Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protection around <br>http://mail.yahoo.com 
--0-1239608287-1114007731=:57036--



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 14:23:58 +0000
From: "Rajiv Papneja" <[e-mail]>
To: "'Diego Caviglia'" <[e-mail]>, "'ccamp'" <[e-mail]>
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 10:22:47 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Thread-Index: AcVFqxtRbKCCSzKrRk+7YQ8Au1U6PgACDByg
Message-Id: <[e-mail]>

Hi Diego,
 Please see inline

/Rajiv

> -----Original Message-----
> From: Diego Caviglia [mailto:[e-mail]]
> Sent: Wednesday, April 20, 2005 9:00 AM
> To: ccamp
> Subject: Re: Addressing doc
>
>
> Some comments/question on the ID.
>
> First all think that this work is very useful in order to understand how
> the different implementation of GMPLS interpret the ID/RFC.
>
> I'd like to have, if it is possible, an explanation of the incoming and
> outgoing terms, my understanding of that terms is the following one.
>
>             +-------+                     +-------+
>             |       |      Path-->        |       |
>             |       |=====================|       |=============
>             |       |                    /|       |\
>             +-------+                   / +-------+ \
>                                Incoming/             \OutGoing
>
>
This is the correct understanding.

> I understood from the Lyndon mail that the ID is the result of the ISOCORE
> tests, my question, w.r.t. the ERO processing, is: TNEs that implements
> option 3 are able to interoperate with TNE that implements option 4?  More
> generally was possible to have interworking between the variuos options?

Typically we have used one or the other kind options defined
during the tests. This eliminates the confusion of interpretations.

>
> What exactly means the term encapsulating in the following sentence
> (section 4.0)
> "...
> Mandating that TE Router ID be a reachable IP address eliminates the need
> of the mentioned above module ?
Please see the first paragraph of Section 4. See also Igor's message:
https://psg.com/lists/ccamp/ccamp.2005/msg00381.html.
"  Generally speaking there is a need for a module/protocol that discovers
and manages control plane/data plane address bindings for the address spaces
to be completely separated.  In this case, the TE Router ID could be just a
network unique number.  Mandating that TE Router ID be a reachable IP
address eliminates the need of the mentioned above module $B!&(Bthe next hop
data plane TE Router ID could be used as a destination for IP packets
encapsulating the LSP setup (RSVP Path) message.  Note that every TE
link ID could always be resolved to the link originating TE Router
ID."

> next hop data
> plane TE Router ID could be used as a destination for IP packets
> encapsulating the LSP setup (RSVP Path) message.
> ..."
IP Packet that carries the RSVP-TE message.
>
> Moreover my understunding is that LMP can be the module that manages, on a
> hop by-hop basis of course, control plane/data plane address binding; why
> LMP is not referenced by the ID?  IMHO LMP is an important part of the
> GMPLS protocols suite.
We do not mean to exclude LMP. We'll add words to that effect.
>
> Regards
>
> Diego
>
>
>
>
>
>
>
>
>
>






Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 13:50:38 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>
Cc: "'Igor Bryskin'" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Wed, 20 Apr 2005 09:49:02 -0400
Message-ID: <001001c545af$b6c8bf50$1410a485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Dimitri,=20
Comments inline.

> -----Original Message-----
> From: dimitri papadimitriou [mailto:[e-mail]]=20
> Sent: Wednesday, April 20, 2005 3:12 AM
> To: Richard Rabbat
> Cc: [e-mail]; 'Igor Bryskin';=20
> 'Kireeti Kompella'; [e-mail]
> Subject: Re: Addressing doc
>=20
>=20
> hi richard,
>=20
> Richard Rabbat wrote:
>=20
> > We mentioned in the discussion in Minneapolis that the=20
> objective was *NOT*
> > to standardize broken implementations interwork with the correct
> > implementations.
> > Agree with Igor's and your comments.
> >=20
> > In the introduction, we said:
> > For the purposes of this document it is assumed that there=20
> is a one-to-one
> > correspondence between control plane and data plane entities.
> > I think we covered this well. As we mentioned in the draft,=20
> "Generally
> > speaking there is a need for a module/protocol that=20
> discovers and manages
> > control plane/data plane address bindings for the address=20
> spaces to be
> > completely separated.  In this case, the TE Router ID could=20
> be just a
> > network unique number.  Mandating that TE Router ID be a=20
> reachable IP
> > address eliminates the need of the mentioned above module=20
> =1B$B!&=1B(Bthe next hop
> > data plane TE Router ID could be used as a destination for=20
> IP packets
> > encapsulating the LSP setup (RSVP Path) message."
>=20
> the main comment indeed refers to the issue generated by last part of=20
> the last sentence "TE Router ID could be used as a destination for IP=20
> packets encapsulating the LSP setup (RSVP Path) message" i.e. what i=20
> pointed out is that by recommending only this behaviour, a capability=20
> provided by the GMPLS protocol suite is not taken into=20
> account and this=20
> independently of the reachable behaviour of the TE router ID i.e. not=20
> using the TE Router ID for encapsulating the packets does not=20
> mean that=20
>   the TE Router ID could be just a number - as its definition=20
> is invariant
>=20
> > We will update the draft to show that we are inclusive of=20
> both the simple
> > case and the more complex case that requires the mapping=20
> that we discussed
> > above.
>=20
> ok, this would help
>=20
Good. There's agreement on this.

> > Based on that, why not to progress it to WG draft? Moving=20
> it to WG draft
> > means that the WG is interested in the topic and wants to=20
> address the topic.
>=20
> afaik, changes can not be provided when moving the status of document=20
> and there were already too much confusions in the past=20
> concerning these=20
> information elements and processing to afford yet another issue to be=20
> solved
>=20

I understand there may be confusion. I suggest to make it a WG draft and =
you
have a commitment from the authors to address the issue you raised in =
the
next update to that. After all, this is work in progress :-)
I hope this is satisfactory.

> thanks,
> - dimitri.
>=20
> > Richard.
> >=20
> > -----Original Message-----
> > From: [e-mail]=20
> [mailto:[e-mail]] On Behalf
> > Of [e-mail]
> > Sent: Sunday, April 17, 2005 10:11 AM
> > To: Igor Bryskin
> > Cc: [e-mail]; Kireeti Kompella;=20
> [e-mail]
> > Subject: Re: Addressing doc
> >=20
> >=20
> >=20
> > igor, i mentioned this because when some implement - for=20
> whatever purpose -
> > a subset of capabilities and draw recommendations from this=20
> partial set,
> > these should not by any means retrofit to the complete set=20
> of capabilities
> > this protocol suite delivers or imply recommendations that=20
> would prevent
> > from using its full set
> >=20
> > coming to the below you have been mentioned on what this so-called
> > separation does imply is that for constructing - and LMP=20
> can be used in
> > helping this construction but this is also not mandatory -=20
> the TE topology
> > make use of the TE router ID for the identification=20
> unnumbered interfaces
> > and (abstract) nodes, (numbered interfaces are also part of=20
> this class of
> > information - but obviously does not require the use of the=20
> TE Router ID)
> > afterwards any control plane message exchange can make use=20
> of the IP control
> > plane topology as long as these messages are exchanged=20
> between control plane
> > entities that have initially advertized (i.e. as owner of)=20
> this information
> >=20
> > hope this clarifies,
> >=20
> > - dimitri.
> >=20
> > Igor Bryskin <[e-mail]>
> > Sent by: [e-mail]
> > 04/17/2005 05:50 MST
> >=20
> > To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> > cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella
> > <[e-mail]>, [e-mail]
> > bcc:
> > Subject: Re: Addressing doc
> >=20
> >=20
> >=20
> >=20
> > Dimitri,
> >=20
> > I think we are in agreement here. The only thing I
> > disagree with is your statement that the document is
> > not ready to be WG document for the reasons you have
> > provided. I am not the author of this document and I
> > let the authors tell what they think. However, the
> > whole point of the document, as far as I understand
> > it, is not to mandate something, rather, to provide a
> > set of recommendations based on the interop tests
> > experience, so that interoperability between different
> > vendors would be easier to achieve. Hence, they do not
> > need to spell out word RECOMMEND in every clause.
> >=20
> > WRT TE Router ID. Of course, IFF there is some
> > knowledge or mechanism to translate TE addresses into
> > control plane IP addresses, any of next hop IP
> > addresses could be used as destination in RSVP Path
> > message IP packet. In this case IHMO  Te Router ID
> > does not even have to be routable, and full separation
> > between TE and control plane name spaces could be
> > achieved. I think LMP could help to do this. However,
> > one cannot mandate using LMP for every link in every
> > layer, especially, for IP/MPLS layer(s).
> >=20
> > Igor
> >=20
> > --- [e-mail] wrote:
> >=20
> >=20
> >>igor, my point is that if you recommend
> >>
> >>"  A Path message is sent to the next hop node. It
> >>is RECOMMENDED that
> >>   the TE router ID of the next hop node be used as
> >>an IP destination
> >>   address in the packet that carries the RSVP-TE
> >>message. "
> >>
> >>and
> >>
> >>"  ... an unnumbered link is identified by the
> >>combination of TE Router
> >>  ID and a node-unique Interface ID."
> >>
> >>then it is clear that the following occurs
> >>
> >>" The reason why the TE Router ID must be a
> >>reachable IP address is
> >>  because in GMPLS, control and data plane
> >>names/addresses are not
> >>  completely separated. "
> >>
> >>and the only change that needs to be done in this
> >>document in section 4.3
> >>
> >>"It is RECOMMENDED that a stable
> >>   control plane IP address of the next/previous hop
> >>node be used as an
> >>   IP destination address in RSVP-TE message.
> >>
> >>   A Path message is sent to the next hop node. It
> >>is RECOMMENDED that
> >>   the TE router ID of the next hop node be used as
> >>an IP destination
> >>   address in the packet that carries the RSVP-TE
> >>message."
> >>
> >>is to remove the second paragraph, as there is
> >>nothing that mandates that
> >>communication between adjacent controllers should
> >>achieved through TE
> >>router ID (note: reading the document you will see
> >>that the section 5.2.1
> >>is indeed
> >>not completed just for this reason)
> >>
> >>in fact, this boils down to say that the TE router
> >>ID is not mandatorily
> >>used for hop-by-hop exchange of control messages as
> >>i can build adjacencies
> >>between neighboring nodes using the base IP routing
> >>topology, (by the way
> >>from where all restrictions that are pointed here
> >>below come from ?)
> >>
> >>thanks,
> >>- dimitri.
> >>---
> >>
> >>Dimitri,
> >>
> >>Suppose a controller has just received an RSVP Path
> >>message that contains an ERO describing a path
> >>computed on the head-end (properly modified, of
> >>course, along the path). ERO is specified in terms
> >>of
> >>numbered or/and unnumbered TE links (and not IP
> >>addresses). Now the processing controller needs to
> >>forward the message to the controller that manages
> >>first non-local ERO sub-object. The question is what
> >>to set as destination in the IP header of the RSVP
> >>Path message? You are saying that it should a stable
> >>IP address of the controller managing the next hop.
> >>Where the processing controller is supposed to get
> >>this stable IP address from? All that it has is a
> >>numbered or unnumbered next hop TE link ID. It is
> >>not
> >>guaranteed that numbered TE link ID is a routable
> >>address, however, it could be easily resolved to TE
> >>Router ID. In case of unnumbered TE link the TE
> >>Router
> >>ID is a part of the link ID. It is also guaranteed
> >>that TE Router ID is a stable routable IP address of
> >>the controller advertising the TE link. Hence, the
> >>recommendation makes a lot of sense to me ? extract
> >>TE
> >>Router ID from unnumbered link ID ERO subobject or
> >>resolve numbered TE link ID into TE Router ID, set
> >>it
> >>as destination in IP header of the RSVP Path message
> >>and forward the packet ?the message will arrive at
> >>the
> >>controller managing next hop no matter how many
> >>actual
> >>IP hops the packet will make. In fact, that's how
> >>the
> >>control plane and data plane separation needs to be
> >>supported.
> >>
> >>Cheers,
> >>Igor
> >>
> >>--- [e-mail] wrote:
> >>
> >>>this document is not ready as it prevents usage of
> >>>the control channel
> >>>separation as defined in Section 8 of RFC 3473
> >>
> >>(but
> >>
> >>>also representation of
> >>>complex nodes)
> >>>
> >>>i point out here the sentences from where this can
> >>>be deduced:
> >>>
> >>>"  A Path message is sent to the next hop node.
> >>
> >>It
> >>
> >>>is RECOMMENDED that
> >>>   the TE router ID of the next hop node be used
> >>
> >>as
> >>
> >>>an IP destination
> >>>   address in the packet that carries the RSVP-TE
> >>>message. "
> >>>
> >>>combined with the following statements
> >>>
> >>>"  ... an unnumbered link is identified by the
> >>>   combination of TE Router ID and a node-unique
> >>>Interface ID."
> >>>
> >>>"  It is RECOMMENDED that the IP tunnel endpoint
> >>>address in the Session
> >>>   Object [RFC3209] be set to the TE Router ID of
> >>>the egress since the
> >>>   TE Router ID is a unique routable ID per node."
> >>>
> >>>[...]
> >>>
> >>>"  It is RECOMMENDED that the IP tunnel sender
> >>>address in the Sender
> >>>   Template Object [RFC3209] specifies the TE
> >>
> >>Router
> >>
> >>>ID of the ingress
> >>>   since the TE Router ID is a unique routable ID
> >>>per node."
> >>>
> >>>therefore, usage of the TE Router ID should be
> >>>reviewed, such that it does
> >>>not recommends the source and destination of IP
> >>>packets to be the TE Router
> >>>ID but simply a stable reachable control plane IP
> >>>address of the
> >>>next/previous hop
> >>>
> >>>also, there is a sentence in this document
> >>>
> >>>"  The reason why the TE Router ID must be a
> >>>reachable IP address is
> >>>   because in GMPLS, control and data plane names
> >>>/addresses are not
> >>>   completely separated. "
> >>>
> >>>my response to this is of course if you use it
> >>
> >>like
> >>
> >>>proposed in this
> >>>document this problem occurs
> >>>
> >>>ps:
> >>>
> >>>section 5.1.2 of this document is unclear wrt
> >>>section 1.1 of
> >>>
> >>
> >=20
> <http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-ext
ensions-19.txt
>=20
>>>
>>>
>>>
>>
>>
>>
>>__________________________________
>>Do you Yahoo!?
>>Plan great trips with Yahoo! Travel: Now over 17,000
>>guides!
>>http://travel.yahoo.com/p-travelguide
>>
>>
>>
>>
>=20
>=20
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>=20
>=20




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 13:01:56 +0000
Sensitivity: 
Subject: Re: Addressing doc
To: "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Apr 2005 15:00:16 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Some comments/question on the ID.

First all think that this work is very useful in order to understand how
the different implementation of GMPLS interpret the ID/RFC.

I'd like to have, if it is possible, an explanation of the incoming and
outgoing terms, my understanding of that terms is the following one.

            +-------+                     +-------+
            |       |      Path-->        |       |
            |       |=====================|       |=============
            |       |                    /|       |\
            +-------+                   / +-------+ \
                               Incoming/             \OutGoing


I understood from the Lyndon mail that the ID is the result of the ISOCORE
tests, my question, w.r.t. the ERO processing, is: TNEs that implements
option 3 are able to interoperate with TNE that implements option 4?  More
generally was possible to have interworking between the variuos options?

What exactly means the term encapsulating in the following sentence
(section 4.0)
"...
Mandating that TE Router ID be a reachable IP address eliminates the need
of the mentioned above module ? next hop data
plane TE Router ID could be used as a destination for IP packets
encapsulating the LSP setup (RSVP Path) message.
..."

Moreover my understunding is that LMP can be the module that manages, on a
hop by-hop basis of course, control plane/data plane address binding; why
LMP is not referenced by the ID?  IMHO LMP is an important part of the
GMPLS protocols suite.

Regards

Diego











Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 08:50:07 +0000
Sensitivity: 
Subject: Re: Addressing doc
To: "Igor Bryskin <i_bryskin" <[e-mail]>
Cc: "ccamp" <[e-mail]>
Message-ID: <[e-mail]>
From: "Diego Caviglia" <[e-mail]>
Date: Wed, 20 Apr 2005 10:49:20 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

Igor,
          my two cents to the discussion.

In line.

Regards

Diego



Igor Bryskin <[e-mail]>@ops.ietf.org on 16/04/2005 23.31.26

Sent by:    [e-mail]


To:    [e-mail], Kireeti Kompella
       <[e-mail]>
cc:    [e-mail]

Subject:    Re: Addressing doc


Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message?
[dc] What about usage of the control channel addresses?  I mean having LMP
running between the two nodes the TNE is able to associate one or more
Control Channels to the TE Link.  In other words LMP is able to provide
adress tanslation between the data plane addresses (TE Link) and control
plane address (Control Channels).
[CUT]







Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 07:13:32 +0000
Message-ID: <[e-mail]>
Date: Wed, 20 Apr 2005 09:12:13 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To: Richard Rabbat <[e-mail]>
CC:  [e-mail],  'Igor Bryskin' <[e-mail]>, 'Kireeti Kompella' <[e-mail]>,  [e-mail]
Subject: Re: Addressing doc
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi richard,

Richard Rabbat wrote:

> We mentioned in the discussion in Minneapolis that the objective was *NOT*
> to standardize broken implementations interwork with the correct
> implementations.
> Agree with Igor's and your comments.
> 
> In the introduction, we said:
> For the purposes of this document it is assumed that there is a one-to-one
> correspondence between control plane and data plane entities.
> I think we covered this well. As we mentioned in the draft, "Generally
> speaking there is a need for a module/protocol that discovers and manages
> control plane/data plane address bindings for the address spaces to be
> completely separated.  In this case, the TE Router ID could be just a
> network unique number.  Mandating that TE Router ID be a reachable IP
> address eliminates the need of the mentioned above module $B!&(Bthe next hop
> data plane TE Router ID could be used as a destination for IP packets
> encapsulating the LSP setup (RSVP Path) message."

the main comment indeed refers to the issue generated by last part of 
the last sentence "TE Router ID could be used as a destination for IP 
packets encapsulating the LSP setup (RSVP Path) message" i.e. what i 
pointed out is that by recommending only this behaviour, a capability 
provided by the GMPLS protocol suite is not taken into account and this 
independently of the reachable behaviour of the TE router ID i.e. not 
using the TE Router ID for encapsulating the packets does not mean that 
  the TE Router ID could be just a number - as its definition is invariant

> We will update the draft to show that we are inclusive of both the simple
> case and the more complex case that requires the mapping that we discussed
> above.

ok, this would help

> Based on that, why not to progress it to WG draft? Moving it to WG draft
> means that the WG is interested in the topic and wants to address the topic.

afaik, changes can not be provided when moving the status of document 
and there were already too much confusions in the past concerning these 
information elements and processing to afford yet another issue to be 
solved

thanks,
- dimitri.

> Richard.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of [e-mail]
> Sent: Sunday, April 17, 2005 10:11 AM
> To: Igor Bryskin
> Cc: [e-mail]; Kireeti Kompella; [e-mail]
> Subject: Re: Addressing doc
> 
> 
> 
> igor, i mentioned this because when some implement - for whatever purpose -
> a subset of capabilities and draw recommendations from this partial set,
> these should not by any means retrofit to the complete set of capabilities
> this protocol suite delivers or imply recommendations that would prevent
> from using its full set
> 
> coming to the below you have been mentioned on what this so-called
> separation does imply is that for constructing - and LMP can be used in
> helping this construction but this is also not mandatory - the TE topology
> make use of the TE router ID for the identification unnumbered interfaces
> and (abstract) nodes, (numbered interfaces are also part of this class of
> information - but obviously does not require the use of the TE Router ID)
> afterwards any control plane message exchange can make use of the IP control
> plane topology as long as these messages are exchanged between control plane
> entities that have initially advertized (i.e. as owner of) this information
> 
> hope this clarifies,
> 
> - dimitri.
> 
> Igor Bryskin <[e-mail]>
> Sent by: [e-mail]
> 04/17/2005 05:50 MST
> 
> To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
> cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella
> <[e-mail]>, [e-mail]
> bcc:
> Subject: Re: Addressing doc
> 
> 
> 
> 
> Dimitri,
> 
> I think we are in agreement here. The only thing I
> disagree with is your statement that the document is
> not ready to be WG document for the reasons you have
> provided. I am not the author of this document and I
> let the authors tell what they think. However, the
> whole point of the document, as far as I understand
> it, is not to mandate something, rather, to provide a
> set of recommendations based on the interop tests
> experience, so that interoperability between different
> vendors would be easier to achieve. Hence, they do not
> need to spell out word RECOMMEND in every clause.
> 
> WRT TE Router ID. Of course, IFF there is some
> knowledge or mechanism to translate TE addresses into
> control plane IP addresses, any of next hop IP
> addresses could be used as destination in RSVP Path
> message IP packet. In this case IHMO  Te Router ID
> does not even have to be routable, and full separation
> between TE and control plane name spaces could be
> achieved. I think LMP could help to do this. However,
> one cannot mandate using LMP for every link in every
> layer, especially, for IP/MPLS layer(s).
> 
> Igor
> 
> --- [e-mail] wrote:
> 
> 
>>igor, my point is that if you recommend
>>
>>"  A Path message is sent to the next hop node. It
>>is RECOMMENDED that
>>   the TE router ID of the next hop node be used as
>>an IP destination
>>   address in the packet that carries the RSVP-TE
>>message. "
>>
>>and
>>
>>"  ... an unnumbered link is identified by the
>>combination of TE Router
>>  ID and a node-unique Interface ID."
>>
>>then it is clear that the following occurs
>>
>>" The reason why the TE Router ID must be a
>>reachable IP address is
>>  because in GMPLS, control and data plane
>>names/addresses are not
>>  completely separated. "
>>
>>and the only change that needs to be done in this
>>document in section 4.3
>>
>>"It is RECOMMENDED that a stable
>>   control plane IP address of the next/previous hop
>>node be used as an
>>   IP destination address in RSVP-TE message.
>>
>>   A Path message is sent to the next hop node. It
>>is RECOMMENDED that
>>   the TE router ID of the next hop node be used as
>>an IP destination
>>   address in the packet that carries the RSVP-TE
>>message."
>>
>>is to remove the second paragraph, as there is
>>nothing that mandates that
>>communication between adjacent controllers should
>>achieved through TE
>>router ID (note: reading the document you will see
>>that the section 5.2.1
>>is indeed
>>not completed just for this reason)
>>
>>in fact, this boils down to say that the TE router
>>ID is not mandatorily
>>used for hop-by-hop exchange of control messages as
>>i can build adjacencies
>>between neighboring nodes using the base IP routing
>>topology, (by the way
>>from where all restrictions that are pointed here
>>below come from ?)
>>
>>thanks,
>>- dimitri.
>>---
>>
>>Dimitri,
>>
>>Suppose a controller has just received an RSVP Path
>>message that contains an ERO describing a path
>>computed on the head-end (properly modified, of
>>course, along the path). ERO is specified in terms
>>of
>>numbered or/and unnumbered TE links (and not IP
>>addresses). Now the processing controller needs to
>>forward the message to the controller that manages
>>first non-local ERO sub-object. The question is what
>>to set as destination in the IP header of the RSVP
>>Path message? You are saying that it should a stable
>>IP address of the controller managing the next hop.
>>Where the processing controller is supposed to get
>>this stable IP address from? All that it has is a
>>numbered or unnumbered next hop TE link ID. It is
>>not
>>guaranteed that numbered TE link ID is a routable
>>address, however, it could be easily resolved to TE
>>Router ID. In case of unnumbered TE link the TE
>>Router
>>ID is a part of the link ID. It is also guaranteed
>>that TE Router ID is a stable routable IP address of
>>the controller advertising the TE link. Hence, the
>>recommendation makes a lot of sense to me ? extract
>>TE
>>Router ID from unnumbered link ID ERO subobject or
>>resolve numbered TE link ID into TE Router ID, set
>>it
>>as destination in IP header of the RSVP Path message
>>and forward the packet ?the message will arrive at
>>the
>>controller managing next hop no matter how many
>>actual
>>IP hops the packet will make. In fact, that's how
>>the
>>control plane and data plane separation needs to be
>>supported.
>>
>>Cheers,
>>Igor
>>
>>--- [e-mail] wrote:
>>
>>>this document is not ready as it prevents usage of
>>>the control channel
>>>separation as defined in Section 8 of RFC 3473
>>
>>(but
>>
>>>also representation of
>>>complex nodes)
>>>
>>>i point out here the sentences from where this can
>>>be deduced:
>>>
>>>"  A Path message is sent to the next hop node.
>>
>>It
>>
>>>is RECOMMENDED that
>>>   the TE router ID of the next hop node be used
>>
>>as
>>
>>>an IP destination
>>>   address in the packet that carries the RSVP-TE
>>>message. "
>>>
>>>combined with the following statements
>>>
>>>"  ... an unnumbered link is identified by the
>>>   combination of TE Router ID and a node-unique
>>>Interface ID."
>>>
>>>"  It is RECOMMENDED that the IP tunnel endpoint
>>>address in the Session
>>>   Object [RFC3209] be set to the TE Router ID of
>>>the egress since the
>>>   TE Router ID is a unique routable ID per node."
>>>
>>>[...]
>>>
>>>"  It is RECOMMENDED that the IP tunnel sender
>>>address in the Sender
>>>   Template Object [RFC3209] specifies the TE
>>
>>Router
>>
>>>ID of the ingress
>>>   since the TE Router ID is a unique routable ID
>>>per node."
>>>
>>>therefore, usage of the TE Router ID should be
>>>reviewed, such that it does
>>>not recommends the source and destination of IP
>>>packets to be the TE Router
>>>ID but simply a stable reachable control plane IP
>>>address of the
>>>next/previous hop
>>>
>>>also, there is a sentence in this document
>>>
>>>"  The reason why the TE Router ID must be a
>>>reachable IP address is
>>>   because in GMPLS, control and data plane names
>>>/addresses are not
>>>   completely separated. "
>>>
>>>my response to this is of course if you use it
>>
>>like
>>
>>>proposed in this
>>>document this problem occurs
>>>
>>>ps:
>>>
>>>section 5.1.2 of this document is unclear wrt
>>>section 1.1 of
>>>
>>
> <http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt
> 
>>>
>>>
>>>
>>
>>
>>
>>__________________________________
>>Do you Yahoo!?
>>Plan great trips with Yahoo! Travel: Now over 17,000
>>guides!
>>http://travel.yahoo.com/p-travelguide
>>
>>
>>
>>
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> 
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 03:28:08 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>, "'Igor Bryskin'" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Tue, 19 Apr 2005 23:26:26 -0400
Message-ID: <003201c54558$bfe79130$1410a485@PHOENIX>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C54537.38D5F130"

This is a multi-part message in MIME format.

------=_NextPart_000_0033_01C54537.38D5F130
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

We mentioned in the discussion in Minneapolis that the objective was *NOT*
to standardize broken implementations interwork with the correct
implementations.
Agree with Igor's and your comments.

In the introduction, we said:
For the purposes of this document it is assumed that there is a one-to-one
correspondence between control plane and data plane entities.
I think we covered this well. As we mentioned in the draft, "Generally
speaking there is a need for a module/protocol that discovers and manages
control plane/data plane address bindings for the address spaces to be
completely separated.  In this case, the TE Router ID could be just a
network unique number.  Mandating that TE Router ID be a reachable IP
address eliminates the need of the mentioned above module $B!&(Bthe next hop
data plane TE Router ID could be used as a destination for IP packets
encapsulating the LSP setup (RSVP Path) message."

We will update the draft to show that we are inclusive of both the simple
case and the more complex case that requires the mapping that we discussed
above.

Based on that, why not to progress it to WG draft? Moving it to WG draft
means that the WG is interested in the topic and wants to address the topic.

Richard.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of [e-mail]
Sent: Sunday, April 17, 2005 10:11 AM
To: Igor Bryskin
Cc: [e-mail]; Kireeti Kompella; [e-mail]
Subject: Re: Addressing doc



igor, i mentioned this because when some implement - for whatever purpose -
a subset of capabilities and draw recommendations from this partial set,
these should not by any means retrofit to the complete set of capabilities
this protocol suite delivers or imply recommendations that would prevent
from using its full set

coming to the below you have been mentioned on what this so-called
separation does imply is that for constructing - and LMP can be used in
helping this construction but this is also not mandatory - the TE topology
make use of the TE router ID for the identification unnumbered interfaces
and (abstract) nodes, (numbered interfaces are also part of this class of
information - but obviously does not require the use of the TE Router ID)
afterwards any control plane message exchange can make use of the IP control
plane topology as long as these messages are exchanged between control plane
entities that have initially advertized (i.e. as owner of) this information

hope this clarifies,

- dimitri.

Igor Bryskin <[e-mail]>
Sent by: [e-mail]
04/17/2005 05:50 MST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella
<[e-mail]>, [e-mail]
bcc:
Subject: Re: Addressing doc




Dimitri,

I think we are in agreement here. The only thing I
disagree with is your statement that the document is
not ready to be WG document for the reasons you have
provided. I am not the author of this document and I
let the authors tell what they think. However, the
whole point of the document, as far as I understand
it, is not to mandate something, rather, to provide a
set of recommendations based on the interop tests
experience, so that interoperability between different
vendors would be easier to achieve. Hence, they do not
need to spell out word RECOMMEND in every clause.

WRT TE Router ID. Of course, IFF there is some
knowledge or mechanism to translate TE addresses into
control plane IP addresses, any of next hop IP
addresses could be used as destination in RSVP Path
message IP packet. In this case IHMO  Te Router ID
does not even have to be routable, and full separation
between TE and control plane name spaces could be
achieved. I think LMP could help to do this. However,
one cannot mandate using LMP for every link in every
layer, especially, for IP/MPLS layer(s).

Igor

--- [e-mail] wrote:

>
> igor, my point is that if you recommend
>
> "  A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
>
> and
>
> "  ... an unnumbered link is identified by the
> combination of TE Router
>   ID and a node-unique Interface ID."
>
> then it is clear that the following occurs
>
> " The reason why the TE Router ID must be a
> reachable IP address is
>   because in GMPLS, control and data plane
> names/addresses are not
>   completely separated. "
>
> and the only change that needs to be done in this
> document in section 4.3
>
> "It is RECOMMENDED that a stable
>    control plane IP address of the next/previous hop
> node be used as an
>    IP destination address in RSVP-TE message.
>
>    A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message."
>
> is to remove the second paragraph, as there is
> nothing that mandates that
> communication between adjacent controllers should
> achieved through TE
> router ID (note: reading the document you will see
> that the section 5.2.1
> is indeed
> not completed just for this reason)
>
> in fact, this boils down to say that the TE router
> ID is not mandatorily
> used for hop-by-hop exchange of control messages as
> i can build adjacencies
> between neighboring nodes using the base IP routing
> topology, (by the way
> from where all restrictions that are pointed here
> below come from ?)
>
> thanks,
> - dimitri.
> ---
>
> Dimitri,
>
> Suppose a controller has just received an RSVP Path
> message that contains an ERO describing a path
> computed on the head-end (properly modified, of
> course, along the path). ERO is specified in terms
> of
> numbered or/and unnumbered TE links (and not IP
> addresses). Now the processing controller needs to
> forward the message to the controller that manages
> first non-local ERO sub-object. The question is what
> to set as destination in the IP header of the RSVP
> Path message? You are saying that it should a stable
> IP address of the controller managing the next hop.
> Where the processing controller is supposed to get
> this stable IP address from? All that it has is a
> numbered or unnumbered next hop TE link ID. It is
> not
> guaranteed that numbered TE link ID is a routable
> address, however, it could be easily resolved to TE
> Router ID. In case of unnumbered TE link the TE
> Router
> ID is a part of the link ID. It is also guaranteed
> that TE Router ID is a stable routable IP address of
> the controller advertising the TE link. Hence, the
> recommendation makes a lot of sense to me ? extract
> TE
> Router ID from unnumbered link ID ERO subobject or
> resolve numbered TE link ID into TE Router ID, set
> it
> as destination in IP header of the RSVP Path message
> and forward the packet ?the message will arrive at
> the
> controller managing next hop no matter how many
> actual
> IP hops the packet will make. In fact, that's how
> the
> control plane and data plane separation needs to be
> supported.
>
> Cheers,
> Igor
>
> --- [e-mail] wrote:
> >
> > this document is not ready as it prevents usage of
> > the control channel
> > separation as defined in Section 8 of RFC 3473
> (but
> > also representation of
> > complex nodes)
> >
> > i point out here the sentences from where this can
> > be deduced:
> >
> > "  A Path message is sent to the next hop node.
> It
> > is RECOMMENDED that
> >    the TE router ID of the next hop node be used
> as
> > an IP destination
> >    address in the packet that carries the RSVP-TE
> > message. "
> >
> > combined with the following statements
> >
> > "  ... an unnumbered link is identified by the
> >    combination of TE Router ID and a node-unique
> > Interface ID."
> >
> > "  It is RECOMMENDED that the IP tunnel endpoint
> > address in the Session
> >    Object [RFC3209] be set to the TE Router ID of
> > the egress since the
> >    TE Router ID is a unique routable ID per node."
> >
> > [...]
> >
> > "  It is RECOMMENDED that the IP tunnel sender
> > address in the Sender
> >    Template Object [RFC3209] specifies the TE
> Router
> > ID of the ingress
> >    since the TE Router ID is a unique routable ID
> > per node."
> >
> > therefore, usage of the TE Router ID should be
> > reviewed, such that it does
> > not recommends the source and destination of IP
> > packets to be the TE Router
> > ID but simply a stable reachable control plane IP
> > address of the
> > next/previous hop
> >
> > also, there is a sentence in this document
> >
> > "  The reason why the TE Router ID must be a
> > reachable IP address is
> >    because in GMPLS, control and data plane names
> > /addresses are not
> >    completely separated. "
> >
> > my response to this is of course if you use it
> like
> > proposed in this
> > document this problem occurs
> >
> > ps:
> >
> > section 5.1.2 of this document is unclear wrt
> > section 1.1 of
> >
>
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt
>
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000
> guides!
> http://travel.yahoo.com/p-travelguide
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


------=_NextPart_000_0033_01C54537.38D5F130
Content-Type: text/html;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: quoted-printable

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

<META content=3D"MSHTML 6.00.2900.2627" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>We=20
mentioned in the discussion in Minneapolis that the objective was *NOT* =
to=20
standardize broken implementations interwork with the correct =
implementations.=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Agree=20
with Igor's and your comments.</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D180105802-20042005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D180105802-20042005>In the=20
introduction, we said:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D180105802-20042005>For the =
purposes of this=20
document it is assumed that there is&nbsp;a one-to-one correspondence =
between=20
control plane and data plane&nbsp;entities.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D180105802-20042005>I=20
think we covered this well.&nbsp;As we mentioned in the draft,=20
"</SPAN></FONT><SPAN class=3D180105802-20042005><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Generally speaking there is a&nbsp;need for a module/protocol =
that=20
discovers and manages control plane/data plane address bindings for the =
address=20
spaces to be completely separated.&nbsp; In this case, the TE Router ID =
could be=20
just a network unique number.&nbsp; Mandating that TE Router ID be a =
reachable=20
IP address eliminates the need of the mentioned above module =
=1B$B!&=1B(Jthe next hop data=20
plane TE Router ID could be used as a destination for IP packets =
encapsulating=20
the LSP setup (RSVP Path) message."</FONT></SPAN></DIV>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>&nbsp;=20
<BR>We will update the draft to show that we are inclusive of both the =
simple=20
case and the more complex case that requires the mapping that we =
discussed=20
above. </FONT></SPAN></DIV>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Based=20
on that, why not to progress it to WG draft? Moving it to WG draft means =
that=20
the WG is interested in the topic and wants to address the=20
topic.</FONT></SPAN></DIV>
<DIV><SPAN class=3D180105802-20042005><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Richard.</DIV></FONT></SPAN>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of=20
  </B>[e-mail]<BR><B>Sent:</B> Sunday, April 17, =
2005=20
  10:11 AM<BR><B>To:</B> Igor Bryskin<BR><B>Cc:</B>=20
  [e-mail]; Kireeti Kompella;=20
  [e-mail]<BR><B>Subject:</B> Re: Addressing =
doc<BR><BR></FONT></DIV>
  <P><FONT face=3DMonospace,Courier>igor, i mentioned this because when =
some=20
  implement - for whatever purpose - a subset of capabilities and draw=20
  recommendations from this partial set, these should not by any means =
retrofit=20
  to the complete set of capabilities this protocol suite delivers or =
imply=20
  recommendations that would prevent from using its full set</FONT></P>
  <P><FONT face=3DMonospace,Courier>coming to the below you have been =
mentioned on=20
  what this so-called separation does imply is that for constructing - =
and LMP=20
  can be used in helping this construction but this is also not =
mandatory - the=20
  TE topology make use of the TE router ID for the identification =
unnumbered=20
  interfaces and (abstract) nodes, (numbered interfaces are also part of =
this=20
  class of information - but obviously does not require the use of the =
TE Router=20
  ID) afterwards any control plane message exchange can make use of the =
IP=20
  control plane topology as long as these messages are exchanged between =
control=20
  plane entities that have initially advertized (i.e. as owner of) this=20
  information</FONT></P>
  <P><FONT face=3DMonospace,Courier>hope this clarifies,</FONT></P>
  <P><FONT face=3DMonospace,Courier>- dimitri.<BR></FONT><BR><FONT =
size=3D2><B>Igor=20
  Bryskin &lt;[e-mail]&gt;</B></FONT><BR><FONT size=3D2>Sent =
by:=20
  [e-mail]</FONT><BR><FONT size=3D2>04/17/2005 05:50=20
  MST</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>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella=20
  &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT=20
  size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>Re:=20
  Addressing doc</FONT><BR><BR><BR></P>
  <P><FONT face=3DMonospace,Courier>Dimitri,<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>I think we are in agreement here. The only =
thing=20
  I<BR>disagree with is your statement that the document is<BR>not ready =
to be=20
  WG document for the reasons you have<BR>provided. I am not the author =
of this=20
  document and I<BR>let the authors tell what they think. However, =
the<BR>whole=20
  point of the document, as far as I understand<BR>it, is not to mandate =

  something, rather, to provide a<BR>set of recommendations based on the =
interop=20
  tests<BR>experience, so that interoperability between =
different<BR>vendors=20
  would be easier to achieve. Hence, they do not<BR>need to spell out =
word=20
  RECOMMEND in every clause.<BR></FONT><BR><FONT =
face=3DMonospace,Courier>WRT TE=20
  Router ID. Of course, IFF there is some<BR>knowledge or mechanism to =
translate=20
  TE addresses into<BR>control plane IP addresses, any of next hop=20
  IP<BR>addresses could be used as destination in RSVP Path<BR>message =
IP=20
  packet. In this case IHMO &nbsp;Te Router ID<BR>does not even have to =
be=20
  routable, and full separation<BR>between TE and control plane name =
spaces=20
  could be<BR>achieved. I think LMP could help to do this. =
However,<BR>one=20
  cannot mandate using LMP for every link in every<BR>layer, especially, =
for=20
  IP/MPLS layer(s).<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>Igor<BR></FONT><BR><FONT =
face=3DMonospace,Courier>---=20
  [e-mail] wrote:<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; igor, my point is that if you=20
  recommend<BR>&gt;<BR>&gt; " &nbsp;A Path message is sent to the next =
hop node.=20
  It<BR>&gt; is RECOMMENDED that<BR>&gt; &nbsp; &nbsp;the TE router ID =
of the=20
  next hop node be used as<BR>&gt; an IP destination<BR>&gt; &nbsp;=20
  &nbsp;address in the packet that carries the RSVP-TE<BR>&gt; message.=20
  "<BR>&gt;<BR>&gt; and<BR>&gt;<BR>&gt; " &nbsp;... an unnumbered link =
is=20
  identified by the<BR>&gt; combination of TE Router<BR>&gt; &nbsp; ID =
and a=20
  node-unique Interface ID."<BR>&gt;<BR>&gt; then it is clear that the =
following=20
  occurs<BR>&gt;<BR>&gt; " The reason why the TE Router ID must be =
a<BR>&gt;=20
  reachable IP address is<BR>&gt; &nbsp; because in GMPLS, control and =
data=20
  plane<BR>&gt; names/addresses are not<BR>&gt; &nbsp; completely =
separated.=20
  "<BR>&gt;<BR>&gt; and the only change that needs to be done in =
this<BR>&gt;=20
  document in section 4.3<BR>&gt;<BR>&gt; "It is RECOMMENDED that a=20
  stable<BR>&gt; &nbsp; &nbsp;control plane IP address of the =
next/previous=20
  hop<BR>&gt; node be used as an<BR>&gt; &nbsp; &nbsp;IP destination =
address in=20
  RSVP-TE message.<BR>&gt;<BR>&gt; &nbsp; &nbsp;A Path message is sent =
to the=20
  next hop node. It<BR>&gt; is RECOMMENDED that<BR>&gt; &nbsp; &nbsp;the =
TE=20
  router ID of the next hop node be used as<BR>&gt; an IP =
destination<BR>&gt;=20
  &nbsp; &nbsp;address in the packet that carries the RSVP-TE<BR>&gt;=20
  message."<BR>&gt;<BR>&gt; is to remove the second paragraph, as there=20
  is<BR>&gt; nothing that mandates that<BR>&gt; communication between =
adjacent=20
  controllers should<BR>&gt; achieved through TE<BR>&gt; router ID =
(note:=20
  reading the document you will see<BR>&gt; that the section =
5.2.1<BR>&gt; is=20
  indeed<BR>&gt; not completed just for this reason)<BR>&gt;<BR>&gt; in =
fact,=20
  this boils down to say that the TE router<BR>&gt; ID is not=20
  mandatorily<BR>&gt; used for hop-by-hop exchange of control messages=20
  as<BR>&gt; i can build adjacencies<BR>&gt; between neighboring nodes =
using the=20
  base IP routing<BR>&gt; topology, (by the way<BR>&gt; from where all=20
  restrictions that are pointed here<BR>&gt; below come from =
?)<BR>&gt;<BR>&gt;=20
  thanks,<BR>&gt; - dimitri.<BR>&gt; ---<BR>&gt;<BR>&gt;=20
  Dimitri,<BR>&gt;<BR>&gt; Suppose a controller has just received an =
RSVP=20
  Path<BR>&gt; message that contains an ERO describing a path<BR>&gt; =
computed=20
  on the head-end (properly modified, of<BR>&gt; course, along the =
path). ERO is=20
  specified in terms<BR>&gt; of<BR>&gt; numbered or/and unnumbered TE =
links (and=20
  not IP<BR>&gt; addresses). Now the processing controller needs =
to<BR>&gt;=20
  forward the message to the controller that manages<BR>&gt; first =
non-local ERO=20
  sub-object. The question is what<BR>&gt; to set as destination in the =
IP=20
  header of the RSVP<BR>&gt; Path message? You are saying that it should =
a=20
  stable<BR>&gt; IP address of the controller managing the next =
hop.<BR>&gt;=20
  Where the processing controller is supposed to get<BR>&gt; this stable =
IP=20
  address from? All that it has is a<BR>&gt; numbered or unnumbered next =
hop TE=20
  link ID. It is<BR>&gt; not<BR>&gt; guaranteed that numbered TE link ID =
is a=20
  routable<BR>&gt; address, however, it could be easily resolved to =
TE<BR>&gt;=20
  Router ID. In case of unnumbered TE link the TE<BR>&gt; Router<BR>&gt; =
ID is a=20
  part of the link ID. It is also guaranteed<BR>&gt; that TE Router ID =
is a=20
  stable routable IP address of<BR>&gt; the controller advertising the =
TE link.=20
  Hence, the<BR>&gt; recommendation makes a lot of sense to me ? =
extract<BR>&gt;=20
  TE<BR>&gt; Router ID from unnumbered link ID ERO subobject or<BR>&gt; =
resolve=20
  numbered TE link ID into TE Router ID, set<BR>&gt; it<BR>&gt; as =
destination=20
  in IP header of the RSVP Path message<BR>&gt; and forward the packet =
?the=20
  message will arrive at<BR>&gt; the<BR>&gt; controller managing next =
hop no=20
  matter how many<BR>&gt; actual<BR>&gt; IP hops the packet will make. =
In fact,=20
  that's how<BR>&gt; the<BR>&gt; control plane and data plane separation =
needs=20
  to be<BR>&gt; supported.<BR>&gt;<BR>&gt; Cheers,<BR>&gt; =
Igor<BR>&gt;<BR>&gt;=20
  --- [e-mail] wrote:<BR>&gt; &gt;<BR>&gt; &gt; =
this=20
  document is not ready as it prevents usage of<BR>&gt; &gt; the control =

  channel<BR>&gt; &gt; separation as defined in Section 8 of RFC =
3473<BR>&gt;=20
  (but<BR>&gt; &gt; also representation of<BR>&gt; &gt; complex =
nodes)<BR>&gt;=20
  &gt;<BR>&gt; &gt; i point out here the sentences from where this =
can<BR>&gt;=20
  &gt; be deduced:<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;A Path message is =
sent to=20
  the next hop node.<BR>&gt; It<BR>&gt; &gt; is RECOMMENDED that<BR>&gt; =
&gt;=20
  &nbsp; &nbsp;the TE router ID of the next hop node be used<BR>&gt; =
as<BR>&gt;=20
  &gt; an IP destination<BR>&gt; &gt; &nbsp; &nbsp;address in the packet =
that=20
  carries the RSVP-TE<BR>&gt; &gt; message. "<BR>&gt; &gt;<BR>&gt; &gt; =
combined=20
  with the following statements<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;... an =

  unnumbered link is identified by the<BR>&gt; &gt; &nbsp; =
&nbsp;combination of=20
  TE Router ID and a node-unique<BR>&gt; &gt; Interface ID."<BR>&gt;=20
  &gt;<BR>&gt; &gt; " &nbsp;It is RECOMMENDED that the IP tunnel=20
  endpoint<BR>&gt; &gt; address in the Session<BR>&gt; &gt; &nbsp; =
&nbsp;Object=20
  [RFC3209] be set to the TE Router ID of<BR>&gt; &gt; the egress since=20
  the<BR>&gt; &gt; &nbsp; &nbsp;TE Router ID is a unique routable ID per =

  node."<BR>&gt; &gt;<BR>&gt; &gt; [...]<BR>&gt; &gt;<BR>&gt; &gt; " =
&nbsp;It is=20
  RECOMMENDED that the IP tunnel sender<BR>&gt; &gt; address in the=20
  Sender<BR>&gt; &gt; &nbsp; &nbsp;Template Object [RFC3209] specifies =
the=20
  TE<BR>&gt; Router<BR>&gt; &gt; ID of the ingress<BR>&gt; &gt; &nbsp;=20
  &nbsp;since the TE Router ID is a unique routable ID<BR>&gt; &gt; per=20
  node."<BR>&gt; &gt;<BR>&gt; &gt; therefore, usage of the TE Router ID =
should=20
  be<BR>&gt; &gt; reviewed, such that it does<BR>&gt; &gt; not =
recommends the=20
  source and destination of IP<BR>&gt; &gt; packets to be the TE =
Router<BR>&gt;=20
  &gt; ID but simply a stable reachable control plane IP<BR>&gt; &gt; =
address of=20
  the<BR>&gt; &gt; next/previous hop<BR>&gt; &gt;<BR>&gt; &gt; also, =
there is a=20
  sentence in this document<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;The reason =
why the=20
  TE Router ID must be a<BR>&gt; &gt; reachable IP address is<BR>&gt; =
&gt;=20
  &nbsp; &nbsp;because in GMPLS, control and data plane names<BR>&gt; =
&gt;=20
  /addresses are not<BR>&gt; &gt; &nbsp; &nbsp;completely separated. =
"<BR>&gt;=20
  &gt;<BR>&gt; &gt; my response to this is of course if you use =
it<BR>&gt;=20
  like<BR>&gt; &gt; proposed in this<BR>&gt; &gt; document this problem=20
  occurs<BR>&gt; &gt;<BR>&gt; &gt; ps:<BR>&gt; &gt;<BR>&gt; &gt; section =
5.1.2=20
  of this document is unclear wrt<BR>&gt; &gt; section 1.1 of<BR>&gt;=20
  &gt;<BR>&gt;<BR>&lt;<A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensi=
ons-19.txt">http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-ext=
ensions-19.txt</A>&gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
  __________________________________<BR>&gt; Do you Yahoo!?<BR>&gt; Plan =
great=20
  trips with Yahoo! Travel: Now over 17,000<BR>&gt; guides!<BR>&gt; <A=20
  =
href=3D"http://travel.yahoo.com/p-travelguide">http://travel.yahoo.com/p-=
travelguide</A><BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR></FONT><BR><BR><FONT=20
  =
face=3DMonospace,Courier>________________________________________________=
__<BR>Do=20
  You Yahoo!?<BR>Tired of spam? &nbsp;Yahoo! Mail has the best spam =
protection=20
  around<BR><A=20
href=3D"http://mail.yahoo.com">http://mail.yahoo.com</A></FONT></P></BLOC=
KQUOTE></BODY></HTML>

------=_NextPart_000_0033_01C54537.38D5F130--




Envelope-to: [e-mail]
Delivery-date: Wed, 20 Apr 2005 02:53:55 +0000
From: "Richard Rabbat" <[e-mail]>
To: <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Addressing doc
Date: Tue, 19 Apr 2005 22:51:19 -0400
Message-ID: <002b01c54553$d6cc9120$1410a485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Dimitri,

> 
> this document is not ready as it prevents usage of the control channel
> separation as defined in Section 8 of RFC 3473 (but also 
> representation of
> complex nodes)
> 
> i point out here the sentences from where this can be deduced:
> 
> "  A Path message is sent to the next hop node.  It is 
> RECOMMENDED that
>    the TE router ID of the next hop node be used as an IP destination
>    address in the packet that carries the RSVP-TE message. "
> 
> combined with the following statements
> 
> "  ... an unnumbered link is identified by the
>    combination of TE Router ID and a node-unique Interface ID."
> 
> "  It is RECOMMENDED that the IP tunnel endpoint address in 
> the Session
>    Object [RFC3209] be set to the TE Router ID of the egress since the
>    TE Router ID is a unique routable ID per node."
> 
> [...]
> 
> "  It is RECOMMENDED that the IP tunnel sender address in the Sender
>    Template Object [RFC3209] specifies the TE Router ID of the ingress
>    since the TE Router ID is a unique routable ID per node."
> 
> therefore, usage of the TE Router ID should be reviewed, such 
> that it does
> not recommends the source and destination of IP packets to be 
> the TE Router
> ID but simply a stable reachable control plane IP address of the
> next/previous hop
> 
Thanks for the suggestion. We'll explain accordingly.

> also, there is a sentence in this document
> 
> "  The reason why the TE Router ID must be a reachable IP address is
>    because in GMPLS, control and data plane names /addresses are not
>    completely separated. "
> 
> my response to this is of course if you use it like proposed in this
> document this problem occurs
> 
> ps:
> 
> section 5.1.2 of this document is unclear wrt section 1.1 of
> <http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-ext
ensions-19.txt>

We'll clarify as well.
Richard.




Envelope-to: [e-mail]
Delivery-date: Tue, 19 Apr 2005 23:27:01 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54536.DB366253"
Subject: RE: Addressing doc
Date: Tue, 19 Apr 2005 19:23:55 -0400
Message-ID: <[e-mail]>
Thread-Topic: Addressing doc
Thread-Index: AcVDWIFpVpHLVv6mQIKn9IVnOXZo5QAdt63A
From: "Ong, Lyndon" <[e-mail]>
To: <[e-mail]>, "Igor Bryskin" <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>

This is a multi-part message in MIME format.

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

Hi Dimitri, et al,
=20
This is exactly the kind of issue that the addressing draft can bring =
out - the addressing draft
is the compilation of interpretations that a number of implementations =
have made when testing together
at Isocore - if these interpretations are not fully correct ones, the =
draft should be modified to
document this, for the benefit of  future implementation and testing.
=20
I agree with you on the text that should be removed from the document.  =
After the text is removed,
(and perhaps some explanatory text added)
it then seems to me to be a good idea to make this into a WG draft.
=20
Cheers,
=20
Lyndon

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On =
Behalf Of [e-mail]
Sent: Sunday, April 17, 2005 7:11 AM
To: Igor Bryskin
Cc: [e-mail]; Kireeti Kompella; =
[e-mail]
Subject: Re: Addressing doc



igor, i mentioned this because when some implement - for whatever =
purpose - a subset of capabilities and draw recommendations from this =
partial set, these should not by any means retrofit to the complete set =
of capabilities this protocol suite delivers or imply recommendations =
that would prevent from using its full set

coming to the below you have been mentioned on what this so-called =
separation does imply is that for constructing - and LMP can be used in =
helping this construction but this is also not mandatory - the TE =
topology make use of the TE router ID for the identification unnumbered =
interfaces and (abstract) nodes, (numbered interfaces are also part of =
this class of information - but obviously does not require the use of =
the TE Router ID) afterwards any control plane message exchange can make =
use of the IP control plane topology as long as these messages are =
exchanged between control plane entities that have initially advertized =
(i.e. as owner of) this information

hope this clarifies,

- dimitri.

Igor Bryskin <[e-mail]>
Sent by: [e-mail]
04/17/2005 05:50 MST

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella =
<[e-mail]>, [e-mail]
bcc:=20
Subject: Re: Addressing doc




Dimitri,

I think we are in agreement here. The only thing I
disagree with is your statement that the document is
not ready to be WG document for the reasons you have
provided. I am not the author of this document and I
let the authors tell what they think. However, the
whole point of the document, as far as I understand
it, is not to mandate something, rather, to provide a
set of recommendations based on the interop tests
experience, so that interoperability between different
vendors would be easier to achieve. Hence, they do not
need to spell out word RECOMMEND in every clause.

WRT TE Router ID. Of course, IFF there is some
knowledge or mechanism to translate TE addresses into
control plane IP addresses, any of next hop IP
addresses could be used as destination in RSVP Path
message IP packet. In this case IHMO  Te Router ID
does not even have to be routable, and full separation
between TE and control plane name spaces could be
achieved. I think LMP could help to do this. However,
one cannot mandate using LMP for every link in every
layer, especially, for IP/MPLS layer(s).

Igor

--- [e-mail] wrote:

>
> igor, my point is that if you recommend
>
> "  A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
>
> and
>
> "  ... an unnumbered link is identified by the
> combination of TE Router
>   ID and a node-unique Interface ID."
>
> then it is clear that the following occurs
>
> " The reason why the TE Router ID must be a
> reachable IP address is
>   because in GMPLS, control and data plane
> names/addresses are not
>   completely separated. "
>
> and the only change that needs to be done in this
> document in section 4.3
>
> "It is RECOMMENDED that a stable
>    control plane IP address of the next/previous hop
> node be used as an
>    IP destination address in RSVP-TE message.
>
>    A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message."
>
> is to remove the second paragraph, as there is
> nothing that mandates that
> communication between adjacent controllers should
> achieved through TE
> router ID (note: reading the document you will see
> that the section 5.2.1
> is indeed
> not completed just for this reason)
>
> in fact, this boils down to say that the TE router
> ID is not mandatorily
> used for hop-by-hop exchange of control messages as
> i can build adjacencies
> between neighboring nodes using the base IP routing
> topology, (by the way
> from where all restrictions that are pointed here
> below come from ?)
>
> thanks,
> - dimitri.
> ---
>
> Dimitri,
>
> Suppose a controller has just received an RSVP Path
> message that contains an ERO describing a path
> computed on the head-end (properly modified, of
> course, along the path). ERO is specified in terms
> of
> numbered or/and unnumbered TE links (and not IP
> addresses). Now the processing controller needs to
> forward the message to the controller that manages
> first non-local ERO sub-object. The question is what
> to set as destination in the IP header of the RSVP
> Path message? You are saying that it should a stable
> IP address of the controller managing the next hop.
> Where the processing controller is supposed to get
> this stable IP address from? All that it has is a
> numbered or unnumbered next hop TE link ID. It is
> not
> guaranteed that numbered TE link ID is a routable
> address, however, it could be easily resolved to TE
> Router ID. In case of unnumbered TE link the TE
> Router
> ID is a part of the link ID. It is also guaranteed
> that TE Router ID is a stable routable IP address of
> the controller advertising the TE link. Hence, the
> recommendation makes a lot of sense to me ? extract
> TE
> Router ID from unnumbered link ID ERO subobject or
> resolve numbered TE link ID into TE Router ID, set
> it
> as destination in IP header of the RSVP Path message
> and forward the packet ?the message will arrive at
> the
> controller managing next hop no matter how many
> actual
> IP hops the packet will make. In fact, that's how
> the
> control plane and data plane separation needs to be
> supported.
>
> Cheers,
> Igor
>
> --- [e-mail] wrote:
> >
> > this document is not ready as it prevents usage of
> > the control channel
> > separation as defined in Section 8 of RFC 3473
> (but
> > also representation of
> > complex nodes)
> >
> > i point out here the sentences from where this can
> > be deduced:
> >
> > "  A Path message is sent to the next hop node.
> It
> > is RECOMMENDED that
> >    the TE router ID of the next hop node be used
> as
> > an IP destination
> >    address in the packet that carries the RSVP-TE
> > message. "
> >
> > combined with the following statements
> >
> > "  ... an unnumbered link is identified by the
> >    combination of TE Router ID and a node-unique
> > Interface ID."
> >
> > "  It is RECOMMENDED that the IP tunnel endpoint
> > address in the Session
> >    Object [RFC3209] be set to the TE Router ID of
> > the egress since the
> >    TE Router ID is a unique routable ID per node."
> >
> > [...]
> >
> > "  It is RECOMMENDED that the IP tunnel sender
> > address in the Sender
> >    Template Object [RFC3209] specifies the TE
> Router
> > ID of the ingress
> >    since the TE Router ID is a unique routable ID
> > per node."
> >
> > therefore, usage of the TE Router ID should be
> > reviewed, such that it does
> > not recommends the source and destination of IP
> > packets to be the TE Router
> > ID but simply a stable reachable control plane IP
> > address of the
> > next/previous hop
> >
> > also, there is a sentence in this document
> >
> > "  The reason why the TE Router ID must be a
> > reachable IP address is
> >    because in GMPLS, control and data plane names
> > /addresses are not
> >    completely separated. "
> >
> > my response to this is of course if you use it
> like
> > proposed in this
> > document this problem occurs
> >
> > ps:
> >
> > section 5.1.2 of this document is unclear wrt
> > section 1.1 of
> >
>
< =
http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.t=
xt>
> >
> >
> >
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000
> guides!
> http://travel.yahoo.com/p-travelguide
>
>
>
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


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

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


<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Dimitri, et al,</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>This=20
is exactly the kind of issue that the addressing draft can bring out - =
the=20
addressing draft</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>is the=20
compilation of interpretations that a number of implementations have =
made when=20
testing together</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>at=20
Isocore - if these interpretations are not fully correct ones, the draft =
should=20
be modified to</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =

size=3D2>document this, for the benefit of&nbsp; future implementation =
and=20
testing.</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
agree with you on the text that should be removed from the =
document.&nbsp; After=20
the text is removed,</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>(and=20
perhaps some explanatory text added)</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =
size=3D2>it=20
then seems to me to be a good idea to make this into a WG=20
draft.</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D085403004-18042005><FONT face=3DArial color=3D#0000ff =

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

size=3D2>Lyndon</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of=20
  </B>[e-mail]<BR><B>Sent:</B> Sunday, April 17, =
2005=20
  7:11 AM<BR><B>To:</B> Igor Bryskin<BR><B>Cc:</B>=20
  [e-mail]; Kireeti Kompella;=20
  [e-mail]<BR><B>Subject:</B> Re: Addressing =
doc<BR><BR></FONT></DIV>
  <P><FONT face=3DMonospace,Courier>igor, i mentioned this because when =
some=20
  implement - for whatever purpose - a subset of capabilities and draw=20
  recommendations from this partial set, these should not by any means =
retrofit=20
  to the complete set of capabilities this protocol suite delivers or =
imply=20
  recommendations that would prevent from using its full set</FONT></P>
  <P><FONT face=3DMonospace,Courier>coming to the below you have been =
mentioned on=20
  what this so-called separation does imply is that for constructing - =
and LMP=20
  can be used in helping this construction but this is also not =
mandatory - the=20
  TE topology make use of the TE router ID for the identification =
unnumbered=20
  interfaces and (abstract) nodes, (numbered interfaces are also part of =
this=20
  class of information - but obviously does not require the use of the =
TE Router=20
  ID) afterwards any control plane message exchange can make use of the =
IP=20
  control plane topology as long as these messages are exchanged between =
control=20
  plane entities that have initially advertized (i.e. as owner of) this=20
  information</FONT></P>
  <P><FONT face=3DMonospace,Courier>hope this clarifies,</FONT></P>
  <P><FONT face=3DMonospace,Courier>- dimitri.<BR></FONT><BR><FONT =
size=3D2><B>Igor=20
  Bryskin &lt;[e-mail]&gt;</B></FONT><BR><FONT size=3D2>Sent =
by:=20
  [e-mail]</FONT><BR><FONT size=3D2>04/17/2005 05:50=20
  MST</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>Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, Kireeti Kompella=20
  &lt;[e-mail]&gt;, [e-mail]</FONT><BR><FONT=20
  size=3D2>bcc:</FONT> <BR><FONT size=3D2>Subject:</FONT> <FONT =
size=3D2>Re:=20
  Addressing doc</FONT><BR><BR><BR></P>
  <P><FONT face=3DMonospace,Courier>Dimitri,<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>I think we are in agreement here. The only =
thing=20
  I<BR>disagree with is your statement that the document is<BR>not ready =
to be=20
  WG document for the reasons you have<BR>provided. I am not the author =
of this=20
  document and I<BR>let the authors tell what they think. However, =
the<BR>whole=20
  point of the document, as far as I understand<BR>it, is not to mandate =

  something, rather, to provide a<BR>set of recommendations based on the =
interop=20
  tests<BR>experience, so that interoperability between =
different<BR>vendors=20
  would be easier to achieve. Hence, they do not<BR>need to spell out =
word=20
  RECOMMEND in every clause.<BR></FONT><BR><FONT =
face=3DMonospace,Courier>WRT TE=20
  Router ID. Of course, IFF there is some<BR>knowledge or mechanism to =
translate=20
  TE addresses into<BR>control plane IP addresses, any of next hop=20
  IP<BR>addresses could be used as destination in RSVP Path<BR>message =
IP=20
  packet. In this case IHMO &nbsp;Te Router ID<BR>does not even have to =
be=20
  routable, and full separation<BR>between TE and control plane name =
spaces=20
  could be<BR>achieved. I think LMP could help to do this. =
However,<BR>one=20
  cannot mandate using LMP for every link in every<BR>layer, especially, =
for=20
  IP/MPLS layer(s).<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>Igor<BR></FONT><BR><FONT =
face=3DMonospace,Courier>---=20
  [e-mail] wrote:<BR></FONT><BR><FONT=20
  face=3DMonospace,Courier>&gt;<BR>&gt; igor, my point is that if you=20
  recommend<BR>&gt;<BR>&gt; " &nbsp;A Path message is sent to the next =
hop node.=20
  It<BR>&gt; is RECOMMENDED that<BR>&gt; &nbsp; &nbsp;the TE router ID =
of the=20
  next hop node be used as<BR>&gt; an IP destination<BR>&gt; &nbsp;=20
  &nbsp;address in the packet that carries the RSVP-TE<BR>&gt; message.=20
  "<BR>&gt;<BR>&gt; and<BR>&gt;<BR>&gt; " &nbsp;... an unnumbered link =
is=20
  identified by the<BR>&gt; combination of TE Router<BR>&gt; &nbsp; ID =
and a=20
  node-unique Interface ID."<BR>&gt;<BR>&gt; then it is clear that the =
following=20
  occurs<BR>&gt;<BR>&gt; " The reason why the TE Router ID must be =
a<BR>&gt;=20
  reachable IP address is<BR>&gt; &nbsp; because in GMPLS, control and =
data=20
  plane<BR>&gt; names/addresses are not<BR>&gt; &nbsp; completely =
separated.=20
  "<BR>&gt;<BR>&gt; and the only change that needs to be done in =
this<BR>&gt;=20
  document in section 4.3<BR>&gt;<BR>&gt; "It is RECOMMENDED that a=20
  stable<BR>&gt; &nbsp; &nbsp;control plane IP address of the =
next/previous=20
  hop<BR>&gt; node be used as an<BR>&gt; &nbsp; &nbsp;IP destination =
address in=20
  RSVP-TE message.<BR>&gt;<BR>&gt; &nbsp; &nbsp;A Path message is sent =
to the=20
  next hop node. It<BR>&gt; is RECOMMENDED that<BR>&gt; &nbsp; &nbsp;the =
TE=20
  router ID of the next hop node be used as<BR>&gt; an IP =
destination<BR>&gt;=20
  &nbsp; &nbsp;address in the packet that carries the RSVP-TE<BR>&gt;=20
  message."<BR>&gt;<BR>&gt; is to remove the second paragraph, as there=20
  is<BR>&gt; nothing that mandates that<BR>&gt; communication between =
adjacent=20
  controllers should<BR>&gt; achieved through TE<BR>&gt; router ID =
(note:=20
  reading the document you will see<BR>&gt; that the section =
5.2.1<BR>&gt; is=20
  indeed<BR>&gt; not completed just for this reason)<BR>&gt;<BR>&gt; in =
fact,=20
  this boils down to say that the TE router<BR>&gt; ID is not=20
  mandatorily<BR>&gt; used for hop-by-hop exchange of control messages=20
  as<BR>&gt; i can build adjacencies<BR>&gt; between neighboring nodes =
using the=20
  base IP routing<BR>&gt; topology, (by the way<BR>&gt; from where all=20
  restrictions that are pointed here<BR>&gt; below come from =
?)<BR>&gt;<BR>&gt;=20
  thanks,<BR>&gt; - dimitri.<BR>&gt; ---<BR>&gt;<BR>&gt;=20
  Dimitri,<BR>&gt;<BR>&gt; Suppose a controller has just received an =
RSVP=20
  Path<BR>&gt; message that contains an ERO describing a path<BR>&gt; =
computed=20
  on the head-end (properly modified, of<BR>&gt; course, along the =
path). ERO is=20
  specified in terms<BR>&gt; of<BR>&gt; numbered or/and unnumbered TE =
links (and=20
  not IP<BR>&gt; addresses). Now the processing controller needs =
to<BR>&gt;=20
  forward the message to the controller that manages<BR>&gt; first =
non-local ERO=20
  sub-object. The question is what<BR>&gt; to set as destination in the =
IP=20
  header of the RSVP<BR>&gt; Path message? You are saying that it should =
a=20
  stable<BR>&gt; IP address of the controller managing the next =
hop.<BR>&gt;=20
  Where the processing controller is supposed to get<BR>&gt; this stable =
IP=20
  address from? All that it has is a<BR>&gt; numbered or unnumbered next =
hop TE=20
  link ID. It is<BR>&gt; not<BR>&gt; guaranteed that numbered TE link ID =
is a=20
  routable<BR>&gt; address, however, it could be easily resolved to =
TE<BR>&gt;=20
  Router ID. In case of unnumbered TE link the TE<BR>&gt; Router<BR>&gt; =
ID is a=20
  part of the link ID. It is also guaranteed<BR>&gt; that TE Router ID =
is a=20
  stable routable IP address of<BR>&gt; the controller advertising the =
TE link.=20
  Hence, the<BR>&gt; recommendation makes a lot of sense to me ? =
extract<BR>&gt;=20
  TE<BR>&gt; Router ID from unnumbered link ID ERO subobject or<BR>&gt; =
resolve=20
  numbered TE link ID into TE Router ID, set<BR>&gt; it<BR>&gt; as =
destination=20
  in IP header of the RSVP Path message<BR>&gt; and forward the packet =
?the=20
  message will arrive at<BR>&gt; the<BR>&gt; controller managing next =
hop no=20
  matter how many<BR>&gt; actual<BR>&gt; IP hops the packet will make. =
In fact,=20
  that's how<BR>&gt; the<BR>&gt; control plane and data plane separation =
needs=20
  to be<BR>&gt; supported.<BR>&gt;<BR>&gt; Cheers,<BR>&gt; =
Igor<BR>&gt;<BR>&gt;=20
  --- [e-mail] wrote:<BR>&gt; &gt;<BR>&gt; &gt; =
this=20
  document is not ready as it prevents usage of<BR>&gt; &gt; the control =

  channel<BR>&gt; &gt; separation as defined in Section 8 of RFC =
3473<BR>&gt;=20
  (but<BR>&gt; &gt; also representation of<BR>&gt; &gt; complex =
nodes)<BR>&gt;=20
  &gt;<BR>&gt; &gt; i point out here the sentences from where this =
can<BR>&gt;=20
  &gt; be deduced:<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;A Path message is =
sent to=20
  the next hop node.<BR>&gt; It<BR>&gt; &gt; is RECOMMENDED that<BR>&gt; =
&gt;=20
  &nbsp; &nbsp;the TE router ID of the next hop node be used<BR>&gt; =
as<BR>&gt;=20
  &gt; an IP destination<BR>&gt; &gt; &nbsp; &nbsp;address in the packet =
that=20
  carries the RSVP-TE<BR>&gt; &gt; message. "<BR>&gt; &gt;<BR>&gt; &gt; =
combined=20
  with the following statements<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;... an =

  unnumbered link is identified by the<BR>&gt; &gt; &nbsp; =
&nbsp;combination of=20
  TE Router ID and a node-unique<BR>&gt; &gt; Interface ID."<BR>&gt;=20
  &gt;<BR>&gt; &gt; " &nbsp;It is RECOMMENDED that the IP tunnel=20
  endpoint<BR>&gt; &gt; address in the Session<BR>&gt; &gt; &nbsp; =
&nbsp;Object=20
  [RFC3209] be set to the TE Router ID of<BR>&gt; &gt; the egress since=20
  the<BR>&gt; &gt; &nbsp; &nbsp;TE Router ID is a unique routable ID per =

  node."<BR>&gt; &gt;<BR>&gt; &gt; [...]<BR>&gt; &gt;<BR>&gt; &gt; " =
&nbsp;It is=20
  RECOMMENDED that the IP tunnel sender<BR>&gt; &gt; address in the=20
  Sender<BR>&gt; &gt; &nbsp; &nbsp;Template Object [RFC3209] specifies =
the=20
  TE<BR>&gt; Router<BR>&gt; &gt; ID of the ingress<BR>&gt; &gt; &nbsp;=20
  &nbsp;since the TE Router ID is a unique routable ID<BR>&gt; &gt; per=20
  node."<BR>&gt; &gt;<BR>&gt; &gt; therefore, usage of the TE Router ID =
should=20
  be<BR>&gt; &gt; reviewed, such that it does<BR>&gt; &gt; not =
recommends the=20
  source and destination of IP<BR>&gt; &gt; packets to be the TE =
Router<BR>&gt;=20
  &gt; ID but simply a stable reachable control plane IP<BR>&gt; &gt; =
address of=20
  the<BR>&gt; &gt; next/previous hop<BR>&gt; &gt;<BR>&gt; &gt; also, =
there is a=20
  sentence in this document<BR>&gt; &gt;<BR>&gt; &gt; " &nbsp;The reason =
why the=20
  TE Router ID must be a<BR>&gt; &gt; reachable IP address is<BR>&gt; =
&gt;=20
  &nbsp; &nbsp;because in GMPLS, control and data plane names<BR>&gt; =
&gt;=20
  /addresses are not<BR>&gt; &gt; &nbsp; &nbsp;completely separated. =
"<BR>&gt;=20
  &gt;<BR>&gt; &gt; my response to this is of course if you use =
it<BR>&gt;=20
  like<BR>&gt; &gt; proposed in this<BR>&gt; &gt; document this problem=20
  occurs<BR>&gt; &gt;<BR>&gt; &gt; ps:<BR>&gt; &gt;<BR>&gt; &gt; section =
5.1.2=20
  of this document is unclear wrt<BR>&gt; &gt; section 1.1 of<BR>&gt;=20
  &gt;<BR>&gt;<BR>&lt;<A=20
  =
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensi=
ons-19.txt">http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-ext=
ensions-19.txt</A>&gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
  __________________________________<BR>&gt; Do you Yahoo!?<BR>&gt; Plan =
great=20
  trips with Yahoo! Travel: Now over 17,000<BR>&gt; guides!<BR>&gt; <A=20
  =
href=3D"http://travel.yahoo.com/p-travelguide">http://travel.yahoo.com/p-=
travelguide</A><BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR></FONT><BR><BR><FONT=20
  =
face=3DMonospace,Courier>________________________________________________=
__<BR>Do=20
  You Yahoo!?<BR>Tired of spam? &nbsp;Yahoo! Mail has the best spam =
protection=20
  around<BR><A=20
href=3D"http://mail.yahoo.com">http://mail.yahoo.com</A></FONT></P></BLOC=
KQUOTE></BODY></HTML>

------_=_NextPart_001_01C54536.DB366253--



Envelope-to: [e-mail]
Delivery-date: Sun, 17 Apr 2005 14:13:31 +0000
MIME-Version: 1.0
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], Kireeti Kompella <[e-mail]>, [e-mail]
From: [e-mail]
Subject: Re: Addressing doc
Date: Sun, 17 Apr 2005 16:11:26 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmlnb3IsIGkgbWVudGlvbmVkIHRoaXMg
YmVjYXVzZSB3aGVuIHNvbWUgaW1wbGVtZW50IC0gZm9yIHdoYXRldmVyIHB1cnBvc2UgLSBhIHN1
YnNldCBvZiBjYXBhYmlsaXRpZXMgYW5kIGRyYXcgcmVjb21tZW5kYXRpb25zIGZyb20gdGhpcyBw
YXJ0aWFsIHNldCwgdGhlc2Ugc2hvdWxkIG5vdCBieSBhbnkgbWVhbnMgcmV0cm9maXQgdG8gdGhl
IGNvbXBsZXRlIHNldCBvZiBjYXBhYmlsaXRpZXMgdGhpcyBwcm90b2NvbCBzdWl0ZSBkZWxpdmVy
cyBvciBpbXBseSByZWNvbW1lbmRhdGlvbnMgdGhhdCB3b3VsZCBwcmV2ZW50IGZyb20gdXNpbmcg
aXRzIGZ1bGwgc2V0PC9GT05UPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
Y29taW5nIHRvIHRoZSBiZWxvdyB5b3UgaGF2ZSBiZWVuIG1lbnRpb25lZCBvbiB3aGF0IHRoaXMg
c28tY2FsbGVkIHNlcGFyYXRpb24gZG9lcyBpbXBseSBpcyB0aGF0IGZvciBjb25zdHJ1Y3Rpbmcg
LSBhbmQgTE1QIGNhbiBiZSB1c2VkIGluIGhlbHBpbmcgdGhpcyBjb25zdHJ1Y3Rpb24gYnV0IHRo
aXMgaXMgYWxzbyBub3QgbWFuZGF0b3J5IC0gdGhlIFRFIHRvcG9sb2d5IG1ha2UgdXNlIG9mIHRo
ZSBURSByb3V0ZXIgSUQgZm9yIHRoZSBpZGVudGlmaWNhdGlvbiB1bm51bWJlcmVkIGludGVyZmFj
ZXMgYW5kIChhYnN0cmFjdCkgbm9kZXMsIChudW1iZXJlZCBpbnRlcmZhY2VzIGFyZSBhbHNvIHBh
cnQgb2YgdGhpcyBjbGFzcyBvZiBpbmZvcm1hdGlvbiAtIGJ1dCBvYnZpb3VzbHkgZG9lcyBub3Qg
cmVxdWlyZSB0aGUgdXNlIG9mIHRoZSBURSBSb3V0ZXIgSUQpIGFmdGVyd2FyZHMgYW55IGNvbnRy
b2wgcGxhbmUgbWVzc2FnZSBleGNoYW5nZSBjYW4gbWFrZSB1c2Ugb2YgdGhlIElQIGNvbnRyb2wg
cGxhbmUgdG9wb2xvZ3kgYXMgbG9uZyBhcyB0aGVzZSBtZXNzYWdlcyBhcmUgZXhjaGFuZ2VkIGJl
dHdlZW4gY29udHJvbCBwbGFuZSBlbnRpdGllcyB0aGF0IGhhdmUgaW5pdGlhbGx5IGFkdmVydGl6
ZWQgKGkuZS4gYXMgb3duZXIgb2YpIHRoaXMgaW5mb3JtYXRpb248L0ZPTlQ+PC9QPjxQPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5ob3BlIHRoaXMgY2xhcmlmaWVzLDwvRk9OVD48L1A+
PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPi0gZGltaXRyaS48QlI+PC9GT05UPjxC
Uj48Rk9OVCBTSVpFPTI+PEI+SWdvciBCcnlza2luICZsdDtpX2JyeXNraW5AeWFob28uY29tJmd0
OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0
Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNC8xNy8yMDA1IDA1OjUwIE1TVDwvRk9OVD48
QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRyaSBQQVBB
RElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxGT05UIFNJWkU9Mj5jYzo8
L0ZPTlQ+IDxGT05UIFNJWkU9Mj5EaW1pdHJpIFBBUEFESU1JVFJJT1UvQkUvQUxDQVRFTEBBTENB
VEVMLCBLaXJlZXRpIEtvbXBlbGxhICZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OywgY2NhbXBA
b3BzLmlldGYub3JnPC9GT05UPjxCUj4gPEZPTlQgU0laRT0yPmJjYzo8L0ZPTlQ+IDxCUj48Rk9O
VCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SZTogQWRkcmVzc2luZyBkb2M8
L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+
RGltaXRyaSw8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SSB0
aGluayB3ZSBhcmUgaW4gYWdyZWVtZW50IGhlcmUuIFRoZSBvbmx5IHRoaW5nIEk8QlI+ZGlzYWdy
ZWUgd2l0aCBpcyB5b3VyIHN0YXRlbWVudCB0aGF0IHRoZSBkb2N1bWVudCBpczxCUj5ub3QgcmVh
ZHkgdG8gYmUgV0cgZG9jdW1lbnQgZm9yIHRoZSByZWFzb25zIHlvdSBoYXZlPEJSPnByb3ZpZGVk
LiBJIGFtIG5vdCB0aGUgYXV0aG9yIG9mIHRoaXMgZG9jdW1lbnQgYW5kIEk8QlI+bGV0IHRoZSBh
dXRob3JzIHRlbGwgd2hhdCB0aGV5IHRoaW5rLiBIb3dldmVyLCB0aGU8QlI+d2hvbGUgcG9pbnQg
b2YgdGhlIGRvY3VtZW50LCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kPEJSPml0LCBpcyBub3QgdG8g
bWFuZGF0ZSBzb21ldGhpbmcsIHJhdGhlciwgdG8gcHJvdmlkZSBhPEJSPnNldCBvZiByZWNvbW1l
bmRhdGlvbnMgYmFzZWQgb24gdGhlIGludGVyb3AgdGVzdHM8QlI+ZXhwZXJpZW5jZSwgc28gdGhh
dCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gZGlmZmVyZW50PEJSPnZlbmRvcnMgd291bGQgYmUg
ZWFzaWVyIHRvIGFjaGlldmUuIEhlbmNlLCB0aGV5IGRvIG5vdDxCUj5uZWVkIHRvIHNwZWxsIG91
dCB3b3JkIFJFQ09NTUVORCBpbiBldmVyeSBjbGF1c2UuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPldSVCBURSBSb3V0ZXIgSUQuIE9mIGNvdXJzZSwgSUZGIHRo
ZXJlIGlzIHNvbWU8QlI+a25vd2xlZGdlIG9yIG1lY2hhbmlzbSB0byB0cmFuc2xhdGUgVEUgYWRk
cmVzc2VzIGludG88QlI+Y29udHJvbCBwbGFuZSBJUCBhZGRyZXNzZXMsIGFueSBvZiBuZXh0IGhv
cCBJUDxCUj5hZGRyZXNzZXMgY291bGQgYmUgdXNlZCBhcyBkZXN0aW5hdGlvbiBpbiBSU1ZQIFBh
dGg8QlI+bWVzc2FnZSBJUCBwYWNrZXQuIEluIHRoaXMgY2FzZSBJSE1PICZuYnNwO1RlIFJvdXRl
ciBJRDxCUj5kb2VzIG5vdCBldmVuIGhhdmUgdG8gYmUgcm91dGFibGUsIGFuZCBmdWxsIHNlcGFy
YXRpb248QlI+YmV0d2VlbiBURSBhbmQgY29udHJvbCBwbGFuZSBuYW1lIHNwYWNlcyBjb3VsZCBi
ZTxCUj5hY2hpZXZlZC4gSSB0aGluayBMTVAgY291bGQgaGVscCB0byBkbyB0aGlzLiBIb3dldmVy
LDxCUj5vbmUgY2Fubm90IG1hbmRhdGUgdXNpbmcgTE1QIGZvciBldmVyeSBsaW5rIGluIGV2ZXJ5
PEJSPmxheWVyLCBlc3BlY2lhbGx5LCBmb3IgSVAvTVBMUyBsYXllcihzKS48QlI+PC9GT05UPjxC
Uj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+SWdvcjxCUj48L0ZPTlQ+PEJSPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj4tLS0gRGltaXRyaS5QYXBhZGltaXRyaW91QGFsY2F0
ZWwuYmUgd3JvdGU6PEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PiZndDs8QlI+Jmd0OyBpZ29yLCBteSBwb2ludCBpcyB0aGF0IGlmIHlvdSByZWNvbW1lbmQ8QlI+
Jmd0OzxCUj4mZ3Q7ICZxdW90OyAmbmJzcDtBIFBhdGggbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBu
ZXh0IGhvcCBub2RlLiBJdDxCUj4mZ3Q7IGlzIFJFQ09NTUVOREVEIHRoYXQ8QlI+Jmd0OyAmbmJz
cDsgJm5ic3A7dGhlIFRFIHJvdXRlciBJRCBvZiB0aGUgbmV4dCBob3Agbm9kZSBiZSB1c2VkIGFz
PEJSPiZndDsgYW4gSVAgZGVzdGluYXRpb248QlI+Jmd0OyAmbmJzcDsgJm5ic3A7YWRkcmVzcyBp
biB0aGUgcGFja2V0IHRoYXQgY2FycmllcyB0aGUgUlNWUC1URTxCUj4mZ3Q7IG1lc3NhZ2UuICZx
dW90OzxCUj4mZ3Q7PEJSPiZndDsgYW5kPEJSPiZndDs8QlI+Jmd0OyAmcXVvdDsgJm5ic3A7Li4u
IGFuIHVubnVtYmVyZWQgbGluayBpcyBpZGVudGlmaWVkIGJ5IHRoZTxCUj4mZ3Q7IGNvbWJpbmF0
aW9uIG9mIFRFIFJvdXRlcjxCUj4mZ3Q7ICZuYnNwOyBJRCBhbmQgYSBub2RlLXVuaXF1ZSBJbnRl
cmZhY2UgSUQuJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyB0aGVuIGl0IGlzIGNsZWFyIHRoYXQgdGhl
IGZvbGxvd2luZyBvY2N1cnM8QlI+Jmd0OzxCUj4mZ3Q7ICZxdW90OyBUaGUgcmVhc29uIHdoeSB0
aGUgVEUgUm91dGVyIElEIG11c3QgYmUgYTxCUj4mZ3Q7IHJlYWNoYWJsZSBJUCBhZGRyZXNzIGlz
PEJSPiZndDsgJm5ic3A7IGJlY2F1c2UgaW4gR01QTFMsIGNvbnRyb2wgYW5kIGRhdGEgcGxhbmU8
QlI+Jmd0OyBuYW1lcy9hZGRyZXNzZXMgYXJlIG5vdDxCUj4mZ3Q7ICZuYnNwOyBjb21wbGV0ZWx5
IHNlcGFyYXRlZC4gJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBhbmQgdGhlIG9ubHkgY2hhbmdlIHRo
YXQgbmVlZHMgdG8gYmUgZG9uZSBpbiB0aGlzPEJSPiZndDsgZG9jdW1lbnQgaW4gc2VjdGlvbiA0
LjM8QlI+Jmd0OzxCUj4mZ3Q7ICZxdW90O0l0IGlzIFJFQ09NTUVOREVEIHRoYXQgYSBzdGFibGU8
QlI+Jmd0OyAmbmJzcDsgJm5ic3A7Y29udHJvbCBwbGFuZSBJUCBhZGRyZXNzIG9mIHRoZSBuZXh0
L3ByZXZpb3VzIGhvcDxCUj4mZ3Q7IG5vZGUgYmUgdXNlZCBhcyBhbjxCUj4mZ3Q7ICZuYnNwOyAm
bmJzcDtJUCBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIFJTVlAtVEUgbWVzc2FnZS48QlI+Jmd0OzxC
Uj4mZ3Q7ICZuYnNwOyAmbmJzcDtBIFBhdGggbWVzc2FnZSBpcyBzZW50IHRvIHRoZSBuZXh0IGhv
cCBub2RlLiBJdDxCUj4mZ3Q7IGlzIFJFQ09NTUVOREVEIHRoYXQ8QlI+Jmd0OyAmbmJzcDsgJm5i
c3A7dGhlIFRFIHJvdXRlciBJRCBvZiB0aGUgbmV4dCBob3Agbm9kZSBiZSB1c2VkIGFzPEJSPiZn
dDsgYW4gSVAgZGVzdGluYXRpb248QlI+Jmd0OyAmbmJzcDsgJm5ic3A7YWRkcmVzcyBpbiB0aGUg
cGFja2V0IHRoYXQgY2FycmllcyB0aGUgUlNWUC1URTxCUj4mZ3Q7IG1lc3NhZ2UuJnF1b3Q7PEJS
PiZndDs8QlI+Jmd0OyBpcyB0byByZW1vdmUgdGhlIHNlY29uZCBwYXJhZ3JhcGgsIGFzIHRoZXJl
IGlzPEJSPiZndDsgbm90aGluZyB0aGF0IG1hbmRhdGVzIHRoYXQ8QlI+Jmd0OyBjb21tdW5pY2F0
aW9uIGJldHdlZW4gYWRqYWNlbnQgY29udHJvbGxlcnMgc2hvdWxkPEJSPiZndDsgYWNoaWV2ZWQg
dGhyb3VnaCBURTxCUj4mZ3Q7IHJvdXRlciBJRCAobm90ZTogcmVhZGluZyB0aGUgZG9jdW1lbnQg
eW91IHdpbGwgc2VlPEJSPiZndDsgdGhhdCB0aGUgc2VjdGlvbiA1LjIuMTxCUj4mZ3Q7IGlzIGlu
ZGVlZDxCUj4mZ3Q7IG5vdCBjb21wbGV0ZWQganVzdCBmb3IgdGhpcyByZWFzb24pPEJSPiZndDs8
QlI+Jmd0OyBpbiBmYWN0LCB0aGlzIGJvaWxzIGRvd24gdG8gc2F5IHRoYXQgdGhlIFRFIHJvdXRl
cjxCUj4mZ3Q7IElEIGlzIG5vdCBtYW5kYXRvcmlseTxCUj4mZ3Q7IHVzZWQgZm9yIGhvcC1ieS1o
b3AgZXhjaGFuZ2Ugb2YgY29udHJvbCBtZXNzYWdlcyBhczxCUj4mZ3Q7IGkgY2FuIGJ1aWxkIGFk
amFjZW5jaWVzPEJSPiZndDsgYmV0d2VlbiBuZWlnaGJvcmluZyBub2RlcyB1c2luZyB0aGUgYmFz
ZSBJUCByb3V0aW5nPEJSPiZndDsgdG9wb2xvZ3ksIChieSB0aGUgd2F5PEJSPiZndDsgZnJvbSB3
aGVyZSBhbGwgcmVzdHJpY3Rpb25zIHRoYXQgYXJlIHBvaW50ZWQgaGVyZTxCUj4mZ3Q7IGJlbG93
IGNvbWUgZnJvbSA/KTxCUj4mZ3Q7PEJSPiZndDsgdGhhbmtzLDxCUj4mZ3Q7IC0gZGltaXRyaS48
QlI+Jmd0OyAtLS08QlI+Jmd0OzxCUj4mZ3Q7IERpbWl0cmksPEJSPiZndDs8QlI+Jmd0OyBTdXBw
b3NlIGEgY29udHJvbGxlciBoYXMganVzdCByZWNlaXZlZCBhbiBSU1ZQIFBhdGg8QlI+Jmd0OyBt
ZXNzYWdlIHRoYXQgY29udGFpbnMgYW4gRVJPIGRlc2NyaWJpbmcgYSBwYXRoPEJSPiZndDsgY29t
cHV0ZWQgb24gdGhlIGhlYWQtZW5kIChwcm9wZXJseSBtb2RpZmllZCwgb2Y8QlI+Jmd0OyBjb3Vy
c2UsIGFsb25nIHRoZSBwYXRoKS4gRVJPIGlzIHNwZWNpZmllZCBpbiB0ZXJtczxCUj4mZ3Q7IG9m
PEJSPiZndDsgbnVtYmVyZWQgb3IvYW5kIHVubnVtYmVyZWQgVEUgbGlua3MgKGFuZCBub3QgSVA8
QlI+Jmd0OyBhZGRyZXNzZXMpLiBOb3cgdGhlIHByb2Nlc3NpbmcgY29udHJvbGxlciBuZWVkcyB0
bzxCUj4mZ3Q7IGZvcndhcmQgdGhlIG1lc3NhZ2UgdG8gdGhlIGNvbnRyb2xsZXIgdGhhdCBtYW5h
Z2VzPEJSPiZndDsgZmlyc3Qgbm9uLWxvY2FsIEVSTyBzdWItb2JqZWN0LiBUaGUgcXVlc3Rpb24g
aXMgd2hhdDxCUj4mZ3Q7IHRvIHNldCBhcyBkZXN0aW5hdGlvbiBpbiB0aGUgSVAgaGVhZGVyIG9m
IHRoZSBSU1ZQPEJSPiZndDsgUGF0aCBtZXNzYWdlPyBZb3UgYXJlIHNheWluZyB0aGF0IGl0IHNo
b3VsZCBhIHN0YWJsZTxCUj4mZ3Q7IElQIGFkZHJlc3Mgb2YgdGhlIGNvbnRyb2xsZXIgbWFuYWdp
bmcgdGhlIG5leHQgaG9wLjxCUj4mZ3Q7IFdoZXJlIHRoZSBwcm9jZXNzaW5nIGNvbnRyb2xsZXIg
aXMgc3VwcG9zZWQgdG8gZ2V0PEJSPiZndDsgdGhpcyBzdGFibGUgSVAgYWRkcmVzcyBmcm9tPyBB
bGwgdGhhdCBpdCBoYXMgaXMgYTxCUj4mZ3Q7IG51bWJlcmVkIG9yIHVubnVtYmVyZWQgbmV4dCBo
b3AgVEUgbGluayBJRC4gSXQgaXM8QlI+Jmd0OyBub3Q8QlI+Jmd0OyBndWFyYW50ZWVkIHRoYXQg
bnVtYmVyZWQgVEUgbGluayBJRCBpcyBhIHJvdXRhYmxlPEJSPiZndDsgYWRkcmVzcywgaG93ZXZl
ciwgaXQgY291bGQgYmUgZWFzaWx5IHJlc29sdmVkIHRvIFRFPEJSPiZndDsgUm91dGVyIElELiBJ
biBjYXNlIG9mIHVubnVtYmVyZWQgVEUgbGluayB0aGUgVEU8QlI+Jmd0OyBSb3V0ZXI8QlI+Jmd0
OyBJRCBpcyBhIHBhcnQgb2YgdGhlIGxpbmsgSUQuIEl0IGlzIGFsc28gZ3VhcmFudGVlZDxCUj4m
Z3Q7IHRoYXQgVEUgUm91dGVyIElEIGlzIGEgc3RhYmxlIHJvdXRhYmxlIElQIGFkZHJlc3Mgb2Y8
QlI+Jmd0OyB0aGUgY29udHJvbGxlciBhZHZlcnRpc2luZyB0aGUgVEUgbGluay4gSGVuY2UsIHRo
ZTxCUj4mZ3Q7IHJlY29tbWVuZGF0aW9uIG1ha2VzIGEgbG90IG9mIHNlbnNlIHRvIG1lID8gZXh0
cmFjdDxCUj4mZ3Q7IFRFPEJSPiZndDsgUm91dGVyIElEIGZyb20gdW5udW1iZXJlZCBsaW5rIElE
IEVSTyBzdWJvYmplY3Qgb3I8QlI+Jmd0OyByZXNvbHZlIG51bWJlcmVkIFRFIGxpbmsgSUQgaW50
byBURSBSb3V0ZXIgSUQsIHNldDxCUj4mZ3Q7IGl0PEJSPiZndDsgYXMgZGVzdGluYXRpb24gaW4g
SVAgaGVhZGVyIG9mIHRoZSBSU1ZQIFBhdGggbWVzc2FnZTxCUj4mZ3Q7IGFuZCBmb3J3YXJkIHRo
ZSBwYWNrZXQgP3RoZSBtZXNzYWdlIHdpbGwgYXJyaXZlIGF0PEJSPiZndDsgdGhlPEJSPiZndDsg
Y29udHJvbGxlciBtYW5hZ2luZyBuZXh0IGhvcCBubyBtYXR0ZXIgaG93IG1hbnk8QlI+Jmd0OyBh
Y3R1YWw8QlI+Jmd0OyBJUCBob3BzIHRoZSBwYWNrZXQgd2lsbCBtYWtlLiBJbiBmYWN0LCB0aGF0
J3MgaG93PEJSPiZndDsgdGhlPEJSPiZndDsgY29udHJvbCBwbGFuZSBhbmQgZGF0YSBwbGFuZSBz
ZXBhcmF0aW9uIG5lZWRzIHRvIGJlPEJSPiZndDsgc3VwcG9ydGVkLjxCUj4mZ3Q7PEJSPiZndDsg
Q2hlZXJzLDxCUj4mZ3Q7IElnb3I8QlI+Jmd0OzxCUj4mZ3Q7IC0tLSBEaW1pdHJpLlBhcGFkaW1p
dHJpb3VAYWxjYXRlbC5iZSB3cm90ZTo8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyB0aGlzIGRv
Y3VtZW50IGlzIG5vdCByZWFkeSBhcyBpdCBwcmV2ZW50cyB1c2FnZSBvZjxCUj4mZ3Q7ICZndDsg
dGhlIGNvbnRyb2wgY2hhbm5lbDxCUj4mZ3Q7ICZndDsgc2VwYXJhdGlvbiBhcyBkZWZpbmVkIGlu
IFNlY3Rpb24gOCBvZiBSRkMgMzQ3MzxCUj4mZ3Q7IChidXQ8QlI+Jmd0OyAmZ3Q7IGFsc28gcmVw
cmVzZW50YXRpb24gb2Y8QlI+Jmd0OyAmZ3Q7IGNvbXBsZXggbm9kZXMpPEJSPiZndDsgJmd0OzxC
Uj4mZ3Q7ICZndDsgaSBwb2ludCBvdXQgaGVyZSB0aGUgc2VudGVuY2VzIGZyb20gd2hlcmUgdGhp
cyBjYW48QlI+Jmd0OyAmZ3Q7IGJlIGRlZHVjZWQ6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsg
JnF1b3Q7ICZuYnNwO0EgUGF0aCBtZXNzYWdlIGlzIHNlbnQgdG8gdGhlIG5leHQgaG9wIG5vZGUu
PEJSPiZndDsgSXQ8QlI+Jmd0OyAmZ3Q7IGlzIFJFQ09NTUVOREVEIHRoYXQ8QlI+Jmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDt0aGUgVEUgcm91dGVyIElEIG9mIHRoZSBuZXh0IGhvcCBub2RlIGJlIHVz
ZWQ8QlI+Jmd0OyBhczxCUj4mZ3Q7ICZndDsgYW4gSVAgZGVzdGluYXRpb248QlI+Jmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDthZGRyZXNzIGluIHRoZSBwYWNrZXQgdGhhdCBjYXJyaWVzIHRoZSBSU1ZQ
LVRFPEJSPiZndDsgJmd0OyBtZXNzYWdlLiAmcXVvdDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OyBjb21iaW5lZCB3aXRoIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50czxCUj4mZ3Q7ICZndDs8QlI+
Jmd0OyAmZ3Q7ICZxdW90OyAmbmJzcDsuLi4gYW4gdW5udW1iZXJlZCBsaW5rIGlzIGlkZW50aWZp
ZWQgYnkgdGhlPEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Y29tYmluYXRpb24gb2YgVEUgUm91
dGVyIElEIGFuZCBhIG5vZGUtdW5pcXVlPEJSPiZndDsgJmd0OyBJbnRlcmZhY2UgSUQuJnF1b3Q7
PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJnF1b3Q7ICZuYnNwO0l0IGlzIFJFQ09NTUVOREVE
IHRoYXQgdGhlIElQIHR1bm5lbCBlbmRwb2ludDxCUj4mZ3Q7ICZndDsgYWRkcmVzcyBpbiB0aGUg
U2Vzc2lvbjxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO09iamVjdCBbUkZDMzIwOV0gYmUgc2V0
IHRvIHRoZSBURSBSb3V0ZXIgSUQgb2Y8QlI+Jmd0OyAmZ3Q7IHRoZSBlZ3Jlc3Mgc2luY2UgdGhl
PEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VEUgUm91dGVyIElEIGlzIGEgdW5pcXVlIHJvdXRh
YmxlIElEIHBlciBub2RlLiZxdW90OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IFsuLi5dPEJS
PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJnF1b3Q7ICZuYnNwO0l0IGlzIFJFQ09NTUVOREVEIHRo
YXQgdGhlIElQIHR1bm5lbCBzZW5kZXI8QlI+Jmd0OyAmZ3Q7IGFkZHJlc3MgaW4gdGhlIFNlbmRl
cjxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RlbXBsYXRlIE9iamVjdCBbUkZDMzIwOV0gc3Bl
Y2lmaWVzIHRoZSBURTxCUj4mZ3Q7IFJvdXRlcjxCUj4mZ3Q7ICZndDsgSUQgb2YgdGhlIGluZ3Jl
c3M8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtzaW5jZSB0aGUgVEUgUm91dGVyIElEIGlzIGEg
dW5pcXVlIHJvdXRhYmxlIElEPEJSPiZndDsgJmd0OyBwZXIgbm9kZS4mcXVvdDs8QlI+Jmd0OyAm
Z3Q7PEJSPiZndDsgJmd0OyB0aGVyZWZvcmUsIHVzYWdlIG9mIHRoZSBURSBSb3V0ZXIgSUQgc2hv
dWxkIGJlPEJSPiZndDsgJmd0OyByZXZpZXdlZCwgc3VjaCB0aGF0IGl0IGRvZXM8QlI+Jmd0OyAm
Z3Q7IG5vdCByZWNvbW1lbmRzIHRoZSBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIG9mIElQPEJSPiZn
dDsgJmd0OyBwYWNrZXRzIHRvIGJlIHRoZSBURSBSb3V0ZXI8QlI+Jmd0OyAmZ3Q7IElEIGJ1dCBz
aW1wbHkgYSBzdGFibGUgcmVhY2hhYmxlIGNvbnRyb2wgcGxhbmUgSVA8QlI+Jmd0OyAmZ3Q7IGFk
ZHJlc3Mgb2YgdGhlPEJSPiZndDsgJmd0OyBuZXh0L3ByZXZpb3VzIGhvcDxCUj4mZ3Q7ICZndDs8
QlI+Jmd0OyAmZ3Q7IGFsc28sIHRoZXJlIGlzIGEgc2VudGVuY2UgaW4gdGhpcyBkb2N1bWVudDxC
Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZxdW90OyAmbmJzcDtUaGUgcmVhc29uIHdoeSB0aGUg
VEUgUm91dGVyIElEIG11c3QgYmUgYTxCUj4mZ3Q7ICZndDsgcmVhY2hhYmxlIElQIGFkZHJlc3Mg
aXM8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtiZWNhdXNlIGluIEdNUExTLCBjb250cm9sIGFu
ZCBkYXRhIHBsYW5lIG5hbWVzPEJSPiZndDsgJmd0OyAvYWRkcmVzc2VzIGFyZSBub3Q8QlI+Jmd0
OyAmZ3Q7ICZuYnNwOyAmbmJzcDtjb21wbGV0ZWx5IHNlcGFyYXRlZC4gJnF1b3Q7PEJSPiZndDsg
Jmd0OzxCUj4mZ3Q7ICZndDsgbXkgcmVzcG9uc2UgdG8gdGhpcyBpcyBvZiBjb3Vyc2UgaWYgeW91
IHVzZSBpdDxCUj4mZ3Q7IGxpa2U8QlI+Jmd0OyAmZ3Q7IHByb3Bvc2VkIGluIHRoaXM8QlI+Jmd0
OyAmZ3Q7IGRvY3VtZW50IHRoaXMgcHJvYmxlbSBvY2N1cnM8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsg
Jmd0OyBwczo8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBzZWN0aW9uIDUuMS4yIG9mIHRoaXMg
ZG9jdW1lbnQgaXMgdW5jbGVhciB3cnQ8QlI+Jmd0OyAmZ3Q7IHNlY3Rpb24gMS4xIG9mPEJSPiZn
dDsgJmd0OzxCUj4mZ3Q7PEJSPiZsdDs8QSBIUkVGPWh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWlldGYtaXNpcy1nbXBscy1leHRlbnNpb25zLTE5LnR4dD5odHRwOi8v
d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWlzaXMtZ21wbHMtZXh0ZW5z
aW9ucy0xOS50eHQ8L0E+Jmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0
OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBEbyB5b3UgWWFob28hPzxC
Uj4mZ3Q7IFBsYW4gZ3JlYXQgdHJpcHMgd2l0aCBZYWhvbyEgVHJhdmVsOiBOb3cgb3ZlciAxNyww
MDA8QlI+Jmd0OyBndWlkZXMhPEJSPiZndDsgPEEgSFJFRj1odHRwOi8vdHJhdmVsLnlhaG9vLmNv
bS9wLXRyYXZlbGd1aWRlPmh0dHA6Ly90cmF2ZWwueWFob28uY29tL3AtdHJhdmVsZ3VpZGU8L0E+
PEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+PC9GT05UPjxCUj48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPEJSPkRvIFlvdSBZYWhvbyE/PEJSPlRpcmVkIG9mIHNwYW0/ICZu
YnNwO1lhaG9vISBNYWlsIGhhcyB0aGUgYmVzdCBzcGFtIHByb3RlY3Rpb24gYXJvdW5kPEJSPjxB
IEhSRUY9aHR0cDovL21haWwueWFob28uY29tPmh0dHA6Ly9tYWlsLnlhaG9vLmNvbTwvQT48L0ZP
TlQ+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Sun, 17 Apr 2005 12:52:02 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=4KEGfDzv6EkVGzvyEXYJEsYgpxcxlFFpVqYxh1xCgjrJ+e2ZLVQ2dhFmG1OgPqrF8JyJ0dRxv4dKidPl1U/zyg4P2lLZGSCl5jTA/6+BJmpOan+yaZWDPN8JYXG8pn0w18l4rXoP7NFCEqKk/b1KBBjvrqSA4PWgojmewaCEmyE=  ;
Message-ID: <[e-mail]>
Date: Sun, 17 Apr 2005 05:50:02 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: Addressing doc
To: [e-mail]
Cc: [e-mail], Kireeti Kompella <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Dimitri,

I think we are in agreement here. The only thing I
disagree with is your statement that the document is
not ready to be WG document for the reasons you have
provided. I am not the author of this document and I
let the authors tell what they think. However, the
whole point of the document, as far as I understand
it, is not to mandate something, rather, to provide a
set of recommendations based on the interop tests
experience, so that interoperability between different
vendors would be easier to achieve. Hence, they do not
need to spell out word RECOMMEND in every clause.

WRT TE Router ID. Of course, IFF there is some
knowledge or mechanism to translate TE addresses into
control plane IP addresses, any of next hop IP
addresses could be used as destination in RSVP Path
message IP packet. In this case IHMO  Te Router ID
does not even have to be routable, and full separation
between TE and control plane name spaces could be
achieved. I think LMP could help to do this. However,
one cannot mandate using LMP for every link in every
layer, especially, for IP/MPLS layer(s). 

Igor

--- [e-mail] wrote:

> 
> igor, my point is that if you recommend
> 
> "  A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
> 
> and
> 
> "  ... an unnumbered link is identified by the
> combination of TE Router
>   ID and a node-unique Interface ID."
> 
> then it is clear that the following occurs
> 
> " The reason why the TE Router ID must be a
> reachable IP address is
>   because in GMPLS, control and data plane
> names/addresses are not
>   completely separated. "
> 
> and the only change that needs to be done in this
> document in section 4.3
> 
> "It is RECOMMENDED that a stable
>    control plane IP address of the next/previous hop
> node be used as an
>    IP destination address in RSVP-TE message.
> 
>    A Path message is sent to the next hop node. It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message."
> 
> is to remove the second paragraph, as there is
> nothing that mandates that
> communication between adjacent controllers should
> achieved through TE
> router ID (note: reading the document you will see
> that the section 5.2.1
> is indeed
> not completed just for this reason)
> 
> in fact, this boils down to say that the TE router
> ID is not mandatorily
> used for hop-by-hop exchange of control messages as
> i can build adjacencies
> between neighboring nodes using the base IP routing
> topology, (by the way
> from where all restrictions that are pointed here
> below come from ?)
> 
> thanks,
> - dimitri.
> ---
> 
> Dimitri,
> 
> Suppose a controller has just received an RSVP Path
> message that contains an ERO describing a path
> computed on the head-end (properly modified, of
> course, along the path). ERO is specified in terms
> of
> numbered or/and unnumbered TE links (and not IP
> addresses). Now the processing controller needs to
> forward the message to the controller that manages
> first non-local ERO sub-object. The question is what
> to set as destination in the IP header of the RSVP
> Path message? You are saying that it should a stable
> IP address of the controller managing the next hop.
> Where the processing controller is supposed to get
> this stable IP address from? All that it has is a
> numbered or unnumbered next hop TE link ID. It is
> not
> guaranteed that numbered TE link ID is a routable
> address, however, it could be easily resolved to TE
> Router ID. In case of unnumbered TE link the TE
> Router
> ID is a part of the link ID. It is also guaranteed
> that TE Router ID is a stable routable IP address of
> the controller advertising the TE link. Hence, the
> recommendation makes a lot of sense to me ? extract
> TE
> Router ID from unnumbered link ID ERO subobject or
> resolve numbered TE link ID into TE Router ID, set
> it
> as destination in IP header of the RSVP Path message
> and forward the packet ?the message will arrive at
> the
> controller managing next hop no matter how many
> actual
> IP hops the packet will make. In fact, that's how
> the
> control plane and data plane separation needs to be
> supported.
> 
> Cheers,
> Igor
> 
> --- [e-mail] wrote:
> >
> > this document is not ready as it prevents usage of
> > the control channel
> > separation as defined in Section 8 of RFC 3473
> (but
> > also representation of
> > complex nodes)
> >
> > i point out here the sentences from where this can
> > be deduced:
> >
> > "  A Path message is sent to the next hop node. 
> It
> > is RECOMMENDED that
> >    the TE router ID of the next hop node be used
> as
> > an IP destination
> >    address in the packet that carries the RSVP-TE
> > message. "
> >
> > combined with the following statements
> >
> > "  ... an unnumbered link is identified by the
> >    combination of TE Router ID and a node-unique
> > Interface ID."
> >
> > "  It is RECOMMENDED that the IP tunnel endpoint
> > address in the Session
> >    Object [RFC3209] be set to the TE Router ID of
> > the egress since the
> >    TE Router ID is a unique routable ID per node."
> >
> > [...]
> >
> > "  It is RECOMMENDED that the IP tunnel sender
> > address in the Sender
> >    Template Object [RFC3209] specifies the TE
> Router
> > ID of the ingress
> >    since the TE Router ID is a unique routable ID
> > per node."
> >
> > therefore, usage of the TE Router ID should be
> > reviewed, such that it does
> > not recommends the source and destination of IP
> > packets to be the TE Router
> > ID but simply a stable reachable control plane IP
> > address of the
> > next/previous hop
> >
> > also, there is a sentence in this document
> >
> > "  The reason why the TE Router ID must be a
> > reachable IP address is
> >    because in GMPLS, control and data plane names
> > /addresses are not
> >    completely separated. "
> >
> > my response to this is of course if you use it
> like
> > proposed in this
> > document this problem occurs
> >
> > ps:
> >
> > section 5.1.2 of this document is unclear wrt
> > section 1.1 of
> >
>
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>
> >
> >
> >
> >
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000
> guides!
> http://travel.yahoo.com/p-travelguide
> 
> 
> 
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



Envelope-to: [e-mail]
Delivery-date: Sun, 17 Apr 2005 08:18:47 +0000
To: Igor Bryskin <[e-mail]>
Cc: [e-mail], Kireeti Kompella <[e-mail]>, [e-mail]
From: [e-mail]
Subject: Re: Addressing doc
MIME-Version: 1.0
Date: Sun, 17 Apr 2005 10:15:19 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

igor, my point is that if you recommend

"  A Path message is sent to the next hop node. It is RECOMMENDED that
   the TE router ID of the next hop node be used as an IP destination
   address in the packet that carries the RSVP-TE message. "

and

"  ... an unnumbered link is identified by the combination of TE Router
  ID and a node-unique Interface ID."

then it is clear that the following occurs

" The reason why the TE Router ID must be a reachable IP address is
  because in GMPLS, control and data plane names/addresses are not
  completely separated. "

and the only change that needs to be done in this document in section 4.3

"It is RECOMMENDED that a stable
   control plane IP address of the next/previous hop node be used as an
   IP destination address in RSVP-TE message.

   A Path message is sent to the next hop node. It is RECOMMENDED that
   the TE router ID of the next hop node be used as an IP destination
   address in the packet that carries the RSVP-TE message."

is to remove the second paragraph, as there is nothing that mandates that
communication between adjacent controllers should achieved through TE
router ID (note: reading the document you will see that the section 5.2.1
is indeed
not completed just for this reason)

in fact, this boils down to say that the TE router ID is not mandatorily
used for hop-by-hop exchange of control messages as i can build adjacencies
between neighboring nodes using the base IP routing topology, (by the way
from where all restrictions that are pointed here below come from ?)

thanks,
- dimitri.
---

Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message? You are saying that it should a stable
IP address of the controller managing the next hop.
Where the processing controller is supposed to get
this stable IP address from? All that it has is a
numbered or unnumbered next hop TE link ID. It is not
guaranteed that numbered TE link ID is a routable
address, however, it could be easily resolved to TE
Router ID. In case of unnumbered TE link the TE Router
ID is a part of the link ID. It is also guaranteed
that TE Router ID is a stable routable IP address of
the controller advertising the TE link. Hence, the
recommendation makes a lot of sense to me ? extract TE
Router ID from unnumbered link ID ERO subobject or
resolve numbered TE link ID into TE Router ID, set it
as destination in IP header of the RSVP Path message
and forward the packet ?the message will arrive at the
controller managing next hop no matter how many actual
IP hops the packet will make. In fact, that's how the
control plane and data plane separation needs to be
supported.

Cheers,
Igor

--- [e-mail] wrote:
>
> this document is not ready as it prevents usage of
> the control channel
> separation as defined in Section 8 of RFC 3473 (but
> also representation of
> complex nodes)
>
> i point out here the sentences from where this can
> be deduced:
>
> "  A Path message is sent to the next hop node.  It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
>
> combined with the following statements
>
> "  ... an unnumbered link is identified by the
>    combination of TE Router ID and a node-unique
> Interface ID."
>
> "  It is RECOMMENDED that the IP tunnel endpoint
> address in the Session
>    Object [RFC3209] be set to the TE Router ID of
> the egress since the
>    TE Router ID is a unique routable ID per node."
>
> [...]
>
> "  It is RECOMMENDED that the IP tunnel sender
> address in the Sender
>    Template Object [RFC3209] specifies the TE Router
> ID of the ingress
>    since the TE Router ID is a unique routable ID
> per node."
>
> therefore, usage of the TE Router ID should be
> reviewed, such that it does
> not recommends the source and destination of IP
> packets to be the TE Router
> ID but simply a stable reachable control plane IP
> address of the
> next/previous hop
>
> also, there is a sentence in this document
>
> "  The reason why the TE Router ID must be a
> reachable IP address is
>    because in GMPLS, control and data plane names
> /addresses are not
>    completely separated. "
>
> my response to this is of course if you use it like
> proposed in this
> document this problem occurs
>
> ps:
>
> section 5.1.2 of this document is unclear wrt
> section 1.1 of
>
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>
>
>
>
>




__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide






Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 21:53:04 +0000
From: "Richard Rabbat" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Sat, 16 Apr 2005 14:50:16 -0700
Message-ID: <00c601c542ce$4706eea0$473ba485@PHOENIX>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Yes, but I'm an author

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Friday, April 15, 2005 3:22 PM
> To: [e-mail]
> Subject: Addressing doc
> 
> 
> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 
> 




Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 21:32:52 +0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Sj0WMQuZ5vmnWObJD7UhAAxWO06/AUYw6DyQnvKarhb4ugeFss78g/0kHFUCd/oesY/a6dcoXjUB4F2CN6rPgazJiSMbqqHf8s0obm2Jm3M1AUATt4xDFB754w/H9hyVoJhL3Axx7S7HyoP8jbyOpCb3BM0KhBMR02GgsXzAVtM=  ;
Message-ID: <[e-mail]>
Date: Sat, 16 Apr 2005 14:31:26 -0700 (PDT)
From: Igor Bryskin <[e-mail]>
Subject: Re: Addressing doc
To: [e-mail], Kireeti Kompella <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Dimitri,

Suppose a controller has just received an RSVP Path
message that contains an ERO describing a path
computed on the head-end (properly modified, of
course, along the path). ERO is specified in terms of
numbered or/and unnumbered TE links (and not IP
addresses). Now the processing controller needs to
forward the message to the controller that manages
first non-local ERO sub-object. The question is what
to set as destination in the IP header of the RSVP
Path message? You are saying that it should a stable
IP address of the controller managing the next hop.
Where the processing controller is supposed to get
this stable IP address from? All that it has is a
numbered or unnumbered next hop TE link ID. It is not
guaranteed that numbered TE link ID is a routable
address, however, it could be easily resolved to TE
Router ID. In case of unnumbered TE link the TE Router
ID is a part of the link ID. It is also guaranteed
that TE Router ID is a stable routable IP address of
the controller advertising the TE link. Hence, the
recommendation makes a lot of sense to me – extract TE
Router ID from unnumbered link ID ERO subobject or
resolve numbered TE link ID into TE Router ID, set it
as destination in IP header of the RSVP Path message
and forward the packet –the message will arrive at the
controller managing next hop no matter how many actual
IP hops the packet will make. In fact, that’s how the
control plane and data plane separation needs to be
supported.

Cheers,
Igor

--- [e-mail] wrote:
> 
> this document is not ready as it prevents usage of
> the control channel
> separation as defined in Section 8 of RFC 3473 (but
> also representation of
> complex nodes)
> 
> i point out here the sentences from where this can
> be deduced:
> 
> "  A Path message is sent to the next hop node.  It
> is RECOMMENDED that
>    the TE router ID of the next hop node be used as
> an IP destination
>    address in the packet that carries the RSVP-TE
> message. "
> 
> combined with the following statements
> 
> "  ... an unnumbered link is identified by the
>    combination of TE Router ID and a node-unique
> Interface ID."
> 
> "  It is RECOMMENDED that the IP tunnel endpoint
> address in the Session
>    Object [RFC3209] be set to the TE Router ID of
> the egress since the
>    TE Router ID is a unique routable ID per node."
> 
> [...]
> 
> "  It is RECOMMENDED that the IP tunnel sender
> address in the Sender
>    Template Object [RFC3209] specifies the TE Router
> ID of the ingress
>    since the TE Router ID is a unique routable ID
> per node."
> 
> therefore, usage of the TE Router ID should be
> reviewed, such that it does
> not recommends the source and destination of IP
> packets to be the TE Router
> ID but simply a stable reachable control plane IP
> address of the
> next/previous hop
> 
> also, there is a sentence in this document
> 
> "  The reason why the TE Router ID must be a
> reachable IP address is
>    because in GMPLS, control and data plane names
> /addresses are not
>    completely separated. "
> 
> my response to this is of course if you use it like
> proposed in this
> document this problem occurs
> 
> ps:
> 
> section 5.1.2 of this document is unclear wrt
> section 1.1 of
>
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>
> 
> 
> 
>



		
__________________________________ 
Do you Yahoo!? 
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide



Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 20:08:36 +0000
To: Kireeti Kompella <[e-mail]>
Cc: [e-mail]
From: [e-mail]
Subject: Re: Addressing doc
MIME-Version: 1.0
Date: Sat, 16 Apr 2005 22:06:42 +0200
Message-ID: <[e-mail]>
Content-type: text/plain; charset=us-ascii

this document is not ready as it prevents usage of the control channel
separation as defined in Section 8 of RFC 3473 (but also representation of
complex nodes)

i point out here the sentences from where this can be deduced:

"  A Path message is sent to the next hop node.  It is RECOMMENDED that
   the TE router ID of the next hop node be used as an IP destination
   address in the packet that carries the RSVP-TE message. "

combined with the following statements

"  ... an unnumbered link is identified by the
   combination of TE Router ID and a node-unique Interface ID."

"  It is RECOMMENDED that the IP tunnel endpoint address in the Session
   Object [RFC3209] be set to the TE Router ID of the egress since the
   TE Router ID is a unique routable ID per node."

[...]

"  It is RECOMMENDED that the IP tunnel sender address in the Sender
   Template Object [RFC3209] specifies the TE Router ID of the ingress
   since the TE Router ID is a unique routable ID per node."

therefore, usage of the TE Router ID should be reviewed, such that it does
not recommends the source and destination of IP packets to be the TE Router
ID but simply a stable reachable control plane IP address of the
next/previous hop

also, there is a sentence in this document

"  The reason why the TE Router ID must be a reachable IP address is
   because in GMPLS, control and data plane names /addresses are not
   completely separated. "

my response to this is of course if you use it like proposed in this
document this problem occurs

ps:

section 5.1.2 of this document is unclear wrt section 1.1 of
<http://www.ietf.org/internet-drafts/draft-ietf-isis-gmpls-extensions-19.txt>





Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 12:11:20 +0000
Message-ID: <[e-mail]>
Date: Sat, 16 Apr 2005 08:08:22 -0400 (EDT)
Subject: Re: Addressing doc
From: [e-mail]
To: "Kireeti Kompella" <[e-mail]>
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> A new version of this draft has been posted as
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
>
> Please reply to this email on whether or not you think this should be
> a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
> received until Fri April 22, 23:59 UTC.
>
> Thanks,
> Kireeti.
> -------
>
>
Yes,
Igor Bryskin



Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 10:20:11 +0000
Message-ID: <049c01c5426d$cb102ab0$cdcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft
Date: Sat, 16 Apr 2005 11:19:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

OK.

No objections received.
Authors, please submit as a WG draft with no changes.

We will liaise this document to the ITU-T and hope to finish with it
pretty soon.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 31, 2005 6:06 PM
Subject: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as
a WG draft


> Hi,
>
> This draft is the product of a DT set up by the WG so it is appropriate
> that the draft become a WG draft.
>
> Please speak up now if you feel strongly against this.
>
> Thanks,
> Adrian
>
> ----- Original Message ----- 
> From: <[e-mail]>
> To: <[e-mail]>
> Sent: Wednesday, March 23, 2005 10:10 PM
> Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt
>
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> >
> > Title : Evaluation of existing Routing Protocols against
> >   ASON routing requirements
> > Author(s) : J. Drake, et al.
> > Filename : draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt
> > Pages : 0
> > Date : 2005-3-23
> >
> > The Generalized MPLS (GMPLS) suite of protocols has been defined to
> >    control different switching technologies as well as different
> >    applications. These include support for requesting TDM connections
> >    including SONET/SDH and Optical Transport Networks (OTNs).
> >
> > A URL for this Internet-Draft is:
> >
>
http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > [e-mail] with the word unsubscribe in the body of
> the message.
> > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > [e-mail].
> > In the body type:
> > "FILE
> /internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility.  To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader.  Different MIME-compliant mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>
>
> ------------------------------------------------------------------------
--
> ------
>
>
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Sat, 16 Apr 2005 02:32:08 +0000
Message-Id: <[e-mail]>
From: "Zafar Ali" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>
Subject: RE: Addressing doc
Date: Fri, 15 Apr 2005 22:30:31 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcVCCgwZKHX05+v7SCSdOzTM5k6MJQAIiaig

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Kireeti Kompella
> Sent: Friday, April 15, 2005 6:22 PM
> To: [e-mail]
> Subject: Addressing doc
> 
> A new version of this draft has been posted as 
> draft-shiomoto-ccamp-gmpls-addressing-01.txt .
> 
> Please reply to this email on whether or not you think this 
> should be a CCAMP WG doc.  

Yes, 

Thanks

Regards... Zafar

>Adrian and I will gauge consensus 
> based on the mail received until Fri April 22, 23:59 UTC.
> 
> Thanks,
> Kireeti.
> -------
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 15 Apr 2005 22:26:08 +0000
Date: Fri, 15 Apr 2005 15:25:55 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: GMPLS MIBs
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This is to announce a two-week WG Last Call on the GMPLS MIB doc set.

Please send in your comments by Fri April 29, 23:59 UTC.

[Tom P, thanks for the comments you already sent.  You need not send
them again; they will be handled with the rest of the LC comments.
If you have more comments, of course please do send them in.]

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 15 Apr 2005 22:24:06 +0000
Date: Fri, 15 Apr 2005 15:22:04 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Addressing doc
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

A new version of this draft has been posted as
draft-shiomoto-ccamp-gmpls-addressing-01.txt .

Please reply to this email on whether or not you think this should be
a CCAMP WG doc.  Adrian and I will gauge consensus based on the mail
received until Fri April 22, 23:59 UTC.

Thanks,
Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 15 Apr 2005 19:35:34 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
Date: Fri, 15 Apr 2005 15:33:38 -0400

--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		: A Per-domain path computation method for 
			  computing Inter-domain Traffic Engineering (TE) 
			  Label Switched Path (LSP)
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt
	Pages		: 0
	Date		: 2005-4-15
	
This document specifies a per-domain path computation method for 
computing inter-domain Traffic Engineering (TE) Multiprotocol Label 
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) 
paths. In this document a domain is referred to as a collection of 
network elements within a common sphere of address management or path 
computational responsibility such as IGP areas and Autonomous Systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Fri, 15 Apr 2005 11:57:00 +0000
Message-ID: <034201c541b2$2cd025f0$cdcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Last call complete on Exclude Route and Crankback
Date: Fri, 15 Apr 2005 12:28:25 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Thanks all for your comments on and off the list.

The editors and authors will update the drafts and answer any specific
technical questions.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Thu, 14 Apr 2005 04:56:52 +0000
Message-ID: <[e-mail]>
Date: Thu, 14 Apr 2005 00:55:26 -0400
From: Cheng-Yin Lee <[e-mail]>
MIME-Version: 1.0
To: Arthi Ayyangar <[e-mail]>
CC: Adrian Farrel <[e-mail]>, kireeti Kompella <[e-mail]>, [e-mail], "[e-mail]" <[e-mail]>
Subject: Re: WG  last calls - exclude route ID
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Arthi,
Thanks for your comments.

Arthi Ayyangar wrote:

> Hi,
>
> Here are a few comments on this ID. Sorry for the delay.
> Also, in case some of these comments are a repetition, please ignore
> those.
>
> thanks,
> -arthi
> ----------------
> 1)
> Section 2.
>
> To convey these constructs within the signaling protocol, a new
> RSVP object and a new ERO subobject are introcuded respectively.
>                                        ^^^^^^^^^^^
> - Typo
>
> 2)
> Section 4.2
> The number of introduced exlicit nodes or abstract nodes with
>                         ^^^^^^^^^^
> the L flag set to "avoid" should be minimised.
>
> - Typo

Ok, we should run spell check.

>
> 3)
> 5.2
> Each EXRS may carry multiple exclusions.  The exclusion is encoded
> ---------------------------------------
> exactly as for XRO subobjects and prefixed by an additional Type and
> Length.
>
> <AA> Did you mean, there can be multiple EXRS per ERO, which I see or
>      multiple exclusions per EXRS ?
>      From the format of the EXRS it looks like one exclusion per EXRS.
>      Did I miss something ?

there can be multiple EXRS per ERO
multiple subobjects can  be specified in an EXRS

>
>
> 4)
> Thus, an EXRO subobject for an IP hop might look as follows:
>      ^^^^^^^^^^^^^^^^^
> <AA> EXRS ?

Yes.

> Also the S in EXRS already means sub-object, so you could get
> rid of sub-object following EXRS.

ok.

> 5)
> The subobjects in the ERO and EXRS SHOULD not contradict each other.
> If they do contradict, the subobjects with the L bit not set, strict
> or MUST be excluded, respectively, in the ERO or XRO MUST take pre-
> cedence.  If there is still a conflict, the subobjects in the ERO
> MUST take precedence.
>
> <AA> You may want to state explicitly what you mean by contradict for
> EXRS. Is the scope of contradiction just the previous and next ERO
> sub-objects ?

Yes. This may not be a contradiction. We will think of some text to clarify
this.

>
> 6)
> If the presence of EXRO Subobjects precludes further forwarding of
>                     ^^^^^^^^^^^^^^^^^
> the Path message, the node should return a PathErr with the error
> code "Routing Problem" and error value of "Route blocked by Exclude
> Route"
>
> 7)
> <AA> With respect to EXRS, it might be useful to clarify what does EXRS
> provide that cannot be achieved by XRO. Basically give some hints as to
> where EXRS may be useful versus XRO.

EXRS - If we need to exclude a resource between A and B only (could be a
policy thing), but may want to use the resource elsewhere  in the path.

> Also, can there be conflicts between
> EXRS and XRO ? If yes, then how is that dealt with ?

I can't think of conflicts between EXRS and XRO, if X is excluded by EXRS and
XRO, then it is just redundant to specify X in EXRS.

>
> 8) Section 6
>
> The IPv6 Prefix subobject MUST be supported with a prefix
>           length of 128, and an attriubute value of "interface" and
>                               ^^^^^^^^^^^^
>           "node".
> - Typo
>
> -----------------

Thanks
Cheng-Yin




Envelope-to: [e-mail]
Delivery-date: Thu, 14 Apr 2005 02:44:04 +0000
Date: Wed, 13 Apr 2005 19:42:35 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Adrian Farrel <[e-mail]>, kireeti Kompella <[e-mail]>
cc: [e-mail], [e-mail], "[e-mail]" <[e-mail]>
Subject: WG  last calls - exclude route ID
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

Here are a few comments on this ID. Sorry for the delay.
Also, in case some of these comments are a repetition, please ignore
those.

thanks,
-arthi
----------------
1)
Section 2.

To convey these constructs within the signaling protocol, a new
RSVP object and a new ERO subobject are introcuded respectively.
                                       ^^^^^^^^^^^
- Typo

2)
Section 4.2
The number of introduced exlicit nodes or abstract nodes with
                        ^^^^^^^^^^
the L flag set to "avoid" should be minimised.

- Typo

3)
5.2
Each EXRS may carry multiple exclusions.  The exclusion is encoded
---------------------------------------
exactly as for XRO subobjects and prefixed by an additional Type and
Length.

<AA> Did you mean, there can be multiple EXRS per ERO, which I see or
     multiple exclusions per EXRS ?
     From the format of the EXRS it looks like one exclusion per EXRS.
     Did I miss something ?

4)
Thus, an EXRO subobject for an IP hop might look as follows:
     ^^^^^^^^^^^^^^^^^
<AA> EXRS ? Also the S in EXRS already means sub-object, so you could get
rid of sub-object following EXRS.

5)
The subobjects in the ERO and EXRS SHOULD not contradict each other.
If they do contradict, the subobjects with the L bit not set, strict
or MUST be excluded, respectively, in the ERO or XRO MUST take pre-
cedence.  If there is still a conflict, the subobjects in the ERO
MUST take precedence.

<AA> You may want to state explicitly what you mean by contradict for
EXRS. Is the scope of contradiction just the previous and next ERO
sub-objects ?

6)
If the presence of EXRO Subobjects precludes further forwarding of
                    ^^^^^^^^^^^^^^^^^
the Path message, the node should return a PathErr with the error
code "Routing Problem" and error value of "Route blocked by Exclude
Route"

7)
<AA> With respect to EXRS, it might be useful to clarify what does EXRS
provide that cannot be achieved by XRO. Basically give some hints as to
where EXRS may be useful versus XRO. Also, can there be conflicts between
EXRS and XRO ? If yes, then how is that dealt with ?

8) Section 6

The IPv6 Prefix subobject MUST be supported with a prefix
          length of 128, and an attriubute value of "interface" and
                              ^^^^^^^^^^^^
          "node".
- Typo

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



Envelope-to: [e-mail]
Delivery-date: Thu, 14 Apr 2005 00:43:11 +0000
Date: Wed, 13 Apr 2005 17:40:44 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: [e-mail], Kireeti Kompella <[e-mail]>
cc: [e-mail]
Subject: WG last calls - cranback ID
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Adrian,

Here are some comments (marked <AA>) on the crankback ID.

thanks,
-arthi

---------
1.1 typo : documentaiton

2.2
Crankback routing schemes could be used to notify the upstream LSRs
of the location of the failure.

<AA> Do you mean "Cranback signaling schemes could be used to notify" ?
                           ----------
     I observed that in some places crankback signaling and cranback routing
     are used interchangeably. Need to clarify ?

4.2.2
   If the crankback information can be used to compute a new route
   avoiding the blocking problem, the route can be signaled as an
   Explicit Route.

<AA> How about "If the crankback information can be used to compute a new
   path avoiding the blocking problem, the path can be signaled with a new
   Explicit Route."


7.2
<AA> What is the PROPOSED_ERO for ? Why can't the node doing crankback
re-routing simply figure out the new path based on constraints and
failures history in the downsstream network that he probably understands
best ? Why do we want the node reporting error to suggest an ERO ?
Same question about 26 and 27 as well. It would be intuitive if the node
reporting failures simply reports the failure and leaves the guesswork and
computation to the node taking the re-routing action. That way the
reponsibility of each node is well-defined. Also, it is the node doing
the re-route that has the bigger picture in the end.


7.3.1
<AA> I am not too sure of the following statement:-

  "If crankback is being used, the sender of a PathErr, ResvErr or
   Notify message MUST use the IF_ID ERROR_SPEC object and MUST include
   at least one of the TLVs in the range 1 through 3 as described in
   [RFC3473], [BUNDLE], and previous paragraph."

The assumption here is that IF_ID ERROR_SPEC is always being used.
In section 5.1 we acknowledge that with RSVP-TE crankback re-routing can
be performed explicitly avoiding the node or interface reported in
ERROR_SPEC; i.e. no TLVs. So, the above sentence is only true in the
context of GMPLS RSVP-TE. You may want to clarify this once somewhere.


7.3.3

   An LSR that proposes to perform crankback re-routing SHOULD
   support receipt and processing of all of the fundamental crankback
   TLVs, and is RECOMMENDED to support the receipt and processing of
   the additional crankback TLVs.

<AA> Why is the requirement for 'crankback re-routing' different from
     that for 'crankback' in section 7.2 ? Why isn't it enough for
     the LSR to support just the Error Report TLVs (1-3) in order to
     perform cranback re-routing ?

<AA> What information does DOWNSTREAM_LABEL and UPSTREAM LABEL provide to
     some node several hops upstream ? How is the node doing cranback
     re-routing going to use this info and enforce it along the new path?

7.4.4 When Re-routing Fails

   However, when a node was responsible for expanding or replacing the
   explicit route as the LSP setup was processed it MUST update the
   crankback information with regard to the explicit route that it
   received. Only if this is done will the upstream nodes stand a
   chance of successfully routing around the problem.

<AA> When you say "update", is the LSR replacing old crankback info with
new crankback info that it generates or is it appending this to received
crankback info in PathErr ? Also, is this a new PathErr (with a new src
addr) or the same PathErr that was received ? The reason I bring this up is
because elsewhere in the doc, you talk about intercepting and terminating
the error. I think you should clarify this in this section.

7.5. Notification of Errors

<AA> Is this section missing PathErr because it has been discussed in the
rest of the document ?

--------



> This is to initiate CCAMP WG last calls on:
>
> draft-ietf-ccamp-crankback-04.txt
>
> and
>
> draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
>
> Please send your comments to the list (preferably) or to the authors
> by April 14, 23:59 GMT (which is when the last calls end).
>
> Thanks,
> Kireeti.
> -------
>



Envelope-to: [e-mail]
Delivery-date: Wed, 13 Apr 2005 15:18:58 +0000
Message-ID: <[e-mail]>
Date: Wed, 13 Apr 2005 11:16:25 -0400
From: [e-mail]
To: [e-mail]
Subject: MPLS 2005 Call for Presentations (Oct 16-19, Wash. DC)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0)

=====================================
  MPLS 2005 International Conference
  http://www.mpls2005.com
  October 16-19, 2005
  Washington, DC
======================================

The Program Committee of MPLS2005 (<http://www.mpls2005.com>) is soliciting
presentation proposals for this conference. If you wish to suggest a 
particular
topic or a contribution, please send a one page long proposal (including
speaker's contact details) to the attention of the Technical Program Committee
at [e-mail] by June 10, 2005.

This year's conference will include, but not be limited to, topics such as:

  - MPLS in multi-area and multi-AS networks
  - Point-to-multipoint MPLS and applications
  - Supporting multicast in MPLS VPNs and for VPLS
  - Single and Multi-hop Pseudowire placement, setup and management
  - Providing QoS in MPLS networks
  - MPLS network management
  - OAM for MPLS networks
  - MPLS in the Next Generation Network
  - Voice over IP/MPLS
  - Triple-play applications on MPLS
  - MPLS-enabled Advanced services and converged networks
  - Interworking and migration for MPLS and GMPLS
  - Multi-layer networks and integration with non-packet technologies
  - Deploying, interworking and operating L2 and L3 MPLS VPNs
  - MPLS deployment experience: scaling, performance and security
  - Testing the technology: MPLS test tools and experience
  - Protection, restoration and reliability
  - Network processors for MPLS and GMPLS
  - MPLS/GMPLS control plane resilience, scaling and robustness
  - MPLS TE applications of the Path Computation Element (PCE)
  - Motivations and requirements for extending MPLS into the access network

The program committee is looking for original and unpublished work to continue
the tradition initiated by this conference in 1998 of covering cutting-edge
topics. Presentations from the vendor, service provider, research and user
community are solicited on new technologies and operational experience.

REGISTRATION is also now open, with extremely lucrative early-bird discounts -
visit <http://www.mpls2005.com/registration.htm> for details.

Thank you for your continued support.

Regards,
Kavita




Envelope-to: [e-mail]
Delivery-date: Tue, 12 Apr 2005 21:54:00 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  ccamp mailing list <[e-mail]>, ccamp chair <[e-mail]>, ccamp chair <[e-mail]>
Subject: Protocol Action: 'Generalized Multi-Protocol Label Switching  (GMPLS) Recovery Functional Specification' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Tue, 12 Apr 2005 17:51:27 -0400

The IESG has approved the following documents:

- 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional 
   Specification '
   <draft-ietf-ccamp-gmpls-recovery-functional-04.txt> as a Proposed Standard
- 'Recovery (Protection and Restoration) Terminology for Generalized 
   Multi-Protocol Label Switching (GMPLS) '
   <draft-ietf-ccamp-gmpls-recovery-terminology-06.txt> as an Informational RFC
- 'Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based 
   Recovery Mechanisms (including Protection and Restoration) '
   <draft-ietf-ccamp-gmpls-recovery-analysis-05.txt> as an Informational RFC

These documents are products of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Alex Zinin and Bill Fenner.

Technical Summary
 
   This set of documents presents a functional description of the protocol 
   extensions needed to support Generalized Multi-Protocol Label 
   Switching (GMPLS)-based recovery (i.e. protection and restoration). 
   Protocol specific formats and mechanisms will be described in 
   subsequent documents. 
 
Working Group Summary
 
   The WG had a consensus on advancing these documents and addressed
   AD-review comments. 
 
Protocol Quality
 
   These documents have been reviewed for the IESG by Alex Zinin.




Envelope-to: [e-mail]
Delivery-date: Tue, 12 Apr 2005 07:38:23 +0000
Date: Tue, 12 Apr 2005 15:36:16 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: About LSP Stitching
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Arthi,
   Thanks for replying.

   Below are the two main assumptions on which my query is based.
   Plz correct me if I am wrong.
   1. E2e LSP & LSP segment are two independant LSP's.
   2. TE-Link is a kind of abstraction.
      User of TE-Link should not know about the implementation details of the TE-Link.
     

   Whether it is a FA or a LSP segment as a TE-Link, an LSP setting up over these TE-Link should not be aware of the TE-Link setup details(whether its a FA or a LSP segment or a Physical Interface or others).

   So if we go by this, the below example which i gave holds true.
 
   Plz let me know your view on this.
Thanks and regards,
Amit.


----- Original Message -----
From: Arthi Ayyangar <[e-mail]>
Date: Saturday, April 9, 2005 4:22 am
Subject: Re: About LSP Stiching

> Amit,
> 
> >  There is no way for LSP segment head node, to identify that a
> > Outif selected is a LSP Segment for setting up E2e LSP.
> ---> What do you mean ? Why would the head-end of an LSP segment 
> not know
> that selected nexthop is the LSP segment ? It is the head-end of 
> the LSP
> segment selecting what you call Outif.
> 
> 
> >  That is Some extension will be needed to RSVP that will allow RSVP
> > message(for E2e LSP) processing at LSP segment head node to be 
> processed> according to the Sticthing needs.
> ------> I don't think there is any need for any more 
> extensions..see my
> explanation above and below.
> 
> 
> >  For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B.
> >
> >  1-----A--D---E--B-----2
> >
> >  Now if A gets the Path message for LSP1-2, and A selects LSP
>        segment LSPA-B as outif.
> >  Then how does RSVP(at Node A) identify that the outif selected is
>        a LSP segment?
> -------> A is doing nexthop (what you call outif) selection, A is the
> head-end of LSP segment. A knows that nexthop is an LSP segment.
> 
> 
> >  Also when A receives Resv for LSP1-2(from B), how can it ignore
> >     Label in it.
> >  There should be a way to determine at node A, that a LSP segment
> > is in use.
> -----> A chose to stitch the e2e LSP to the LSP segment in the 
> first place.
> 
> thanks,
> -arthi
> 
> 
> 
> >  One possible way could be that Resv message for LSP1-2 should be
> > sent(by B) with some special Label value.
> >  This Label value should indicate the node A that the Resv is
> > received for a TE-Link(of type LSP Segment).
> >  This will help node A to ignore Label value in Resv msg for E2e
> > Lsp LSP1-2.
> 
> 






Envelope-to: [e-mail]
Delivery-date: Mon, 11 Apr 2005 17:51:39 +0000
Message-ID: <[e-mail]>
Date: Mon, 11 Apr 2005 13:48:50 -0400
From: Cheng-Yin Lee <[e-mail]>
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], kireeti Kompella <[e-mail]>, Adrian Farrel <[e-mail]>
Subject: Re: WG  last calls - comments  ondraft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Stefaan, Dimitri,

[e-mail] wrote:

> Hi Dimitri,
>
> see below for responses...
>
> >>
> >>> 3. section 4.1
> >>>
> >>> "The subobjects are identical to
> >>>    those defined in [RFC3209] and [RFC3473] for use in EROs."
> >>>
> >>> looking at the definitions this is not the case (moreover the SRLG
> >>> subobject has been added) -
> >>
> >>
> >> Are you only referring to the SRLG subobject? If yes, then it is best
> >> to change it into "...those defined in [RFC3209] and [RFC3473] for use
> >> in EROs and section 3.1 of this document."
> >
> >
> > -> yes, but also ERO subobjects do not include an attribute field, XRO
> > subobjects do
> >
>
> Correct.  We use ERO subobjects with these modifications. There has been
> discussion in the past whether we reuse ERO subobjects and modify to
> make them useful for XRO, or whether we define for the XRO new
> subobjects. So far, the decision was to do the former but this is of
> course open for discussion. The consequence is that when we want to
> exclude something in the XRO, we also need the corresponding to include
> it in the ERO. For SRLGs this means that we need an SRLG ERO subobject
> which is not defined previously. It does not make much sense to have an
> SRLG ERO subobject (that is why you would not find a document describing
> the processing rules of such an object in the ERO), but it is needed for
>   the corresponding subobject in the XRO.

Perhaps it is sufficient to say something along the line :
"This specification adapts ERO subobjects for use in route exclusions.
The SRLG ERO subobject and its processing within an ERO have not been defined
before. The SRLG ERO subobject is defined here for use with route exclusion."

SRLG ERO processing for route inclusion, if required, is out of scope but I
think it is better that the Exclude Route spec does not rule out/talk about the
use of SRLG ERO in route inclusion for whatever reasons ...

Thanks
Cheng-Yin

>
>
> >>> 4. section 4.1
> >>>
> >>> "  An Attribute octet is introduced in the subobjects that define IP
> >>>    addresses to indicate the attribute (e.g.  interface, node, SRLG)
> >>>    associated with the IP addresses that can be excluded from the path."
> >>>
> >>> what is a subobject that define IP addresses ?
> >>
> >>
> >> see following subsections. Is it enough that I change "IP address"
> >> into "IP prefix" to make it more clear?
> >
> >
> > wouldn't be better to refer to the subobject types instead, something
> > like (concerning the
> >
> > "An Attribute field is introduced in the subobjects Type 1, 2 and 4 to
> > indicate the attribute (e.g. interface, node, SRLG) that is associated
> > with the IP address included as part of the subobject and that can be
> > excluded from the path."
> >
>
> Sounds better. I will do that. I will also remove the word "IP address"
> because unnumbered (type 4) is not really an IP address.
>
> > also definition of the attribute value should refer better to "IPv4 or
> > IPv6 address treated as an prefix based on the prefix length value"
> >
> > last point but this is editorial, currently you have
> >
> > 4.1.1  Subobject 1: IPv4 prefix
> > 4.1.2  Subobject 2: IPv6 Prefix
> > 4.1.3  Subobject 32: Autonomous System Number
> > 4.1.4  Subobject TBD: SRLG
> > 4.1.5  Subobject 4: Unnumbered Interface ID Subobject
> >
> > wouldn't it be better to list them as
> >
> > 4.1.1  Subobject 1: IPv4 prefix
> > 4.1.2  Subobject 2: IPv6 Prefix
> > 4.1.3  Subobject 4: Unnumbered Interface ID Subobject
> > 4.1.4  Subobject 32: Autonomous System Number
> > 4.1.5  Subobject TBD: SRLG
> >
>
> yes
>
> >>> 5. section 4.1
> >>>
> >>> "   For instance, the attribute node allows a whole node to be excluded
> >>>    from the path, in contrast to the attribute interface, which allows
> >>>    specific interfaces to be excluded from the path. "
> >>>
> >>> but below the definition says "0 indicates that the interface or set
> >>> of interfaces associated with the IP prefix should be excluded or
> >>> avoided" which makes the term specific ambiguous
> >>
> >>
> >> Section 4.1 is an example on how to exclude a node or an interface
> >> from  a path. Section 4.1.1 contains the full specification and the
> >> example looks to be contained in 4.1.1.
> >
> >
> > indeed, this is what i understood, my question is more "how can you be
> > specific if you remove a set of interfaces"
> >
>
> ??? Is it OK if I change it into "For instance, the attribute node
> allows a whole node to be excluded from the path, in contrast to the
> attribute interface, which allows a specific interface or set of
> interfaces to be excluded from the path."
>
> Note that the interfaces in the set of interfaces does not have to be on
> the same node.
>
> >>> 6. section 4.1.5
> >>>
> >>> "         node
> >>>
> >>>              1 indicates that the node with the Router ID should be
> >>>                excluded or avoided (this can be achieved using IPv4/v6
> >>>                subobject as well, but is included here because it may be
> >>>                convenient to use subobjects from RRO, in specifying the
> >>>                exclusions)"
> >>>
> >>> until "(this can be achieved using IPv4/v6 subobject" i understand
> >>> after  i would ask you to clarify i guess you mean RRO from another
> >>> path ? should you include this as part of the definition ?
> >>
> >>
> >> Can you give an example on how the exlude/avoid resources from a path
> >> computation while the path is already computed and signaled (otherwise
> >> you do not have an RRO)?
> >
> >
> > you signal a first LSP, at the ingress you recuperate the (Resv) RRO
> > that you inject (may be after some transformation) as part of the XRO of
> > another LSP (load balancing for inst.)
> >
> > now concerning the initial point (as i do not understand what you mean
> > by "use RRO subobjects for exclusion" to achieve the same functionality
> > as an XRO with the Type 4 subobject) would you please provide 1) the
> > explanation about the context of the usage of the RRO subobjects for
> > exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then
> > 2) why do you think providing two ways to do the same thing as part of
> > the same document is useful ?
> >
>
> to make it more exact, I will change it into "*information* from RRO
> subobjects, in speficying the exclusions." toghether with a reference to
> the RRO-subobjects.
>
> >>
> >>> 9. section 4.2 - condition 4. "The number of introduced SLRGs with
> >>> the L flag set to "avoid" should be minimised." i guess you mean wrt
> >>> to the number of "exclude" SRLGs (blocking) ? or is there an absolute
> >>> limitation due to the message size
> >>
> >>
> >> The sentence you are referring to is not related to the number of
> >> subobejcts in the XRO. It is related to the number of links belonging
> >> to SRLGs that should be avoided.
> >
> >
> > please rephrase it - because it is quite difficult to deduce this
> > meaning (in particular, if a recommendation follows that statement)
> >
> >> For instance, when there is a path that has a link with 1 SRLG to be
> >> avoided, and there is another path with a link of 2 SRLGs to be
> >> avoided, and there are no alternative paths then take the first path
> >> because it minimises the number of SLRGs with the L flag set to avoid.
> >>
> >> To make it clear, I will change the text as follows: "The number of
> >> introduced explicit ndoes or abstract nodes in the computed path with
> >> the L flag set to "avoid" should be minimised.
> >
> >
> > ok - and indicate a sensible reason would help in understanding why -
> > this is not difficult to be spelled out anyway
> >
>
> ok
>
> >>> 10. section 4.2 - concerning the operations i would suggesting adding
> >>> a rule suggesting that no contradicting exclusions get inserted
> >>
> >>
> >> What is a contradicting exclusion? Do you mean if for instance a node
> >> appears twice in the XRO, as avoid and exclude? In that case it is
> >> exclude. I will add a statement. Contradictions with ERO are possible
> >> but that is mentioned.
> >
> >
> > the document says "If an XRO was present, the content of the XRO can be
> > modified." so what i mean is that THIS node does not introduce a
> > exclusion for an subobject it has itself included as part of the ERO (as
> > the document explains how to process such contradicting exclusions but
> > should also have clear rules in terms of generation of XROs)
> >
>
> Ok, I see, it should indeed be mentioned somewhere that nodes MUST NOT
> generate ERO and XRO/EXRS with conflicting information. Nevertheless it
> remains needed to be said what has to be done when conflicting ERO and
> XRO/EXRS are received by a node.
>
> >
> >>> 13. section 5.1
> >>>
> >>> "  Note: The Most Significant Bit in the Type field could be used to
> >>>    indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
> >>>    the need to prepend the subobject with an additional TLV header.
> >>>    This would reduce the number bytes require for each subobject by 2
> >>>    bytes.  However, this approach would reduce the ERO Type field space
> >>>    by half.  This issue need WG discussion and feedback."
> >>>
> >>> -> i would suggest keeping existing definition (since the EXRS is to
> >>> considered as an optimization), this said better formalization of the
> >>> EXRS subobjects needs to be provided - as the next section mentions
> >>> "Each EXRS may carry multiple exclusions.  The exclusion is encoded
> >>> exactly as for XRO subobjects and prefixed by an additional Type and
> >>> Length." while with the provided alignment it looks like each
> >>> exclusion element is encoded with this double Type/Length field
> >>
> >>
> >> Thanks for your feedback on this question. Concerning the alignment:
> >> there can be multiple subobjects in an EXRS, note the plural form of
> >> "EXRS subobjects" in the first figure of section 5.1.
> >
> >
> > also "The format of this field is exactly the format of an XRO subobject
> > and may include an SRLG subobject.  Both subobjects are as described
> > earlier in this document." ... both subobjects refers to ?
> >
> >> Better to make this more explicit in the specification of "EXRS
> >> subobjects": One or more EXRS subobjects. An EXRS subobject
> >> indicates....". For a better alignment it might be better to indeed
> >> add 2 padding bytes after the Type and Length.
> >
> >
> > ok - i do suggest making use of this padding since we speak about a list
> > including sub-lists of subobjects and not lists including (double
> > type/length) subobjects
> >
>
> Ok, I will add 2 padding bytes.
>
> >>
> >>> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this
> >>> should better be defined as an "SRLG Subobject" as i do not see a
> >>> specific reason for having an SRLG subobject outside of the XRO, EXRS
> >>> context ?
> >>
> >>
> >> not really, see 2 previous comments. It is really an ERO subobject but
> >> the usage of this in ERO is not part of this document.
> >
> >
> > would it be possible to know which document makes use of SRLG as part of
> > an ERO ?
> >
>
> see beginning of this email.
>
> >> This comes down to the discussion whether XRO defines new subobjects
> >> specific for XRO or whether XRO simply reuses the ERO subobjects with
> >> some modifications (L-flag and attribute). So far, the latter has been
> >> choosen but that means that it is an SRLG ERO subobject.
> >
> >
> > ok - but then indicate that there is no description available of the
> > usage of an SRLG subobjects as part of an ERO
> >
>
> ok
>
> >>> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the
> >>> IPv4 subobject, etc.
> >>
> >>
> >> yes
> >>
> >>> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,
> >>
> >>
> >> see rfc3477, section 4, from where we got the object. In fact, a
> >> reference to this RFC is missing.
> >
> >
> > this rfc refers to the former but i do suggest using the latter as this
> > has already generated enough issues
> >
>
> Ok, will change it into "TE Router ID"
>
> >>> 7. section 5.1
> >>>
> >>> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
> >>> what do you mean by might ? isn't EXRS instead of EXRO ?
> >>
> >>
> >> "Might" means that there other methods to do the same. For instance,
> >> if the IP hop is IPv6, it looks different. If unnumbered links are
> >> used, it is also different. Indeed, EXRO should be EXRS.
> >
> >
> > indeed but might is not really used in a prescptive document (prefer MAY
> > with alternatives in case)
> >
>
> ok, will use "may"
>
> >>
> >>> 9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2
> >>> Processing Rules for the EXR Subobject and its Subobjects"
> >>
> >>
> >> indeed. should be "5.2 Semantics and Processing Rules for the EXRS and
> >> its Subobjects".
> >
> >
> > suggest to remove the term semantic since it should be clear from its
> > definition in section 5.1
> >
>
> It depends on how the content of this section evolves. It is similar to
> section 4.2, with similar title. Removign Semantic in both sections
> looks good to me.
>
> regards,
>
> Stefaan




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Apr 2005 20:23:24 +0000
Date: Fri, 8 Apr 2005 13:22:18 -0700 (PDT)
From: Arthi Ayyangar <[e-mail]>
To: Amit 70405 <[e-mail]>
cc: [e-mail]
Subject: Re: About LSP Stiching
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Amit,

> 	There is no way for LSP segment head node, to identify that a
> Outif selected is a LSP Segment for setting up E2e LSP.
---> What do you mean ? Why would the head-end of an LSP segment not know
that selected nexthop is the LSP segment ? It is the head-end of the LSP
segment selecting what you call Outif.


> 	That is Some extension will be needed to RSVP that will allow RSVP
> message(for E2e LSP) processing at LSP segment head node to be processed
> according to the Sticthing needs.
------> I don't think there is any need for any more extensions..see my
explanation above and below.


> 	For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B.
>
> 	1-----A--D---E--B-----2
>
> 	Now if A gets the Path message for LSP1-2, and A selects LSP
        segment LSPA-B as outif.
> 	Then how does RSVP(at Node A) identify that the outif selected is
        a LSP segment?
-------> A is doing nexthop (what you call outif) selection, A is the
head-end of LSP segment. A knows that nexthop is an LSP segment.


> 	Also when A receives Resv for LSP1-2(from B), how can it ignore
>     Label in it.
> 	There should be a way to determine at node A, that a LSP segment
> is in use.
-----> A chose to stitch the e2e LSP to the LSP segment in the first place.

thanks,
-arthi



> 	One possible way could be that Resv message for LSP1-2 should be
> sent(by B) with some special Label value.
> 	This Label value should indicate the node A that the Resv is
> received for a TE-Link(of type LSP Segment).
> 	This will help node A to ignore Label value in Resv msg for E2e
> Lsp LSP1-2.



Envelope-to: [e-mail]
Delivery-date: Fri, 08 Apr 2005 17:40:28 +0000
Message-ID: <01cc01c53c61$faba3a10$6fcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison received from ITU-T Q12/15 and Q14/15 on (G)MPLS Change Procedure
Date: Fri, 8 Apr 2005 18:29:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison statement from ITU-T Study Group 15
Questions 12 and 14.

Adrian
===

From: Malcolm Betts, Rapporteur Q12/15
      Kam Lam, Rapporteur Q14/15
Title: Liaison Statement to ccamp and mpls WGs on (G)MPLS Change Process
For: Information

Thank you for your liaison on <draft-andersson-rtg-gmpls-change-01.txt>,
which has started to address the issues raised in our previous liaison.
We appreciate your efforts towards resolving the concerns raised, and look
forward to receiving the next stable version of the draft.

An electronic copy of this liaison can be found at
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html




Envelope-to: [e-mail]
Delivery-date: Fri, 08 Apr 2005 17:40:21 +0000
Message-ID: <01cd01c53c61$fda3ec80$6fcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Liaison received from ITU-T Q12/15 and Q14/15 on RFC 4003
Date: Fri, 8 Apr 2005 18:31:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

We have received the following liaison statement from ITU-T Study Group 15
Questions 12 and 14.

Adrian
===
From: Malcolm Betts, Rapporteur Q12/15
      Kam Lam, Rapporteur Q14/15
Title: Liaison Statement to IETF CCAMP WG on RFC 4003
For: Information

ITU-T SG15 Q14/15 would like to thank you for bringing to our attention
the new RFC 4003 on Egress Control.  We expect to add RFC 4003 as a
reference in future specifications.  We are happy to be able to contribute
to the discussions of the IETF CCAMP WG and help to further the work on
control plane protocols in your group.


An electronic copy of this liaison can be found at
ftp://sg15opticalt:[e-mail]/tsg15opticaltransport/COMMUNICATIONS/index.html




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Apr 2005 18:38:21 +0000
Message-ID: <[e-mail]>
Date: Thu, 07 Apr 2005 20:37:08 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: [e-mail], [e-mail]
Cc: [e-mail], kireeti Kompella <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>
Subject: Re: WG  last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi Dimitri,

see below for responses...

>>
>>> 3. section 4.1
>>>
>>> "The subobjects are identical to
>>>    those defined in [RFC3209] and [RFC3473] for use in EROs."
>>>
>>> looking at the definitions this is not the case (moreover the SRLG 
>>> subobject has been added) -
>>
>>
>> Are you only referring to the SRLG subobject? If yes, then it is best 
>> to change it into "...those defined in [RFC3209] and [RFC3473] for use 
>> in EROs and section 3.1 of this document."
> 
> 
> -> yes, but also ERO subobjects do not include an attribute field, XRO 
> subobjects do
> 

Correct.  We use ERO subobjects with these modifications. There has been 
discussion in the past whether we reuse ERO subobjects and modify to 
make them useful for XRO, or whether we define for the XRO new 
subobjects. So far, the decision was to do the former but this is of 
course open for discussion. The consequence is that when we want to 
exclude something in the XRO, we also need the corresponding to include 
it in the ERO. For SRLGs this means that we need an SRLG ERO subobject 
which is not defined previously. It does not make much sense to have an 
SRLG ERO subobject (that is why you would not find a document describing 
the processing rules of such an object in the ERO), but it is needed for 
  the corresponding subobject in the XRO.



>>> 4. section 4.1
>>>
>>> "  An Attribute octet is introduced in the subobjects that define IP
>>>    addresses to indicate the attribute (e.g.  interface, node, SRLG)
>>>    associated with the IP addresses that can be excluded from the path."
>>>
>>> what is a subobject that define IP addresses ?
>>
>>
>> see following subsections. Is it enough that I change "IP address" 
>> into "IP prefix" to make it more clear?
> 
> 
> wouldn't be better to refer to the subobject types instead, something 
> like (concerning the
> 
> "An Attribute field is introduced in the subobjects Type 1, 2 and 4 to 
> indicate the attribute (e.g. interface, node, SRLG) that is associated 
> with the IP address included as part of the subobject and that can be 
> excluded from the path."
> 

Sounds better. I will do that. I will also remove the word "IP address" 
because unnumbered (type 4) is not really an IP address.

> also definition of the attribute value should refer better to "IPv4 or 
> IPv6 address treated as an prefix based on the prefix length value"
> 
> last point but this is editorial, currently you have
> 
> 4.1.1  Subobject 1: IPv4 prefix
> 4.1.2  Subobject 2: IPv6 Prefix
> 4.1.3  Subobject 32: Autonomous System Number
> 4.1.4  Subobject TBD: SRLG
> 4.1.5  Subobject 4: Unnumbered Interface ID Subobject
> 
> wouldn't it be better to list them as
> 
> 4.1.1  Subobject 1: IPv4 prefix
> 4.1.2  Subobject 2: IPv6 Prefix
> 4.1.3  Subobject 4: Unnumbered Interface ID Subobject
> 4.1.4  Subobject 32: Autonomous System Number
> 4.1.5  Subobject TBD: SRLG
> 

yes

>>> 5. section 4.1
>>>
>>> "   For instance, the attribute node allows a whole node to be excluded
>>>    from the path, in contrast to the attribute interface, which allows
>>>    specific interfaces to be excluded from the path. "
>>>
>>> but below the definition says "0 indicates that the interface or set 
>>> of interfaces associated with the IP prefix should be excluded or 
>>> avoided" which makes the term specific ambiguous
>>
>>
>> Section 4.1 is an example on how to exclude a node or an interface 
>> from  a path. Section 4.1.1 contains the full specification and the 
>> example looks to be contained in 4.1.1.
> 
> 
> indeed, this is what i understood, my question is more "how can you be 
> specific if you remove a set of interfaces"
> 

??? Is it OK if I change it into "For instance, the attribute node 
allows a whole node to be excluded from the path, in contrast to the 
attribute interface, which allows a specific interface or set of 
interfaces to be excluded from the path."

Note that the interfaces in the set of interfaces does not have to be on 
the same node.

>>> 6. section 4.1.5
>>>
>>> "         node
>>>
>>>              1 indicates that the node with the Router ID should be
>>>                excluded or avoided (this can be achieved using IPv4/v6
>>>                subobject as well, but is included here because it may be
>>>                convenient to use subobjects from RRO, in specifying the
>>>                exclusions)"
>>>
>>> until "(this can be achieved using IPv4/v6 subobject" i understand 
>>> after  i would ask you to clarify i guess you mean RRO from another 
>>> path ? should you include this as part of the definition ?
>>
>>
>> Can you give an example on how the exlude/avoid resources from a path 
>> computation while the path is already computed and signaled (otherwise 
>> you do not have an RRO)?
> 
> 
> you signal a first LSP, at the ingress you recuperate the (Resv) RRO 
> that you inject (may be after some transformation) as part of the XRO of 
> another LSP (load balancing for inst.)
> 
> now concerning the initial point (as i do not understand what you mean 
> by "use RRO subobjects for exclusion" to achieve the same functionality 
> as an XRO with the Type 4 subobject) would you please provide 1) the 
> explanation about the context of the usage of the RRO subobjects for 
> exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then 
> 2) why do you think providing two ways to do the same thing as part of 
> the same document is useful ?
> 

to make it more exact, I will change it into "*information* from RRO 
subobjects, in speficying the exclusions." toghether with a reference to 
the RRO-subobjects.


>>
>>> 9. section 4.2 - condition 4. "The number of introduced SLRGs with 
>>> the L flag set to "avoid" should be minimised." i guess you mean wrt 
>>> to the number of "exclude" SRLGs (blocking) ? or is there an absolute 
>>> limitation due to the message size
>>
>>
>> The sentence you are referring to is not related to the number of 
>> subobejcts in the XRO. It is related to the number of links belonging 
>> to SRLGs that should be avoided. 
> 
> 
> please rephrase it - because it is quite difficult to deduce this 
> meaning (in particular, if a recommendation follows that statement)
> 
>> For instance, when there is a path that has a link with 1 SRLG to be 
>> avoided, and there is another path with a link of 2 SRLGs to be 
>> avoided, and there are no alternative paths then take the first path 
>> because it minimises the number of SLRGs with the L flag set to avoid.
>>
>> To make it clear, I will change the text as follows: "The number of 
>> introduced explicit ndoes or abstract nodes in the computed path with 
>> the L flag set to "avoid" should be minimised.
> 
> 
> ok - and indicate a sensible reason would help in understanding why - 
> this is not difficult to be spelled out anyway
> 

ok

>>> 10. section 4.2 - concerning the operations i would suggesting adding 
>>> a rule suggesting that no contradicting exclusions get inserted
>>
>>
>> What is a contradicting exclusion? Do you mean if for instance a node 
>> appears twice in the XRO, as avoid and exclude? In that case it is 
>> exclude. I will add a statement. Contradictions with ERO are possible 
>> but that is mentioned.
> 
> 
> the document says "If an XRO was present, the content of the XRO can be 
> modified." so what i mean is that THIS node does not introduce a 
> exclusion for an subobject it has itself included as part of the ERO (as 
> the document explains how to process such contradicting exclusions but 
> should also have clear rules in terms of generation of XROs)
> 

Ok, I see, it should indeed be mentioned somewhere that nodes MUST NOT 
generate ERO and XRO/EXRS with conflicting information. Nevertheless it 
remains needed to be said what has to be done when conflicting ERO and 
XRO/EXRS are received by a node.

> 
>>> 13. section 5.1
>>>
>>> "  Note: The Most Significant Bit in the Type field could be used to
>>>    indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
>>>    the need to prepend the subobject with an additional TLV header.
>>>    This would reduce the number bytes require for each subobject by 2
>>>    bytes.  However, this approach would reduce the ERO Type field space
>>>    by half.  This issue need WG discussion and feedback."
>>>
>>> -> i would suggest keeping existing definition (since the EXRS is to 
>>> considered as an optimization), this said better formalization of the 
>>> EXRS subobjects needs to be provided - as the next section mentions 
>>> "Each EXRS may carry multiple exclusions.  The exclusion is encoded 
>>> exactly as for XRO subobjects and prefixed by an additional Type and 
>>> Length." while with the provided alignment it looks like each 
>>> exclusion element is encoded with this double Type/Length field
>>
>>
>> Thanks for your feedback on this question. Concerning the alignment: 
>> there can be multiple subobjects in an EXRS, note the plural form of 
>> "EXRS subobjects" in the first figure of section 5.1. 
> 
> 
> also "The format of this field is exactly the format of an XRO subobject 
> and may include an SRLG subobject.  Both subobjects are as described 
> earlier in this document." ... both subobjects refers to ?
> 
>> Better to make this more explicit in the specification of "EXRS 
>> subobjects": One or more EXRS subobjects. An EXRS subobject 
>> indicates....". For a better alignment it might be better to indeed 
>> add 2 padding bytes after the Type and Length.
> 
> 
> ok - i do suggest making use of this padding since we speak about a list 
> including sub-lists of subobjects and not lists including (double 
> type/length) subobjects
> 

Ok, I will add 2 padding bytes.


>>
>>> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this 
>>> should better be defined as an "SRLG Subobject" as i do not see a 
>>> specific reason for having an SRLG subobject outside of the XRO, EXRS 
>>> context ?
>>
>>
>> not really, see 2 previous comments. It is really an ERO subobject but 
>> the usage of this in ERO is not part of this document. 
> 
> 
> would it be possible to know which document makes use of SRLG as part of 
> an ERO ?
> 

see beginning of this email.

>> This comes down to the discussion whether XRO defines new subobjects 
>> specific for XRO or whether XRO simply reuses the ERO subobjects with 
>> some modifications (L-flag and attribute). So far, the latter has been 
>> choosen but that means that it is an SRLG ERO subobject.
> 
> 
> ok - but then indicate that there is no description available of the 
> usage of an SRLG subobjects as part of an ERO
> 

ok

>>> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the 
>>> IPv4 subobject, etc.
>>
>>
>> yes
>>
>>> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,
>>
>>
>> see rfc3477, section 4, from where we got the object. In fact, a 
>> reference to this RFC is missing.
> 
> 
> this rfc refers to the former but i do suggest using the latter as this 
> has already generated enough issues
> 

Ok, will change it into "TE Router ID"

>>> 7. section 5.1
>>>
>>> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
>>> what do you mean by might ? isn't EXRS instead of EXRO ?
>>
>>
>> "Might" means that there other methods to do the same. For instance, 
>> if the IP hop is IPv6, it looks different. If unnumbered links are 
>> used, it is also different. Indeed, EXRO should be EXRS.
> 
> 
> indeed but might is not really used in a prescptive document (prefer MAY 
> with alternatives in case)
> 

ok, will use "may"


>>
>>> 9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2 
>>> Processing Rules for the EXR Subobject and its Subobjects"
>>
>>
>> indeed. should be "5.2 Semantics and Processing Rules for the EXRS and 
>> its Subobjects".
> 
> 
> suggest to remove the term semantic since it should be clear from its 
> definition in section 5.1
> 

It depends on how the content of this section evolves. It is similar to 
section 4.2, with similar title. Removign Semantic in both sections 
looks good to me.

regards,

Stefaan




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Apr 2005 17:16:16 +0000
Message-ID: <006201c53b95$855fa150$6fcb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Bill Fenner" <[e-mail]>, "Scott Bradner" <[e-mail]>
Subject: Fw: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt
Date: Thu, 7 Apr 2005 13:52:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please see below a response from the Counsel for Nortel Networks with
regard to my enquiry about their IPR disclosure for
draft-ietf-ccamp-loose-path-reopt-00.txt.

The working group must now decide whether it wishes to pursue the
techniques described in the I-D notwithstanding the IPR claim, or whether
it should seek out an alternative technology.

Discussion please.

Thanks,
Adrian
----- Original Message ----- 
From: "Michelle Lee" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "'Kireeti Kompella'" <[e-mail]>; "Richard Weiss"
<[e-mail]>
Sent: Wednesday, April 06, 2005 5:54 PM
Subject: RE: Nortel Networks Statement on IPR claimed in
draft-ietf-ccamp-loose-path-reopt-00.txt


> Dear Mr. Farrel,
>
> Thank you for your email.
>
> Unfortunately, I am not in a position to answer these questions
> specifically, especially since they would require my providing
privileged
> and/or confidential information. We believe, however, our intentions are
> clearly set forth in and by our conforming disclosure and declaration
> statement to IETF with respect to IETF Internet Draft
> draft-ietf-ccamp-loose-path-reopt-00.txt, and that experts in the area
can
> probably better determine relevance of the identified patent therein.
>
> Kind Regards,
> Michelle Lee
> Counsel, IP Law
> Nortel Networks
>
>
>  -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, March 21, 2005 4:32 PM
> To: [e-mail]; [e-mail]
> Cc: 'Kireeti Kompella'; [e-mail]
> Subject: Nortel Networks Statement on IPR claimed in
> draft-ietf-ccamp-loose-path-reopt-00.txt
>
>
>
> Dear Richard and Michelle,
>
> Thank you for submitting your Patent Disclosure
> (
>
<http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt
-0
> 0.txt>
>
http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00
> .txt)
> with respect to IETF Internet Draft
> draft-ietf-ccamp-loose-path-reopt-00.txt.
>
> I would be grateful if you could clarify two points to help me
understand
> this discolsure further.
>
> 1. The disclosure states that:
>      Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and
>      method of maintaining timely topology data within a link state
routing
>      network" may contain claims that may be necessary for practicing a
>      resulting IETF Standard based on this Internet Draft.
>   Could you provide more detail about what aspects of
>   draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted
by
>   this disclosure?
>
> 2. Can you clarify whether the "fair, reasonable, reciprocal, and
>    non-discriminatory terms" referenced in the disclosure include the
>    intention, in the event that the referenced draft becomes an Internet
>    Standard, not to assert the patent except that some party asserts a
> patent
>    patent it owns or controls against Nortel?
>    By way of an example of wording that covers this intention, can I
draw
>    your attention to a completely unrelated IPR disclosure at
>
<http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt>
> http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt
>
> Thank you for any clarification you are able to offer.
>
> Please note that I am copying this email to Kireeti Kompella who
co-chairs
> the IETF's CCAMP working group with me. The CCAMP working group
developed
> the Internet-Draft in question
(draft-ietf-ccamp-loose-path-reopt-00.txt)
> and so I am also copying this email to the CCAMP mailing list.
>
> Best regards,
> Adrian Farrel
> --
> Adrian Farrel
> Old Dog Consulting
> Phone: [phone]
> Fax: [phone]
> [e-mail] <mailto:[e-mail]>
>
>
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 07 Apr 2005 10:47:11 +0000
Date: Thu, 07 Apr 2005 18:08:25 +0800
From: Amit 70405 <[e-mail]>
Subject: About LSP Stiching
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi All,
	In the draft draft-ietf-ccamp-lsp-stitching-00 for LSP stitching, I think one more extension may be needed for E2e LSP.
	The draft suggest 2 main extensions,LSP Stitch desired bit and LSP Stitch Ready Bit.
	Both these extensions are for LSP Segement LSP.
	An LSP Segment will be treated like any other TE-Link.
	So TE-Link type will be hidden from E2e LSP.
	There is no way for LSP segment head node, to identify that a Outif selected is a LSP Segment for setting up E2e LSP.

	That is Some extension will be needed to RSVP that will allow RSVP message(for E2e LSP) processing at LSP segment head node to be processed according to the Sticthing needs.

	For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B.

	1-----A--D---E--B-----2

	Now if A gets the Path message for LSP1-2, and A selects LSP segment LSPA-B as outif.
	Then how does RSVP(at Node A) identify that the outif selected is a LSP segment?
	
	Also when A receives Resv for LSP1-2(from B), how can it ignore Label in it.
	There should be a way to determine at node A, that a LSP segment is in use.

	One possible way could be that Resv message for LSP1-2 should be sent(by B) with some special Label value.
	This Label value should indicate the node A that the Resv is received for a TE-Link(of type LSP Segment).
	This will help node A to ignore Label value in Resv msg for E2e Lsp LSP1-2.

	Plz let me know your view.
	Thanks in advance.
Regards,
Amit.





Envelope-to: [e-mail]
Delivery-date: Thu, 07 Apr 2005 07:56:22 +0000
Message-ID: <[e-mail]>
Date: Thu, 07 Apr 2005 09:53:35 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To:  [e-mail]
CC:  [e-mail],  [e-mail],  kireeti Kompella <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>
Subject: Re: WG  last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi stefaan

thanks for your detailed reply - see in-line for some additional 
clarifications

[e-mail] wrote:
> 
> Hi Dimitri,
> 
> Thanks for these useful comments. Replies inline...
> 
> dimitri papadimitriou wrote:
> 
>> hi adrian,
>>
>> some comments here below on the exclude route i-d
>>
>> technical
>> ---------
>>
>> 1. section 2.1
>>
>>  "Constrained Shortest Path First (CSPF) computation at Ingress, so the
>>    ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, 
>> AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively."
>>
>> AB1 should also be excluded as AB2 does not know the first path 
>> crosses this node so there may be a case (in this example for inst. 
>> imagine there is no link between AB2 and B3) where this could lead to 
>> overlap if AB2 selects an area B link to reach AB1
> 
> correct, the same applies for the next area as well.
> 
>> 2. section 4
>>
>> "The exclude route identifies a list of abstract nodes that MUST NOT
>>    be traversed along the path of the LSP being established."
>>
>> while section 4.1
>>
>> " The concept of loose or strict hops has no meaning in route
>>    exclusion.  The L bit, defined for ERO subobjects in [RSPV-TE], is
>>    reused here to indicate that an abstract node MUST be avoided (value
>>    0) or SHOULD be avoided (value 1)."
> 
> correct. I believe it is better to say "... that should not be 
> traversed..." with "should" in small because the formal specification is 
> in the subsections.
> 
>> 3. section 4.1
>>
>> "The subobjects are identical to
>>    those defined in [RFC3209] and [RFC3473] for use in EROs."
>>
>> looking at the definitions this is not the case (moreover the SRLG 
>> subobject has been added) -
> 
> Are you only referring to the SRLG subobject? If yes, then it is best to 
> change it into "...those defined in [RFC3209] and [RFC3473] for use in 
> EROs and section 3.1 of this document."

-> yes, but also ERO subobjects do not include an attribute field, XRO 
subobjects do

>> 4. section 4.1
>>
>> "  An Attribute octet is introduced in the subobjects that define IP
>>    addresses to indicate the attribute (e.g.  interface, node, SRLG)
>>    associated with the IP addresses that can be excluded from the path."
>>
>> what is a subobject that define IP addresses ?
> 
> see following subsections. Is it enough that I change "IP address" into 
> "IP prefix" to make it more clear?

wouldn't be better to refer to the subobject types instead, something 
like (concerning the

"An Attribute field is introduced in the subobjects Type 1, 2 and 4 to 
indicate the attribute (e.g. interface, node, SRLG) that is associated 
with the IP address included as part of the subobject and that can be 
excluded from the path."

also definition of the attribute value should refer better to "IPv4 or 
IPv6 address treated as an prefix based on the prefix length value"

last point but this is editorial, currently you have

4.1.1  Subobject 1: IPv4 prefix
4.1.2  Subobject 2: IPv6 Prefix
4.1.3  Subobject 32: Autonomous System Number
4.1.4  Subobject TBD: SRLG
4.1.5  Subobject 4: Unnumbered Interface ID Subobject

wouldn't it be better to list them as

4.1.1  Subobject 1: IPv4 prefix
4.1.2  Subobject 2: IPv6 Prefix
4.1.3  Subobject 4: Unnumbered Interface ID Subobject
4.1.4  Subobject 32: Autonomous System Number
4.1.5  Subobject TBD: SRLG

>> 5. section 4.1
>>
>> "   For instance, the attribute node allows a whole node to be excluded
>>    from the path, in contrast to the attribute interface, which allows
>>    specific interfaces to be excluded from the path. "
>>
>> but below the definition says "0 indicates that the interface or set 
>> of interfaces associated with the IP prefix should be excluded or 
>> avoided" which makes the term specific ambiguous
> 
> Section 4.1 is an example on how to exclude a node or an interface from 
>  a path. Section 4.1.1 contains the full specification and the example 
> looks to be contained in 4.1.1.

indeed, this is what i understood, my question is more "how can you be 
specific if you remove a set of interfaces"

>> 6. section 4.1.5
>>
>> "         node
>>
>>              1 indicates that the node with the Router ID should be
>>                excluded or avoided (this can be achieved using IPv4/v6
>>                subobject as well, but is included here because it may be
>>                convenient to use subobjects from RRO, in specifying the
>>                exclusions)"
>>
>> until "(this can be achieved using IPv4/v6 subobject" i understand 
>> after  i would ask you to clarify i guess you mean RRO from another 
>> path ? should you include this as part of the definition ?
> 
> Can you give an example on how the exlude/avoid resources from a path 
> computation while the path is already computed and signaled (otherwise 
> you do not have an RRO)?

you signal a first LSP, at the ingress you recuperate the (Resv) RRO 
that you inject (may be after some transformation) as part of the XRO of 
another LSP (load balancing for inst.)

now concerning the initial point (as i do not understand what you mean 
by "use RRO subobjects for exclusion" to achieve the same functionality 
as an XRO with the Type 4 subobject) would you please provide 1) the 
explanation about the context of the usage of the RRO subobjects for 
exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then 
2) why do you think providing two ways to do the same thing as part of 
the same document is useful ?

>> 7. section 4.2 - condition 1. what does happen when the L flag is not 
>> set and the condition is not verified ?
>>
> 
> Then the actions mentioned do not have to be done and the next step in 
> the processing is done. There is no explicit statement saying that in 
> this case the next step must be taken, neither is there a statement 
> saying that the processing also stops when the condition is met. See 
> 4.3.4.1. of RFC3209 for similar way of describing processing.
> 
>> 8. section 4.2 - condition 3. "If they do contradict, the subobjects 
>> with the L flag not set, strict or MUST be excluded, respectively, in 
>> the ERO or XRO MUST take precedence." this sentence is cryptic i put 
>> in the technical part because it impacts understanding concerning the 
>> exact processing
> 
> Indeed, the sentence is not understandable and even wrong (the same 
> applies to a similar sentence in EXRS). Irrespective of whether the ERO 
> subobject is strict or loose, it takes precedence togheter with exclude 
> subobjects in the XRO over the avoid subobjects.
> 
>> 9. section 4.2 - condition 4. "The number of introduced SLRGs with the 
>> L flag set to "avoid" should be minimised." i guess you mean wrt to 
>> the number of "exclude" SRLGs (blocking) ? or is there an absolute 
>> limitation due to the message size
> 
> The sentence you are referring to is not related to the number of 
> subobejcts in the XRO. It is related to the number of links belonging to 
> SRLGs that should be avoided. 

please rephrase it - because it is quite difficult to deduce this 
meaning (in particular, if a recommendation follows that statement)

> For instance, when there is a path that 
> has a link with 1 SRLG to be avoided, and there is another path with a 
> link of 2 SRLGs to be avoided, and there are no alternative paths then 
> take the first path because it minimises the number of SLRGs with the L 
> flag set to avoid.
> 
> To make it clear, I will change the text as follows: "The number of 
> introduced explicit ndoes or abstract nodes in the computed path with 
> the L flag set to "avoid" should be minimised.

ok - and indicate a sensible reason would help in understanding why - 
this is not difficult to be spelled out anyway

>> 10. section 4.2 - concerning the operations i would suggesting adding 
>> a rule suggesting that no contradicting exclusions get inserted
>
> What is a contradicting exclusion? Do you mean if for instance a node 
> appears twice in the XRO, as avoid and exclude? In that case it is 
> exclude. I will add a statement. Contradictions with ERO are possible 
> but that is mentioned.

the document says "If an XRO was present, the content of the XRO can be 
modified." so what i mean is that THIS node does not introduce a 
exclusion for an subobject it has itself included as part of the ERO (as 
the document explains how to process such contradicting exclusions but 
should also have clear rules in terms of generation of XROs)

>> 11. section 5.
>>
>> "The Explicit Exclude Route defines abstract nodes or resources (such
>>    as links, unnumbered interfaces or labels) that must not be used on
>>    the path between two inclusive abstract nodes or resources in the
>>    explicit route."
>>
>> ... "must" while the L bit means either "avoid" or "exclude"
> 
> indeed, should be "...must not or should not be used...".
> 
>> 12. section 5.1
>>
>> "  A new ERO subobject type is defined.  The Explicit Exclude Route
>>    Subobject (EXRS) has type [TBD].  The EXRS may not be present in an
>>    RRO or XRO."
>>
>> would you clarify the meaning of the second sentence in the context of 
>> the first one ? (note: the doc. since far tells the reader that the 
>> EXRS is an ERO subobject)
> 
> Better to make it "The EXRS MUST NOT be present in an XRO". The 
> subobjects of the XRO are the same as the ERO subobject. The EXRS is 
> also an ERO subobject, but may not be present in XRO. It is rather 
> obvious that EXRS can not be in the RRO, so that can be removed.

ok -

>> 13. section 5.1
>>
>> "  Note: The Most Significant Bit in the Type field could be used to
>>    indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
>>    the need to prepend the subobject with an additional TLV header.
>>    This would reduce the number bytes require for each subobject by 2
>>    bytes.  However, this approach would reduce the ERO Type field space
>>    by half.  This issue need WG discussion and feedback."
>>
>> -> i would suggest keeping existing definition (since the EXRS is to 
>> considered as an optimization), this said better formalization of the 
>> EXRS subobjects needs to be provided - as the next section mentions 
>> "Each EXRS may carry multiple exclusions.  The exclusion is encoded 
>> exactly as for XRO subobjects and prefixed by an additional Type and 
>> Length." while with the provided alignment it looks like each 
>> exclusion element is encoded with this double Type/Length field
> 
> Thanks for your feedback on this question. Concerning the alignment: 
> there can be multiple subobjects in an EXRS, note the plural form of 
> "EXRS subobjects" in the first figure of section 5.1. 

also "The format of this field is exactly the format of an XRO subobject 
and may include an SRLG subobject.  Both subobjects are as described 
earlier in this document." ... both subobjects refers to ?

> Better to make this more explicit in the specification of "EXRS subobjects": One or 
> more EXRS subobjects. An EXRS subobject indicates....". For a better 
> alignment it might be better to indeed add 2 padding bytes after the 
> Type and Length.

ok - i do suggest making use of this padding since we speak about a list 
including sub-lists of subobjects and not lists including (double 
type/length) subobjects

>> note that section 5. would probably require a revision after 
>> completion of the technical details
> 
> I agree. In fact, I believe the processing can be largely removed by 
> referring to the XRO processing. The processing is the same except with 
> the limitation that it only applies to a part of the path. For instance 
> comment 8 above, also applies here and it makes not much sense to 
> duplicate things.
> 
>> 14. section 6.
>>
>> "   2.  The EXRS SHOULD be supported.  If supported, the same
>>        restrictions as for the XRO apply."
>>
>> -> the EXRS is an optimization it should not be considered as a should 
>> but optional ie MAY
>
> Because it is about *minimal* compliance, I tend to agree.

indeed

>> 15. there is nothing said concerning usage of EXRS when using XRO ?
> 
> Good point. Since there is basically not much difference in the 
> processing between EXRS and XRO, it is not a big deal to handle both.

i would suggest carefully analyzing all the potential cases here in 
part. for the partial overlaps

>> editorial
>> ---------
>>
>> 1. section 2. and onward why referring to a "Explicit Exclude Route" 
>> and then to a "5.1  Explicit Exclusion Route Subobject (EXRS)" and not 
>> a "Explicit Exclude Route Subobject (EXRS)" ? -> the document would 
>> benefit from using a single term either "exclude" or "exclusion"
>>
> 
> ok, lets take "exclusion"
> 
>> 2. section 2.
>>
>> "  This subobject might also be appropriate for use within Explicit
>>    Routes or Record Routes, but that discussion is outside the scope of
>>    this document."
>>
>> would suggest replace this sentence with "This document does not 
>> assume or preclude any other usage for this subobject."
> 
> ok
> 
>> 3. section 2. "A new subobject type the Explicit Exclude
>>        Route Subobject (EXRS) is introduced to indicate an exclusion
>>        between a pair of included abstract nodes."
>>
>> would complete the last part of the sentence (as i guess you mean of 
>> the ERO in the present context)
> 
> indeed, sentence should be "A new ERO subobject type ...."
> 
>> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this 
>> should better be defined as an "SRLG Subobject" as i do not see a 
>> specific reason for having an SRLG subobject outside of the XRO, EXRS 
>> context ?
> 
> not really, see 2 previous comments. It is really an ERO subobject but 
> the usage of this in ERO is not part of this document. 

would it be possible to know which document makes use of SRLG as part of 
an ERO ?

> This comes down 
> to the discussion whether XRO defines new subobjects specific for XRO or 
> whether XRO simply reuses the ERO subobjects with some modifications 
> (L-flag and attribute). So far, the latter has been choosen but that 
> means that it is an SRLG ERO subobject.

ok - but then indicate that there is no description available of the 
usage of an SRLG subobjects as part of an ERO

>> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the 
>> IPv4 subobject, etc.
> 
> yes
> 
>> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,
> 
> see rfc3477, section 4, from where we got the object. In fact, a 
> reference to this RFC is missing.

this rfc refers to the former but i do suggest using the latter as this 
has already generated enough issues

>> 7. section 5.1
>>
>> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
>> what do you mean by might ? isn't EXRS instead of EXRO ?
> 
> "Might" means that there other methods to do the same. For instance, if 
> the IP hop is IPv6, it looks different. If unnumbered links are used, it 
> is also different. Indeed, EXRO should be EXRS.

indeed but might is not really used in a prescptive document (prefer MAY 
with alternatives in case)

>> 8. section 5.1
>>
>> "Both subobjects are as described earlier in this document." both (to 
>> which subobject do you refer here) ?
> 
> should be "The format of an EXRS subobject is exactly the same as the 
> format of a subobject in the XRO. An EXRS may include all subobjects 
> defined for the XRO in this document.".
> 
> In this way it is more clear. Becuase SRLG has been defined for XRO in 
> this document it may also be in the EXRS but that is implicit in the 
> above sentence.
> 
>> 9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2 
>> Processing Rules for the EXR Subobject and its Subobjects"
> 
> indeed. should be "5.2 Semantics and Processing Rules for the EXRS and 
> its Subobjects".

suggest to remove the term semantic since it should be clear from its 
definition in section 5.1

>> 10. section 5.2
>>
>> "If the presence of EXRO Subobjects precludes further forwarding of
>>    the Path message, the node should return a PathErr with the error
>>    code "Routing Problem" and error value of "Route blocked by Exclude
>>    Route"."
>>
>> you mean EXRS ? instead EXRO ?
> 
> yes
> 
>> 11. section 5.2
>>
>> "If a node is called upon to process an EXRS and does not support
>>    handling of exclusions it will return a PathErr with a "Bad
>>    EXPLICIT_ROUTE object" error."
>>
>> ... Routing Problem/Bad EXPLICIT_ROUTE object
> 
> yes
> 
>> note that in general definition of the subobject field could be made a 
>> bit more explicit
> 
> I agree with that.
> 
>> hope these comments will help you
> 
> Sure. Thanks for the comments.
> 
> regards,
> 
> Stefaan
> 
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Apr 2005 15:31:19 +0000
Message-ID: <181601c53abd$a2af8910$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Lam, Hing-Kam (Kam)" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "Scott Bradner" <[e-mail]>, <[e-mail]>, "Bill Fenner" <[e-mail]>
Subject: Liaison to ITU-T Q14/15 on Inclusion of Crankback in G.7713
Date: Wed, 6 Apr 2005 15:25:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

To: Mr. Kam Lam, Rapporteur ITU-T Q14/15
From: Adrian Farrel and Kireeti Kompella
          Co-chairs of IETF CCAMP Working Group
Subject: Inclusion of Crankback in G.7713
For: Action
Deadline: May 1st 2005

Dear Mr. Lam,

Thank you for your recent response liaison on Crankback. The CCAMP working
group is pleased to hear that our work on crankback is of use to your
Question and looks forward to seeing the inclusion of crankback within
G.7713, and to the inclusion of specific protocol elements in G.7713.2.

In order to increase the convergence between the work of our two
organizations, the CCAMP working group would welcome the opportunity to
review and comment on these inclusions in G.7713 and G.7713.2 before they
are presented for consent.

Thank you.

Adrian Farrel and Kireeti Kompella




Envelope-to: [e-mail]
Delivery-date: Wed, 06 Apr 2005 13:23:46 +0000
Message-ID: <[e-mail]>
Date: Wed, 06 Apr 2005 15:21:15 +0200
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: [e-mail], [e-mail]
Cc: [e-mail], kireeti Kompella <[e-mail]>, [e-mail], Adrian Farrel <[e-mail]>
Subject: Re: WG  last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

Hi Dimitri,

Thanks for these useful comments. Replies inline...

dimitri papadimitriou wrote:

> hi adrian,
> 
> some comments here below on the exclude route i-d
> 
> technical
> ---------
> 
> 1. section 2.1
> 
>  "Constrained Shortest Path First (CSPF) computation at Ingress, so the
>    ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, 
> AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively."
> 
> AB1 should also be excluded as AB2 does not know the first path crosses 
> this node so there may be a case (in this example for inst. imagine 
> there is no link between AB2 and B3) where this could lead to overlap if 
> AB2 selects an area B link to reach AB1
> 

correct, the same applies for the next area as well.

> 2. section 4
> 
> "The exclude route identifies a list of abstract nodes that MUST NOT
>    be traversed along the path of the LSP being established."
> 
> while section 4.1
> 
> " The concept of loose or strict hops has no meaning in route
>    exclusion.  The L bit, defined for ERO subobjects in [RSPV-TE], is
>    reused here to indicate that an abstract node MUST be avoided (value
>    0) or SHOULD be avoided (value 1)."
> 

correct. I believe it is better to say "... that should not be 
traversed..." with "should" in small because the formal specification is 
in the subsections.


> 
> 3. section 4.1
> 
> "The subobjects are identical to
>    those defined in [RFC3209] and [RFC3473] for use in EROs."
> 
> looking at the definitions this is not the case (moreover the SRLG 
> subobject has been added) -
> 

Are you only referring to the SRLG subobject? If yes, then it is best to 
change it into "...those defined in [RFC3209] and [RFC3473] for use in 
EROs and section 3.1 of this document."

> 4. section 4.1
> 
> "  An Attribute octet is introduced in the subobjects that define IP
>    addresses to indicate the attribute (e.g.  interface, node, SRLG)
>    associated with the IP addresses that can be excluded from the path."
> 
> what is a subobject that define IP addresses ?

see following subsections. Is it enough that I change "IP address" into 
"IP prefix" to make it more clear?

> 
> 5. section 4.1
> 
> "   For instance, the attribute node allows a whole node to be excluded
>    from the path, in contrast to the attribute interface, which allows
>    specific interfaces to be excluded from the path. "
> 
> but below the definition says "0 indicates that the interface or set of 
> interfaces associated with the IP prefix should be excluded or avoided" 
> which makes the term specific ambiguous
> 

Section 4.1 is an example on how to exclude a node or an interface from 
  a path. Section 4.1.1 contains the full specification and the example 
looks to be contained in 4.1.1.


> 6. section 4.1.5
> 
> "         node
> 
>              1 indicates that the node with the Router ID should be
>                excluded or avoided (this can be achieved using IPv4/v6
>                subobject as well, but is included here because it may be
>                convenient to use subobjects from RRO, in specifying the
>                exclusions)"
> 
> until "(this can be achieved using IPv4/v6 subobject" i understand after 
>  i would ask you to clarify i guess you mean RRO from another path ? 
> should you include this as part of the definition ?
> 

Can you give an example on how the exlude/avoid resources from a path 
computation while the path is already computed and signaled (otherwise 
you do not have an RRO)?

> 7. section 4.2 - condition 1. what does happen when the L flag is not 
> set and the condition is not verified ?
> 

Then the actions mentioned do not have to be done and the next step in 
the processing is done. There is no explicit statement saying that in 
this case the next step must be taken, neither is there a statement 
saying that the processing also stops when the condition is met. See 
4.3.4.1. of RFC3209 for similar way of describing processing.

> 8. section 4.2 - condition 3. "If they do contradict, the subobjects 
> with the L flag not set, strict or MUST be excluded, respectively, in 
> the ERO or XRO MUST take precedence." this sentence is cryptic i put in 
> the technical part because it impacts understanding concerning the exact 
> processing
> 

Indeed, the sentence is not understandable and even wrong (the same 
applies to a similar sentence in EXRS). Irrespective of whether the ERO 
subobject is strict or loose, it takes precedence togheter with exclude 
subobjects in the XRO over the avoid subobjects.

> 9. section 4.2 - condition 4. "The number of introduced SLRGs with the L 
> flag set to "avoid" should be minimised." i guess you mean wrt to the 
> number of "exclude" SRLGs (blocking) ? or is there an absolute 
> limitation due to the message size
> 

The sentence you are referring to is not related to the number of 
subobejcts in the XRO. It is related to the number of links belonging to 
SRLGs that should be avoided. For instance, when there is a path that 
has a link with 1 SRLG to be avoided, and there is another path with a 
link of 2 SRLGs to be avoided, and there are no alternative paths then 
take the first path because it minimises the number of SLRGs with the L 
flag set to avoid.

To make it clear, I will change the text as follows: "The number of 
introduced explicit ndoes or abstract nodes in the computed path with 
the L flag set to "avoid" should be minimised.


> 10. section 4.2 - concerning the operations i would suggesting adding a 
> rule suggesting that no contradicting exclusions get inserted
> 

What is a contradicting exclusion? Do you mean if for instance a node 
appears twice in the XRO, as avoid and exclude? In that case it is 
exclude. I will add a statement. Contradictions with ERO are possible 
but that is mentioned.


> 11. section 5.
> 
> "The Explicit Exclude Route defines abstract nodes or resources (such
>    as links, unnumbered interfaces or labels) that must not be used on
>    the path between two inclusive abstract nodes or resources in the
>    explicit route."
> 
> ... "must" while the L bit means either "avoid" or "exclude"
> 

indeed, should be "...must not or should not be used...".


> 12. section 5.1
> 
> "  A new ERO subobject type is defined.  The Explicit Exclude Route
>    Subobject (EXRS) has type [TBD].  The EXRS may not be present in an
>    RRO or XRO."
> 
> would you clarify the meaning of the second sentence in the context of 
> the first one ? (note: the doc. since far tells the reader that the EXRS 
> is an ERO subobject)
> 

Better to make it "The EXRS MUST NOT be present in an XRO". The 
subobjects of the XRO are the same as the ERO subobject. The EXRS is 
also an ERO subobject, but may not be present in XRO. It is rather 
obvious that EXRS can not be in the RRO, so that can be removed.




> 13. section 5.1
> 
> "  Note: The Most Significant Bit in the Type field could be used to
>    indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
>    the need to prepend the subobject with an additional TLV header.
>    This would reduce the number bytes require for each subobject by 2
>    bytes.  However, this approach would reduce the ERO Type field space
>    by half.  This issue need WG discussion and feedback."
> 
> -> i would suggest keeping existing definition (since the EXRS is to 
> considered as an optimization), this said better formalization of the 
> EXRS subobjects needs to be provided - as the next section mentions 
> "Each EXRS may carry multiple exclusions.  The exclusion is encoded 
> exactly as for XRO subobjects and prefixed by an additional Type and 
> Length." while with the provided alignment it looks like each exclusion 
> element is encoded with this double Type/Length field
> 

Thanks for your feedback on this question. Concerning the alignment: 
there can be multiple subobjects in an EXRS, note the plural form of 
"EXRS subobjects" in the first figure of section 5.1. Better to make 
this more explicit in the specification of "EXRS subobjects": One or 
more EXRS subobjects. An EXRS subobject indicates....". For a better 
alignment it might be better to indeed add 2 padding bytes after the 
Type and Length.

> note that section 5. would probably require a revision after completion 
> of the technical details
> 

I agree. In fact, I believe the processing can be largely removed by 
referring to the XRO processing. The processing is the same except with 
the limitation that it only applies to a part of the path. For instance 
comment 8 above, also applies here and it makes not much sense to 
duplicate things.

> 14. section 6.
> 
> "   2.  The EXRS SHOULD be supported.  If supported, the same
>        restrictions as for the XRO apply."
> 
> -> the EXRS is an optimization it should not be considered as a should 
> but optional ie MAY
> 

Because it is about *minimal* compliance, I tend to agree.

> 15. there is nothing said concerning usage of EXRS when using XRO ?
> 

Good point. Since there is basically not much difference in the 
processing between EXRS and XRO, it is not a big deal to handle both.


> editorial
> ---------
> 
> 1. section 2. and onward why referring to a "Explicit Exclude Route" and 
> then to a "5.1  Explicit Exclusion Route Subobject (EXRS)" and not a 
> "Explicit Exclude Route Subobject (EXRS)" ? -> the document would 
> benefit from using a single term either "exclude" or "exclusion"
> 

ok, lets take "exclusion"

> 2. section 2.
> 
> "  This subobject might also be appropriate for use within Explicit
>    Routes or Record Routes, but that discussion is outside the scope of
>    this document."
> 
> would suggest replace this sentence with "This document does not assume 
> or preclude any other usage for this subobject."
> 

ok

> 3. section 2. "A new subobject type the Explicit Exclude
>        Route Subobject (EXRS) is introduced to indicate an exclusion
>        between a pair of included abstract nodes."
> 
> would complete the last part of the sentence (as i guess you mean of the 
> ERO in the present context)
> 

indeed, sentence should be "A new ERO subobject type ...."

> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this 
> should better be defined as an "SRLG Subobject" as i do not see a 
> specific reason for having an SRLG subobject outside of the XRO, EXRS 
> context ?
> 

not really, see 2 previous comments. It is really an ERO subobject but 
the usage of this in ERO is not part of this document. This comes down 
to the discussion whether XRO defines new subobjects specific for XRO or 
whether XRO simply reuses the ERO subobjects with some modifications 
(L-flag and attribute). So far, the latter has been choosen but that 
means that it is an SRLG ERO subobject.


> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the 
> IPv4 subobject, etc.
> 

yes

> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,
> 

see rfc3477, section 4, from where we got the object. In fact, a 
reference to this RFC is missing.

> 7. section 5.1
> 
> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
> what do you mean by might ? isn't EXRS instead of EXRO ?
> 

"Might" means that there other methods to do the same. For instance, if 
the IP hop is IPv6, it looks different. If unnumbered links are used, it 
is also different. Indeed, EXRO should be EXRS.

> 8. section 5.1
> 
> "Both subobjects are as described earlier in this document." both (to 
> which subobject do you refer here) ?
> 

should be "The format of an EXRS subobject is exactly the same as the 
format of a subobject in the XRO. An EXRS may include all subobjects 
defined for the XRO in this document.".

In this way it is more clear. Becuase SRLG has been defined for XRO in 
this document it may also be in the EXRS but that is implicit in the 
above sentence.

> 9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2 Processing 
> Rules for the EXR Subobject and its Subobjects"
> 

indeed. should be "5.2 Semantics and Processing Rules for the EXRS and 
its Subobjects".

> 10. section 5.2
> 
> "If the presence of EXRO Subobjects precludes further forwarding of
>    the Path message, the node should return a PathErr with the error
>    code "Routing Problem" and error value of "Route blocked by Exclude
>    Route"."
> 
> you mean EXRS ? instead EXRO ?
> 

yes

> 11. section 5.2
> 
> "If a node is called upon to process an EXRS and does not support
>    handling of exclusions it will return a PathErr with a "Bad
>    EXPLICIT_ROUTE object" error."
> 
> ... Routing Problem/Bad EXPLICIT_ROUTE object
> 

yes

> note that in general definition of the subobject field could be made a 
> bit more explicit
> 

I agree with that.

> 
> hope these comments will help you
> 

Sure. Thanks for the comments.

regards,

Stefaan




Envelope-to: [e-mail]
Delivery-date: Wed, 06 Apr 2005 09:58:15 +0000
Date: Wed, 06 Apr 2005 17:05:39 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Regarding Reversion
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)"
Content-language: en

This is a multi-part message in MIME format.

--Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Dimitri,
   Thanks a lot for replying.

   But depending on GR may lead to below problems:
   - For all the LSP's, on restart(or failure) a notification MAY be sent to the upstream of the LSP about the failure. And if the upstream(Ingress) decides to delete the LSP, then upstream MAY only delete it till the restarted node. Downstream to the Retarted node the LSP will continue to exist as result of GR process till the GR completes.
   - And if a restarting node or the neighbor node doesnt support GR than it will not be possible to retain the LSP.

   Yes but I agree with you that GR can be used for Reversion.
   Thanks a lot again.

Regards,
Amit.


--Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)
Content-type: message/rfc822
Content-disposition: inline

MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: QUOTED-PRINTABLE

E*n*zZ*0***q****"z***^q**y***hnk*r***m*****<fsM*******h*********"******
	a**X**n[*)m1***M8*+a#>'tB4*F-*T*****6*xnk*r**y*: ***Nu**7**<*@*M*z+*u*******7*{3***)**m*****<`kM*******h*********"***
	***a**X**n[*)m1***M8*+a#>'tB4***3M*B****7*xnk*r**y*:***Nu**u**<*@*M*z+
	*u****r***(*^;**:*****x****z'(*#*jw*1*,j**'*****z-,u****[Lj***N0**DH**
	***4*wP*****Ch*=***jj]j***(*g***)*m4*N***>*M4E****~*&*****u**^*****jW
	**_****(****&**1*n8*Z*x***C'***M

=C4d=F4=E5B=054=95=A4S=D3#=E6&63=A3=C2=F4d=F4=E5C=E2=03=C4%#=E2=03=
=C4d=F4=E5B=054=95=A4S=D3#=E57V&=A6V7C=A3=C2=F4d=F4=E5C=E2=03=C4d=
=F4=E5B=054=95=A4S=D3#=E5&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3=
=C2=F4d=F4=E5C=E3=C4%#=E2=03=C4%#=E3=C4%#=E3=C2=F5=03=E3=C5=03=E3=
=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=
=92=04=16=C6=C2=C3=C4%#=E46=16=E2=06=16=E7=96&=F6G=92=07=06=C7=A2=
=066=C6=17&=96g=92=E3=C4%#=E5F=86=16=E6=B72=06=96=E2=06=16Gf=16=E66R=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=
=06=166R=C46=F7W&=96W"#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3=C4%#=E3=
=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=
=166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04=16=D6=97B=03s=03C=
=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3=C4%#=E56V=
=E7B=02f=E6'7=03=B4=D6=F6=E6F=17=92=C2=04=17=07&=96=C2=03B=C2=03#=
=03=03R=03=93=A3S2=06=16=D3=C4%#=E5F=F2=02f=E6'7=03=B4F=96=D6=97G&=
=92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S=C4%#=
=E462=02f=E6'7=03=B666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C4%#=E4&63=
=C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96=
=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=
=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=04F=96=D6=97G&=92=C3=C4%#=
=E4=92=076=17r=07F=86R=06FWF=16=96=C72=06=D6V=E7F=96=F6=E6VB=06'=92=
=07=96=F7R=06=16&=F7WB=07F=86=972=06=96=E2=06=16=E6=F7F=86W"=06G&=
=16gB=06=16&=F7B=06S&R=07&V6=F7fW'=92=E3=C4%#=E56=F2=07F=86R=04=C55=
=02=06FV=C6WF=96=F6=E2=06=972=06&=176VB=06=F6=E2=05&W&W6=82=06=D6W76=
=16vW2=06=96=E2=07&WfW'6=96=F6=E2=E3=C4%#=E4'WB=07v=86=17B=07v=96=
=C6=C2=06&R=07F=86R=066=176R=06=96=E2=06&V=C6=F7r=0766V=E6=17&=96=
=F73=A3=C4%#=E3=12=E2=06=96b=07F=86W&R=06=972=06=12=06Gv=F6=E77G&V=
=16=D2=06=E6=F6FR=06f=16=96=C72=E2=04=96=E2=07F=86=972=066=176R=07&Vg=
&W6=82=06=D6W76=16vW2=07F=F6=F2=07v=96=C6=C2=06vWB=06=16ffV7FVB=E3=
=C4%#=E3"=E2=06=96b=07F=86R=076=96v=E6=16=C6=96=E6r=06=972=06=96=E2=
=D6&=16=E6B=06=16=E6B=07F=86R=06=F7WF=96b=86=172=04=92=06=D6V=E7F=
=96=F6=E6VB=06=96=E2=06=D7=92=07=07&Wf=96=F7W2=06=D6=16=96=C2=92=06v=
=F6W2=06F=F7v=E2=E2=04=16=E6B=07F=86W&R=06=972=06=E6=F2=06=F7F=86W"=
=06=96=E7FW&f=166R=07F=F2=06vWB=07F=86R=07&V
&W6=82=06=D6W76=16vW2=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5=03=E3=C5T=
=C3=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=
=E4=96=E2=06&=F7F=82=07F=86W6R=0766V=E6=17&=96=F72=C2=06=172=07&Vg&W6=
=82=06F=F6W2=06=E6=F7B=06=86=17=07=06V=E2=C2=07F=86R=04=C55=02=076=
=86=F7V=C6B=06vWB=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=
=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E5=06=
=C7=A2=066=F6=E6f=97&=D2=06=96b=07F=86=972=06=972=07&=96v=87B=E3=C4%#=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=
=06=166R=C46=F7W&=96W"#=E4=F7"=06=17&R=07=96=F7R=06v=F6=96=E6r=07F=
=F2=06F=F2=076=F6=D6R=076V=C6b=D7&Vg&W6=82=06=B6=96=E6B=06=F6b=06f=
=F7"=06=96=E6f=96=E6=97FR=06GW&=17F=96=F6=E2=E3=C4%#=E4GW&=17F=96=
=F6=E2=076=86=F7V=C6B=06&R=06=96=E6f=96=E6=97FR=06=172=07&V6=F7fW'=
=92=06=F6b=06f=16=96=C7W&R=06=D6=17=92=07F=16=B6R=07F=96=D6R=E3=C4%#=
=E5F=86=972=076V=C6b=07&Vg&W6=82=06=86=172=07F=F2=06&R=07F=96=C6=C2=
=06f=16=96=C7W&R=07&V6=F7fW'2=06=F7"=07F=96=C6=C2=07=96=F7R=06=16v=
=16=96=E2=077F=17'B=06vWGF=96=E6r=07F=86R=07&Vg&W6=82=06=D6W76=16vW2=
=E2=04=F7"=07F=86R=057F=17FR=06vWG2=06W=87=06=C6=966=97F=C7=92=06FV=
=C6WFVB=06'=92=06=86V=16B=06V=E6B=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5T=
=C3=E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"=07f=96Wr=
=E3=C4%#=E5F=86=16=E6=B72=06=16=E6B=05&Vv=17&G2=C3=C4%#=E4=16=D6=97B=
=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=
=E6=F77=06=166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04F=96=D6=
=97G&=92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S=
=C4%#=E56V=E7B=02f=E6'7=03=B4g&=96F=17=92=C2=04=17=07&=96=C2=03=12=
=C2=03#=03=03R=03s=A3S=12=07=06=D3=C4%#=E5F=F2=02f=E6'7=03=B4=16=D6=
=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=
=B3=C4%#=E462=02f=E6'7=03=B4F=96=D6=97G&=92=E5=06=17=06=16F=96=D6=
=97G&=96=F7T=06=16=C66=17FV=C2=E6&R=02=C2=0666=16=D7=04=06=F7=072=
=E6=96WFb=E6=F7&s=C4%#=E4&63=C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2=
=05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=
=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6=
=16=D6=97B=C2=07W=06=F6=E2=06
=17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R=07F=86W&R=06=972=06=E6=F2=
=077V6=82=06&V=86=17f=96=F7W"=06=172=07=96=F7R=06=D6V=E7F=96=F6=E2=
=02=D2=06=C6=F66=16=C2=06F=17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R=
=06FWFV7F=96=F6=E2=06F=F6W2=06=E6=F7B=06=96=D7=06=C7=92=077F=17FR=
=06FV=C6WF=96=F6=E2=06=16=E6B=066=F6=D6=D6=F6=E2=05=06=17F=84W'"=F5&W=
7dW'"=06F=F2=06=E6=F7B=07G&=96vvW"=06=16=E7=92=077F=17FR=06FV=C6WF=
=96=F6=E2=06=E6=F7"=06F=F6W2=06=12=04=E6=F7F=96g=93=B2=06=96=E2=07=
=06=17'F=967V=C6=17"=C2=06=96=E2=07F=86R=07=07&W6V=E7B=066=F6=E7FW=
=87B=07v=86W&R=06=F6=E6R=06F=F2=06=1777V=D6R=066=F6=E7G&=F6=C2=07=
=06=C6=16=E6R=06=17f=16=96=C6=16&=96=C6=97G=92=06WfV=E2=06=96=E2=066=
=176R=06=F6b=06F=17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R=02=D2=06=E6=
=F7FS=A2=06FWF=16=96=C72=06=F6b=06=97B=06=17f=16=96=C6=16&=C6R=06=
=96=E2=06=F7F=86W"=06F=F67V=D6V=E7G2=02=D2=077F=17FW2=066=16=E2=06&R=
=06=B6W=07B=07&Vg&W6=86VC=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=
=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=16=D6=97B=
=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3=
=C4%#=E56V=E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6=96WFb=
=E6=F7&s=C4%#=E3=03B=F3=03=12=F3#=03=03R=03=13s=A3S=12=05=A4S=83=C4%#=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=
=06=166R=C46=F7W&=96W"#=E5F=F3=A2=04F=96=D6=97G&=92=05=04=15=04=14D=
=94=D4=95E$=94=F5R=F4$R=F4=14=C44=15DT=C4=04=14=C44=15DT=C3=C4%#=E663=
=A2=0666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C4%#=E6&63=A3=C4%#=E57V&=
=A6V7C=A2=05&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=
=F4=E5C=E3=C4%#=E3=C4%#=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=
=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=C3=C4%#=E5F=86=16=E6=
=B72=06f=F7"=07&W=06=C7=96=96=E6r=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=
=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E4=1666=F7&F=96=E6r=07F=F2=07F=86R=077F=17FV=D6V=E7B=04=92=
=06=D6V=E7F=96=F6=E6VB=06g&=F6=D2=07F=86R=06G&=16gB=C2=04=92=07V=E6FW=
'7F=16=E6B=07F=86=17B=C2=06=96b=07F=86W&R=06=972=06=12=06f=16=96=C7W&=
R=07F=86R=06=F6=C6B=07v=F7&=B6=96=E6r=04=C55=02=076=86=F7V=C6B=06=
=E6=F7B=06&R=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=
=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W
=96W"#=E4'WB=06=E6=F7B=06=F6=E6=C7=92=06f=F7"=05%5e=02=C2=06f=F7"=
=06=16=E7=92=04=D5=04=C52=056=96v=E6=16=C6=96=E6r=07=07&=F7F=F66=F6=
=C2=C2=06=97B=06=972=06=D6=16=E6F=17F=F7'=92=07F=86=17B=07v=86V=E2=
=06=12=06f=16=96=C7W&R=06=86=17=07=06V=E72=C2=07=96=F7R=076=86=F7V=
=C6B=077F=17'B=07FV=17&=96=E6r=06F=F7v=E2=07F=86R=04=C55=02=E3=C4%#=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=
=06=166R=C46=F7W&=96W"#=E5F=16=B6R=06f=F7"=06=96=E77F=16=E66R=06=96b=
=06=12=04=F7WD=96=E7FW&f=166R=86=F6=E2=07v=86=966=82=04=C55=02=06=
=972=076WGW=02=92=06v=F6W2=06F=F7v=E2=E3=C4%#=E5=07&=F7F=F66=F6=C2=
=07v=96=C6=C2=06=C6V=16B=07F=F2=04=C55=02=06FV=C6WF=96=F6=E2=E3=C4%#=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=
=06=166R=C46=F7W&=96W"#=E5=06=C7=A2=066=F7'&V7B=06=D6R=06=96b=04=92=
=06=16=D2=07w&=F6=E6r=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3=
=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=
=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04F=
=96=D6=97G&=92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=
=E6&S=C4%#=E56V=E7B=02f=E6'7=03=B4g&=96F=17=92=C2=04=17=07&=96=C2=
=03=12=C2=03#=03=03R=03S=A3#B=07=06=D3=C4%#=E5F=F2=02f=E6'7=03=B4=
=16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=
=D2fwC=B3=C4%#=E462=02f=E6'7=03=B666=16=D7=04=06=F7=072=E6=96WFb=E6=
=F7&s=C4%#=E4&63=C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2=05&Vv=17&F=96=
=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=
=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6=86=92=02=D2=07v=
=F7V=C6B=07=96=F7R=07=06=C6V=176R=066=C6=17&=96g=92=07=96=F7W"=066=
=F6=D6=D6V=E7B=02=D2=07F=F2=07v=86=966=82=07=06=F7FV=E7F=96=16=C2=
=07f=96=F6=C6=17F=96=F6=E2=06F=F2=07=96=F7R=07&VfW"=03=F2=06=96=E2=
=07=06=17'F=967V=C6=17"=07F=86=972=077=06V6=96f=966=17F=96=F6=E2=06&V=
=96=E6r=06gV=E67F=96=F6=E6=16=C2=077=06V6=96f=962=06FWF=16=96=C72=
=066=F6=E66W&=E6=96=E6r=07&V=16=C6=97=A6=17F=96=F6=E2=07W6=96=E6r=
=05%5e=02=06=17&R=07=07&=F7f=96FVB=06=96=E2=07F=86R=06V=E6B=D7F=F2=
=D6V=E6B=076=96v=E6=16=C6=96=E6r=06F=F67V=D6V=E7C=C4%#=E3=C2=F4d=F4=
=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E4=16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=
=92=E66=F6=D2fw
=B3=C4%#=E56V=E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6=
=96WFb=E6=F7&s=C4%#=E3=03B=F3=03=12=F3#=03=03R=03=13C=A33=92=05=A4S=
=83=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=
=E6=F77=06=166R=C46=F7W&=96W"#=E5F=F3=A2=0666=16=D7=04=06=F7=072=E6=
=96WFb=E6=F7&s=C4%#=E663=A3=C4%#=E6&63=A3=C4%#=E57V&=A6V7C=A2=05&Vv=
=17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=
=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=
=86=92=C3=C4%#=E4=96=E2=07F=86R=06G&=16gB=06G&=16gB=D6=96WFb=D666=
=16=D7=02=D6v=D7=06=C72=D7&V6=F7fW'=92=D6gV=E67F=96=F6=E6=16=C2=D3=
=03B=E7G=87B=C2=06=96=E2=07F=86R=076V7F=96=F6=E2=06=16&=F7WB=05&WfW'6=
=96=F6=E2=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d=
=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=97B=06=972=076=16=
=96C=A3=C4%#=E2g=17V=F7C=B5&WfW'6=96=F6=E2=06=96=D7=06=C6=96W2=07F=
=86=17B=06=12=07v=F7&=B6=96=E6r=07=06=17F=82=07&V=D6=16=96=E72=06=
=16=C6=C6=F66=17FVB=07F=F2=07F=86R=04=C55=02=07F=86=17C=C4%#=E7v=172=
=06=F7&=96v=96=E6=16=C6=C7=92=07&=F7WFVB=06=F7fW"=06=97B=06WfV=E2=
=06=16gFW"=06=12=06f=16=96=C7W&R=E2g=17V=F7C=B3=C4%#=E3=C2=F4d=F4=
=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E5F=86=972=07&W=17V=97&V=D6V=E7B=06=D6=17=92=06=86=F6=C6B=07G'=
VR=06f=F7"=06=E6=F6=E2=D5=0542=06=E6WGv=F7&=B72=C2=06=16=E6B=06=D6=
=17=92=06=E6=F7B=06&R=07&W=17V=97&VB=06=96=E2=05=0542=E3=C4%#=E4=86=
=F7r=066=16=E2=05%5e=02=077W=07=06=F7'B=07F=86=973=F3=F2=04=92=06=
=D6V=16=E2=06=97B=06=D6=17=92=07F=F7F=16=C6=C7=92=07f=96=F6=C6=17FR=
=05%5e=02=D5DR=077F=16=E6F=17&B=E3=C4%#=E4=172=07F=86=F7Vv=82=07F=
=86R=06f=16=96=C7W&R=06=86=172=06=86=17=07=06V=E6VB=06=16=E6B=04=C55=
=02=076=86=F7V=C6B=06=E6=F7B=06&R=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4=
=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"=07f=96Wr=
=06=F6=E2=07F=86=972=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3=C4%#=
=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C2=F5=03=E0


--Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)--



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Apr 2005 07:53:05 +0000
To: Amit 70405 <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Regarding Reversion
Date: Wed, 6 Apr 2005 09:51:19 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+YW1pdCwgPC9QPjxQPnVwb24gY29udHJvbCBwbGFuZSBmYWlsdXJlIHlvdSBhcHBseSB0aGUg
bWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA5IG9mIFJGQyAzNDczIHRoYXQgYWxsb3dz
IHJlY292ZXJ5IHdoZW4gdGhlIGRhdGEgcGxhbmUgaGFzIHJldGFpbmVkIHRoZSBmb3J3YXJkaW5n
IHN0YXRlIGFjcm9zcyBhIHJlc3RhcnQgKHRoaXMgY292ZXJzIHRoZSBjYXNlIHlvdSBtZW50aW9u
IGhlcmUgYmVsb3cgd2hlbiBjb250cm9sIGNoYW5uZWwgaXMgdW5kZXIgZmFpbHVyZSksIGluIGNh
c2Ugb2Ygc291cmNlIG5vZGFsIGZhaWx1cmUgeW91IGFwcGx5IHRoZSBleHRlbmRlZCByZXN0YXJ0
IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gJmx0O2RyYWZ0LWlldGYtY2NhbXAtcnN2cC1yZXN0YXJ0
LWV4dC0wMi50eHQmZ3Q7ID0mZ3Q7IHRoZSBMU1AgaXMgbm90IGRlbGV0ZWQgKGlmIHRoaXMgeW91
ciBxdWVzdGlvbiksIGluIHRoZSBvdGhlciB3YXkgYXJvdW5kIHRoZXJlIGlzIG5vIHNwZWNpZmlj
IGlzc3VlIGFzIHJlc291cmNlcyBhcmUgcmV0YWluZWQgYW5kIHRoZSBMU1AgcmVmcmVzaGVkIHVu
dGlsIGRhdGEgcGxhbmUgZmFpbHVyZSBpcyByZWNvdmVyZWQ8QlI+PEJSPjxGT05UIFNJWkU9Mj48
Qj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05U
IFNJWkU9Mj4wNC8wNi8yMDA1IDEwOjU1IFpFODwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+
VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Y2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj4gPEZP
TlQgU0laRT0yPmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8
Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SZTogUmVnYXJkaW5nIFJl
dmVyc2lvbjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5IaSBBbGwsPEJSPkNhbiBhbnlib2R5IHBseiBjbGFyaWZ5LjxCUj5UaGFua3MgaW4g
YWR2YW5jZS48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5SZWdhcmRz
LDxCUj5BbWl0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5G
cm9tICZuYnNwOyBBbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzxCUj5TZW50ICZu
YnNwO01vbmRheSwgQXByaWwgNCwgMjAwNSA5OjUzIGFtPEJSPlRvICZuYnNwO0RpbWl0cmkuUGFw
YWRpbWl0cmlvdUBhbGNhdGVsLmJlPEJSPkNjICZuYnNwO2NjYW1wQG9wcy5pZXRmLm9yZzxCUj5C
Y2M8QlI+U3ViamVjdCAmbmJzcDtSZTogUmVnYXJkaW5nIFJldmVyc2lvbjxCUj48L0ZPTlQ+PEJS
PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSBEaW1pdHJpLDxCUj5JIHNhdyB0aGUg
ZGV0YWlscyBtZW50aW9uZWQgYnkgeW91IGFib3V0IHRoaXMgaW4gYW5vdGhlciBkcmFmdCBhYm90
IGUyZSByZWNvdmVyeS48QlI+U28gdGhlIExTUCBkZWxldGlvbiBpcyBiYXNlZCBvbiBSZXJlc2gg
bWVzc2FnZXMgaW4gcmV2ZXJzaW9uLjxCUj5CdXQgd2hhdCB3aWxsIGJlIHRoZSBjYXNlIGluIGJl
bG93IHNjZW5hcmlvczo8QlI+MS4gaWYgdGhlcmUgaXMgYSBkd29uc3RyZWFtIG5vZGUgZmFpbHMu
IEluIHRoaXMgY2FzZSByZWZyZXNoIG1lc3NhZ2VzIHRvbyB3aWxsIGdldCBhZmZlY3RlZC48QlI+
Mi4gaWYgdGhlIHNpZ25hbGluZyBpcyBpbi1iYW5kIGFuZCB0aGUgb3V0aWYoYXMgSSBtZW50aW9u
ZWQgaW4gbXkgcHJldmlvdXMgbWFpbCkgZ29lcyBkb3duLiBBbmQgdGhlcmUgaXMgbm8gb3RoZXIg
aW50ZXJmYWNlIHRvIGdldCB0aGUgcmVmcmVzaCBtZXNzYWdlcy48L0ZPTlQ+PEJSPjwvUD48VUw+
PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkluIGJvdGggdGhlc2Ugc2NlbmFyaW9zLCBh
cyByZWZyZXNoIGRvZXMgbm90IGhhcHBlbiwgdGhlIExTUCBzaG91bGQgZ2V0IGRlbGV0ZWQuPEJS
PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlBseiBjb25maXJtIGlm
IHRoaXMgaXMgcmlnaHQuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp
ZXIiPk9yIGFyZSB5b3UgZ29pbmcgdG8gZG8gc29tZSBzZWxmLXJlZnJlc2gga2luZCBvZiBmb3Ig
aW5maW5pdGUgZHVyYXRpb24uPEJSPkR1cmF0aW9uIHNob3VsZCBiZSBpbmZpbml0ZSBhcyByZWNv
dmVyeSBvZiBmYWlsdXJlIG1heSB0YWtlIHRpbWUuPEJSPlRoaXMgc2VsZiByZWZyZXNoIGhhcyB0
byBiZSB0aWxsIGZhaWx1cmUgcmVjb3ZlcnMgb3IgdGlsbCB5b3UgYWdhaW4gc3RhcnQgZ2V0dGlu
ZyB0aGUgcmVmcmVzaCBtZXNzYWdlcy4gT3IgdGhlIFN0YXRlIGdldHMgZXhwbGljaXRseSBkZWxl
dGVkIGJ5IGhlYWQgZW5kLjwvRk9OVD48QlI+PC9VTD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2Us
Q291cmllciI+UGx6IGxldCBtZSBrbm93IHlvdXIgdmlldy48QlI+VGhhbmtzIGFuZCBSZWdhcmRz
LDxCUj5BbWl0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5G
cm9tICZuYnNwOyBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5TZW50ICZuYnNw
O0ZyaWRheSwgQXByaWwgMSwgMjAwNSA3OjUxIHBtPEJSPlRvICZuYnNwO0FtaXQgNzA0MDUgJmx0
O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPkNjICZuYnNwO0RpbWl0cmkuUGFwYWRpbWl0cmlvdUBh
bGNhdGVsLmJlICwgY2NhbXBAb3BzLmlldGYub3JnPEJSPkJjYzxCUj5TdWJqZWN0ICZuYnNwO1Jl
OiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl
LENvdXJpZXIiPmFtaXQsIHVwb24gZGF0YSBwbGFuZSBmYWlsdXJlIHRoZXJlIGlzIG5vIHN1Y2gg
YmVoYXZpb3VyIGFzIHlvdSBtZW50aW9uIC0gbG9jYWwgZGF0YSBwbGFuZSBmYWlsdXJlIGRldGVj
dGlvbiBkb2VzIG5vdCBpbXBseSBzdGF0ZSBkZWxldGlvbiBhbmQgY29tbW9uIFBhdGhFcnIvUmVz
dkVyciBkbyBub3QgdHJpZ2dlciBhbnkgc3RhdGUgZGVsZXRpb24gbm9yIGRvZXMgYSBOb3RpZnk7
IGluIHBhcnRpY3VsYXIsIGluIHRoZSBwcmVzZW50IGNvbnRleHQgd2hlcmUgb25lIGRvIGFzc3Vt
ZSBjb250cm9sIHBsYW5lIGF2YWlsYWJpbGl0eSBldmVuIGluIGNhc2Ugb2YgZGF0YSBwbGFuZSBm
YWlsdXJlIC0gbm90ZTogZGV0YWlscyBvZiBpdCBhdmFpbGFibGUgaW4gb3RoZXIgZG9jdW1lbnRz
IC0gc3RhdGVzIGNhbiBiZSBrZXB0IHJlZnJlc2hlZDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9
Ik1vbm9zcGFjZSxDb3VyaWVyIj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzxC
Uj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+MDQvMDEvMjAwNSAxNzo1MSBa
RTg8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VG86IERpbWl0
cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8QlI+Y2M6IGNjYW1wQG9wcy5pZXRm
Lm9yZzxCUj5iY2M6PEJSPlN1YmplY3Q6IFJlOiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9O
VD48QlI+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhpLDxCUj5U
aGFua3MgZm9yIHJlcGx5aW5nLjxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh
Y2UsQ291cmllciI+QWNjb3JkaW5nIHRvIHRoZSBzdGF0ZW1lbnQgSSBtZW50aW9uZWQgZnJvbSB0
aGUgZHJhZnQsIEkgdW5kZXJzdGFuZCB0aGF0LCBpZiB0aGVyZSBpcyBhIGZhaWx1cmUgdGhlIG9s
ZCB3b3JraW5nIExTUCBzaG91bGQgbm90IGJlIGRlbGV0ZWQuPEJSPjwvRk9OVD48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkJ1dCBub3Qgb25seSBmb3IgUlNWUCwgZm9yIGFueSBN
UExTIFNpZ25hbGluZyBwcm90b2NvbCwgaXQgaXMgbWFuZGF0b3J5IHRoYXQgd2hlbiBhIGZhaWx1
cmUgaGFwcGVucywgeW91IHNob3VsZCBzdGFydCB0ZWFyaW5nIGRvd24gdGhlIExTUC48QlI+PC9G
T05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGFrZSBmb3IgaW5zdGFuY2Ug
aWYgYSBPdXRJbnRlcmZhY2Uob24gd2hpY2ggTFNQIGlzIHNldHVwKSBnb2VzIGRvd24uPEJSPlBy
b3RvY29sIHdpbGwgbGVhZCB0byBMU1AgZGVsZXRpb24uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD
RT0iTW9ub3NwYWNlLENvdXJpZXIiPlBseiBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcuPEJSPlJl
Z2FyZHMsPEJSPkFtaXQuPEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5Gcm9tICZuYnNwOyBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5T
ZW50ICZuYnNwO0ZyaWRheSwgQXByaWwgMSwgMjAwNSA1OjI0IHBtPEJSPlRvICZuYnNwO0FtaXQg
NzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPkNjICZuYnNwO2NjYW1wQG9wcy5pZXRm
Lm9yZzxCUj5CY2M8QlI+U3ViamVjdCAmbmJzcDtSZTogUmVnYXJkaW5nIFJldmVyc2lvbjxCUj48
L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5oaSAtIHdvdWxkIHlvdSBw
bGVhc2UgY2xhcmlmeSB5b3VyIGNvbW1lbnQgLSB0byB3aGljaCBwb3RlbnRpYWwgdmlvbGF0aW9u
IGRvIHlvdSByZWZlciA/IGluIHBhcnRpY3VsYXIgdGhpcyBzcGVjaWZpY2F0aW9uIGJlaW5nIGZ1
bmN0aW9uYWwgc3BlY2lmaWMgZGV0YWlscyBjb25jZXJuaW5nIHJlYWxpemF0aW9uIHVzaW5nIFJT
VlAgYXJlIHByb3ZpZGVkIGluIHRoZSBlbmQtdG8tZW5kIHNpZ25hbGluZyBkb2N1bWVudDxCUj48
L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5BbWl0IDcwNDA1ICZsdDtB
bWl0R0BodWF3ZWkuY29tJmd0OzxCUj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8
QlI+MDQvMDEvMjAwNSAxNDozOSBaRTg8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh
Y2UsQ291cmllciI+VG86IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj5jYzo8QlI+YmNjOjxCUj5TdWJq
ZWN0OiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj5IaSw8QlI+SW4gdGhlIGRyYWZ0IGRyYWZ0LWlldGYtY2NhbXAtZ21w
bHMtcmVjb3ZlcnktZnVuY3Rpb25hbC0wNC50eHQsIGluIHRoZSBzZWN0aW9uIGFib3V0IFJldmVy
c2lvbi48QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkl0
IGlzIHNhaWQ6PEJSPiZxdW90O1JldmVyc2lvbiBpbXBsaWVzIHRoYXQgYSB3b3JraW5nIHBhdGgg
cmVtYWlucyBhbGxvY2F0ZWQgdG8gdGhlIExTUCB0aGF0PEJSPndhcyBvcmlnaW5hbGx5IHJvdXRl
ZCBvdmVyIGl0IGV2ZW4gYWZ0ZXIgYSBmYWlsdXJlLiZxdW90OzxCUj48L0ZPTlQ+PEJSPjxGT05U
IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGlzIHJlcXVpcmVtZW50IG1heSBob2xkIHRydWUg
Zm9yIG5vbi1QU0MgbmV0d29ya3MsIGFuZCBtYXkgbm90IGJlIHJlcXVpcmVkIGluIFBTQy48QlI+
SG93IGNhbiBSU1ZQIHN1cHBvcnQgdGhpcz8/IEkgbWVhbiBpdCBtYXkgdG90YWxseSB2aW9sYXRl
IFJTVlAtVEUgc3RhbmRhcmQuPEJSPkFzIHRob3VnaCB0aGUgZmFpbHVyZSBoYXMgaGFwcGVuZWQg
YW5kIExTUCBzaG91bGQgbm90IGJlIGRlbGV0ZWQuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i
TW9ub3NwYWNlLENvdXJpZXIiPlBseiBsZXQgbWUga25vdyB5b3VyIHZpZXcgb24gdGhpcy48QlI+
UmVnYXJkcyw8QlI+QW1pdC48QlI+PC9GT05UPjxCUj48QlI+PC9QPg==



Envelope-to: [e-mail]
Delivery-date: Wed, 06 Apr 2005 02:56:12 +0000
Date: Wed, 06 Apr 2005 10:55:21 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Regarding Reversion
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi All,
   Can anybody plz clarify.
   Thanks in advance.
Regards,
Amit.

>From   Amit 70405 <[e-mail]>  
Sent  Monday, April 4, 2005 9:53 am 
To  [e-mail]  
Cc  [e-mail]  
Bcc    
Subject  Re: Regarding Reversion 

Hi Dimitri,
   I saw the details mentioned by you about this in another draft abot e2e recovery.
   So the LSP deletion is based on Reresh messages in reversion.
   But what will be the case in below scenarios:
   1. if there is a dwonstream node fails. In this case refresh messages too will get affected.
   2. if the signaling is in-band and the outif(as I mentioned in my previous mail) goes down. And there is no other interface to get the refresh messages.

   In both these scenarios, as refresh does not happen, the LSP should get deleted.

   Plz confirm if this is right.

   Or are you going to do some self-refresh kind of for infinite duration.
   Duration should be infinite as recovery of failure may take time.
   This self refresh has to be till failure recovers or till you again start getting the refresh messages. Or the State gets explicitly deleted by head end.

   Plz let me know your view.
Thanks and Regards,
Amit.

>From   [e-mail]  
Sent  Friday, April 1, 2005 7:51 pm 
To  Amit 70405 <[e-mail]>  
Cc  [e-mail] , [e-mail]  
Bcc    
Subject  Re: Regarding Reversion 

amit, upon data plane failure there is no such behaviour as you mention - local data plane failure detection does not imply state deletion and common PathErr/ResvErr do not trigger any state deletion nor does a Notify; in particular, in the present context where one do assume control plane availability even in case of data plane failure - note: details of it available in other documents - states can be kept refreshed

Amit 70405 <[e-mail]>
Sent by: [e-mail]
04/01/2005 17:51 ZE8

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [e-mail]
bcc: 
Subject: Re: Regarding Reversion




Hi,
Thanks for replying.


According to the statement I mentioned from the draft, I understand that, if there is a failure the old working LSP should not be deleted.

But not only for RSVP, for any MPLS Signaling protocol, it is mandatory that when a failure happens, you should start tearing down the LSP.

Take for instance if a OutInterface(on which LSP is setup) goes down.
Protocol will lead to LSP deletion.

Plz correct me if I am wrong.
Regards,
Amit.

 
>From   [e-mail]  
Sent  Friday, April 1, 2005 5:24 pm 
To  Amit 70405 <[e-mail]>  
Cc  [e-mail]  
Bcc    
Subject  Re: Regarding Reversion 

hi - would you please clarify your comment - to which potential violation do you refer ? in particular this specification being functional specific details concerning realization using RSVP are provided in the end-to-end signaling document

Amit 70405 <[e-mail]>
Sent by: [e-mail]
04/01/2005 14:39 ZE8

To: [e-mail]
cc: 
bcc: 
Subject: Regarding Reversion

 
Hi,
In the draft draft-ietf-ccamp-gmpls-recovery-functional-04.txt, in the section about Reversion.


It is said:
"Reversion implies that a working path remains allocated to the LSP that
was originally routed over it even after a failure."

This requirement may hold true for non-PSC networks, and may not be required in PSC.
How can RSVP support this?? I mean it may totally violate RSVP-TE standard.
As though the failure has happened and LSP should not be deleted.

Plz let me know your view on this.
Regards,
Amit.






Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 21:13:29 +0000
Date: Tue, 5 Apr 2005 14:12:55 -0700 (PDT)
From: Kireeti Kompella <[e-mail]>
To: Adrian Farrel <[e-mail]>
cc: [e-mail]
Subject: Re: Fw: Enforcement of Updated IPR Boilerplate 
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 5 Apr 2005, Adrian Farrel wrote:

> Please be aware and update your new draft submissions accordingly.

For those using xml2rfc, there is a new version that has the new
boilerplate.

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 20:44:03 +0000
Message-ID: <175101c53a1e$dbeed720$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Enforcement of Updated IPR Boilerplate 
Date: Tue, 5 Apr 2005 21:19:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Please be aware and update your new draft submissions accordingly.
Adrian
----- Original Message ----- 
From: "IETF Secretariat" <[e-mail]>
To: "IETF Announcement list" <[e-mail]>
Sent: Monday, April 04, 2005 6:05 PM
Subject: Enforcement of Updated IPR Boilerplate


> As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions,"
> has been obsoleted by RFC 3978 (BCP 78), which was published in March
> 2005, and which bears the same title.  The major difference between the
> two RFCs is that the IPR-related notices and disclaimers that the IETF
> requires in all Internet-Drafts have been updated to correct anomalies.
>
> The updated versions of the required notices and disclaimers are
specified
> in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in
> Section 3, "IPR-Related Notices Required in Internet-Drafts," of the
> recently revised "Guidelines to Authors of Internet-Drafts"
> (http://www.ietf.org/ietf/1id-guidelines.html).  The "Guidelines"
document
> also provides additional guidance regarding the placement of these
notices.
>
> Currently, the IETF Secretariat accepts and posts Internet-Drafts that
> include *either* the RFC 3667 or the RFC 3978 version of these notices.
> However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will
> accept *only* those Internet-Drafts that comply with the requirements
> of RFC 3978, and with the most recent version of the "Guidelines"
> document.
>
> Please note that the required notices and disclaimers must be reproduced
> verbatim since they have been legally reviewed and formally adopted as
part
> of the IETF process.  The Secretariat will not accept deviations from
the
> specified text, nor will it correct the text.  Any documents that do not
> comply with the requirements will be returned to the submitter.
>
> The IETF Secretariat




Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 19:28:10 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
Date: Tue, 05 Apr 2005 15:27:47 -0400

--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		: RSVP-TE Extensions in support of End-to-End Generalized 
			  Multi-Protocol Label Switching (GMPLS)-based Recovery
	Author(s)	: J. Lang, et al.
	Filename	: draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
	Pages		: 36
	Date		: 2005-4-5
	
This document describes protocol specific procedures and extensions 
   for Generalized Multi-Protocol Label Switching (GMPLS) Resource 
   ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to 
   support end-to-end Label Switched Path (LSP) recovery that is 
   protection and restoration. A generic functional description of 
   GMPLS recovery can be found in a companion document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 19:28:03 +0000
Message-ID: <16c901c53a15$10666f40$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Zhang Renhai" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, <[e-mail]>
Subject: Re: WG last calls
Date: Tue, 5 Apr 2005 20:11:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Zhang,

There is certainly nothing to prevent your suggestion.

This would be an implementation choice, although an operator would
probably want to configure identical behavior on all crankback-capable
LSRs in the network.

Adrian
----- Original Message ----- 
From: "Zhang Renhai" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>; <[e-mail]>
Sent: Monday, April 04, 2005 9:51 AM
Subject: Re: WG last calls


> Hi, Adrian
> In RFC 3209,LSP is provided with attribute of  Priority(Setup
Priority,Holding Priority),
> so it is more reasonable to  process different LSPs according to the
Priority, for the LSP
> with higher priority, more retry number should be given, lower priority
with less number.
> Extremely, to the highest LSP, can the interception be concelled by
ABR?(although multi LSPs
> may be derived simultaneously, sellection can be done by egress on
receiving Path massege
> .So we can get another LSP with most possibility because of its highest
priority)
>
> Just my suggestion.
>
> Regard,
> Zhang
>
>
> ----- Original Message ----- 
> From: "Adrian Farrel" <[e-mail]>
> To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>; "Zhang Renhai"
<[e-mail]>; <[e-mail]>; "Kireeti Kompella"
<[e-mail]>
> Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
> Sent: Sunday, April 03, 2005 1:05 AM
> Subject: Re: WG last calls
>
>
> > Hi,
> >
> > Yes, to clarify what Jerry says, the number of crankback attempts MAY
be
> > limited. At the moment, the only way that we provide to limit the
attempts
> > is implemented per LSR. That is, any LSR MAY decide that it has
performed
> > enough attempts at rerouting and pass the error back to the upstream
LSR.
> >
> > Note that the use of crankback to derive a path through a network is
not
> > recommended. This approach is almost equivalent to random walk routing
and
> > is neither efficient nor effective.
> >
> > The use of crankback, as described in the draft is intended for use in
> > specific circumstances, such as inter-domain routing. In these cases
only
> > selective LSRs (such as domain boundaries) perform rerouting attempts.
> >
> > Adrian
> >
> > ----- Original Message ----- 
> > From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
> > To: "Zhang Renhai" <[e-mail]>; "Adrian Farrel"
> > <[e-mail]>; <[e-mail]>; "Kireeti Kompella"
> > <[e-mail]>
> > Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
> > Sent: Friday, April 01, 2005 2:02 PM
> > Subject: RE: WG last calls
> >
> >
> > Zhang,
> >
> > > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the
> > > number of crankback rerouting is limited, so there will
> > > be a result: there is another LSP,but for the reason of
> > > limiting, the path may be not found.  I think sometimes
> > > it is unacceptable.The LSP may be prefered to enhancing
> > > performance.
> >
> > This problem can be avoided by the setting the node retry threshold
> > (configurable per node) very high (~infinity), so retries aren't
> > limited.
> >
> > Thanks,
> > Jerry
> >
> >
> >
> >
>
>
>




Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 19:27:55 +0000
Message-ID: <16bd01c53a15$0b1f92f0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Cc: "Kohei Shiomoto" <[e-mail]>, "'Rajiv Papneja'" <[e-mail]>, "Richard Rabbat" <[e-mail]>
Subject: Interoperability/Addressing Draft - Please read it
Date: Mon, 4 Apr 2005 11:46:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

The editors have produced a new version of this important draft which can
be found at
http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing-01.txt

Please review this revision and send your comments to the list.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Tue, 05 Apr 2005 08:50:26 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Apr 2005 10:48:24 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC: kireeti Kompella <[e-mail]>,  [e-mail],  [e-mail], "[e-mail]" <[e-mail]>
Subject: Re: WG  last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian,

some comments here below on the exclude route i-d

technical
---------

1. section 2.1

  "Constrained Shortest Path First (CSPF) computation at Ingress, so the
    ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, 
AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively."

AB1 should also be excluded as AB2 does not know the first path crosses 
this node so there may be a case (in this example for inst. imagine 
there is no link between AB2 and B3) where this could lead to overlap if 
AB2 selects an area B link to reach AB1

2. section 4

"The exclude route identifies a list of abstract nodes that MUST NOT
    be traversed along the path of the LSP being established."

while section 4.1

" The concept of loose or strict hops has no meaning in route
    exclusion.  The L bit, defined for ERO subobjects in [RSPV-TE], is
    reused here to indicate that an abstract node MUST be avoided (value
    0) or SHOULD be avoided (value 1)."


3. section 4.1

"The subobjects are identical to
    those defined in [RFC3209] and [RFC3473] for use in EROs."

looking at the definitions this is not the case (moreover the SRLG 
subobject has been added) -

4. section 4.1

"  An Attribute octet is introduced in the subobjects that define IP
    addresses to indicate the attribute (e.g.  interface, node, SRLG)
    associated with the IP addresses that can be excluded from the path."

what is a subobject that define IP addresses ?

5. section 4.1

"   For instance, the attribute node allows a whole node to be excluded
    from the path, in contrast to the attribute interface, which allows
    specific interfaces to be excluded from the path. "

but below the definition says "0 indicates that the interface or set of 
interfaces associated with the IP prefix should be excluded or avoided" 
which makes the term specific ambiguous

6. section 4.1.5

"         node

              1 indicates that the node with the Router ID should be
                excluded or avoided (this can be achieved using IPv4/v6
                subobject as well, but is included here because it may be
                convenient to use subobjects from RRO, in specifying the
                exclusions)"

until "(this can be achieved using IPv4/v6 subobject" i understand after 
  i would ask you to clarify i guess you mean RRO from another path ? 
should you include this as part of the definition ?

7. section 4.2 - condition 1. what does happen when the L flag is not 
set and the condition is not verified ?

8. section 4.2 - condition 3. "If they do contradict, the subobjects 
with the L flag not set, strict or MUST be excluded, respectively, in 
the ERO or XRO MUST take precedence." this sentence is cryptic i put in 
the technical part because it impacts understanding concerning the exact 
processing

9. section 4.2 - condition 4. "The number of introduced SLRGs with the L 
flag set to "avoid" should be minimised." i guess you mean wrt to the 
number of "exclude" SRLGs (blocking) ? or is there an absolute 
limitation due to the message size

10. section 4.2 - concerning the operations i would suggesting adding a 
rule suggesting that no contradicting exclusions get inserted

11. section 5.

"The Explicit Exclude Route defines abstract nodes or resources (such
    as links, unnumbered interfaces or labels) that must not be used on
    the path between two inclusive abstract nodes or resources in the
    explicit route."

... "must" while the L bit means either "avoid" or "exclude"

12. section 5.1

"  A new ERO subobject type is defined.  The Explicit Exclude Route
    Subobject (EXRS) has type [TBD].  The EXRS may not be present in an
    RRO or XRO."

would you clarify the meaning of the second sentence in the context of 
the first one ? (note: the doc. since far tells the reader that the EXRS 
is an ERO subobject)

13. section 5.1

"  Note: The Most Significant Bit in the Type field could be used to
    indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating
    the need to prepend the subobject with an additional TLV header.
    This would reduce the number bytes require for each subobject by 2
    bytes.  However, this approach would reduce the ERO Type field space
    by half.  This issue need WG discussion and feedback."

-> i would suggest keeping existing definition (since the EXRS is to 
considered as an optimization), this said better formalization of the 
EXRS subobjects needs to be provided - as the next section mentions 
"Each EXRS may carry multiple exclusions.  The exclusion is encoded 
exactly as for XRO subobjects and prefixed by an additional Type and 
Length." while with the provided alignment it looks like each exclusion 
element is encoded with this double Type/Length field

note that section 5. would probably require a revision after completion 
of the technical details

14. section 6.

"   2.  The EXRS SHOULD be supported.  If supported, the same
        restrictions as for the XRO apply."

-> the EXRS is an optimization it should not be considered as a should 
but optional ie MAY

15. there is nothing said concerning usage of EXRS when using XRO ?

editorial
---------

1. section 2. and onward why referring to a "Explicit Exclude Route" and 
then to a "5.1  Explicit Exclusion Route Subobject (EXRS)" and not a 
"Explicit Exclude Route Subobject (EXRS)" ? -> the document would 
benefit from using a single term either "exclude" or "exclusion"

2. section 2.

"  This subobject might also be appropriate for use within Explicit
    Routes or Record Routes, but that discussion is outside the scope of
    this document."

would suggest replace this sentence with "This document does not assume 
or preclude any other usage for this subobject."

3. section 2. "A new subobject type the Explicit Exclude
        Route Subobject (EXRS) is introduced to indicate an exclusion
        between a pair of included abstract nodes."

would complete the last part of the sentence (as i guess you mean of the 
ERO in the present context)

4. why section 3.1 is defined as "SRLG ERO Subobject" i think this 
should better be defined as an "SRLG Subobject" as i do not see a 
specific reason for having an SRLG subobject outside of the XRO, EXRS 
context ?

5. Section 4.1.x - adapt IP address to IPv4 address when defining the 
IPv4 subobject, etc.

6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID,

7. section 5.1

""Thus, an EXRO subobject for an IP hop might look as follows:..." ?
what do you mean by might ? isn't EXRS instead of EXRO ?

8. section 5.1

"Both subobjects are as described earlier in this document." both (to 
which subobject do you refer here) ?

9 "5.2  Semantics and Processing Rules for the EXRS" -> "5.2 Processing 
Rules for the EXR Subobject and its Subobjects"

10. section 5.2

"If the presence of EXRO Subobjects precludes further forwarding of
    the Path message, the node should return a PathErr with the error
    code "Routing Problem" and error value of "Route blocked by Exclude
    Route"."

you mean EXRS ? instead EXRO ?

11. section 5.2

"If a node is called upon to process an EXRS and does not support
    handling of exclusions it will return a PathErr with a "Bad
    EXPLICIT_ROUTE object" error."

... Routing Problem/Bad EXPLICIT_ROUTE object

note that in general definition of the subobject field could be made a 
bit more explicit


hope these comments will help you

thanks,
- dimitri.



Envelope-to: [e-mail]
Delivery-date: Mon, 04 Apr 2005 22:58:32 +0000
Message-ID: <[e-mail]>
Date: Tue, 05 Apr 2005 00:57:05 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To: Adrian Farrel <[e-mail]>
CC:  [e-mail],  Kireeti Kompella <[e-mail]>, [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail]
Subject: Re: WG last calls - comments on crankback i-d
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian - see in-line for one or two remaining clarifications:

Adrian Farrel wrote:

> Hi Dimitri,
> 
> Thanks for the thorough review.
> 
>> technical ---------
>> 
>> 1. section 2.1
>> 
>> it seems from phrasing the term QoS is used in two different ways
>> 
>> "Using RSVP-TE, resources can also be reserved along a path to
>> guarantee or control QoS for traffic carried on the LSP" thus last
>> part of this sentence refers to the traffic oriented approach (as
>> detailed in RFC 2702) but after in this section (and in section
>> 4.2) the term "QoS constraints" is used in a resource oriented
>> perspective;
> 
> Point taken. This needs to be clarified.
> 
> 
>> 2. section 2.2
>> 
>> " The requirement for end-to-end allocation of lambda resources in 
>> GMPLS networks without wavelength converters means that end-to-end 
>> restoration is the only way to recover LSP failures. "
>> 
>> -> would it be possible to know how you came to this statement ?
> 
> Yes. Actually, it should read "may be the only way". Simply put,
> segment protection may be much harder in networks of photonic
> cross-connects because a particular lambda may already be in use on
> other links. End-to-end protection offers the choice of use of
> another lambda, but this choice is not available in segment
> protection.
> 
>> 3. section 3.
>> 
>> I may have missed it but the definition of "Explicit and Implicit 
>> Re-routing Indications" is not provided
> 
> The first paragraph was intended to convey this. We will clarify.
> 
>> 4. section 4.2.1
>> 
>> not sure to see why the "reason" of the failure is important beside
>> link, label, etc. (in particular since the persistence is limited
>> to the LSP under establishmnet) - but i guess it depends on the
>> semantic you put behind this word in the present context -
> 
> OK. It would probably help if we gave an example and a counter
> example.
> 
> Off the top of my head: "temporary control plane congestion" has a
> different impact on crankback rerouting to "cannot route to
> destination".
> 
>> also by context you mean "position" of the element under failure
>> wrt to its sequence as part of the ERO ?
> 
> Yeah. I don't think either of us has the right word here. We'll try
> to find something that explains this a bit better.
> 
>> 5. section 4.4
>> 
>> is it " error indication upstream" or indicationS (collection) ?
> 
> Hmmm. One error indication (message) may report multiple errors. We
> will clarify this by inserting the word "message".
> 
>> 6. section 5.2
>> 
>> "The Notify message may be used to expedite the propagation of
>> error notifications, but in a network that offers crankback routing
>> at multiple nodes there would need to be some agreement between
>> LSRs as to whether PathErr or Notify provides the stimulus for
>> crankback operation. "
>> 
>> this agreement is constrained by the re-routing behavior selection
>> (as listed in section 6.4
> 
> Yes. That would be a helpful cross-reference.
> 
>> 7. section 6.4
>> 
>> point 2 - why segment-based is referred to as "hierarchical" - do
>> you refer to an "horizontal hierarchy" here ?)
> 
> Probably best if we remove this word because it has overloaded
> semantics with respect to hierarchical LSPs. What we meant is simply
> that segment based protection allows you to protect ever smaller
> segments in a nested way. For example...
> 
> A--B--C--D--E--F--G--H
>    |  |  |  |  |  |
>    |  |  P--Q  |  |
>    |  R----S---T  |
>    W----X----Y----Z 

-> ok - i would refer to this as "nested crankback"

>> 8. section 7.2
>> 
>> not sure to understand the "Proposed ERO" TLV ? would it be
>> possible to describe this more than "MAY supply suggestions about
>> the ERO that could have been used to avoid the error."
> 
> Intention is to allow a downstream LSR to report that "I cannot route
> using the supplied ERO, but if you had supplied *this* ERO it would have
> been possible."
>  
>> not sure to understand the "ERO_NEXT_CONTEXT" TLV
> 
> Both of these TLVs are described a bit further in 7.3.4. However, on
> re-reading I see that there isn't enough information. The distinction
> between TLVs 12 and 13 is the distinction between "this is the hop I was
> trying to satisfy when I failed" and "this is the next hop I was trying
> to reach when I failed".
> 
>> " Link Identifiers:
>> 
>> A sequence of TLVs as defined here of type 3 that indicate incoming
>> interfaces at downstream nodes that have already participated in
>> crankback attempts and have been declared unusable for the current
>> LSP setup attempt."
>> 
>> -> definition does not match the one proposed above in the text
>> 
>> " For types 1, 2 and 3 the format of the Value field is already 
>> defined in [RFC3471]."
> 
> 
> Not sure what you are saying. Are you simply suggesting that the
> defintion of the Value for type 27 should point to 3471?

-> i mean that the encoding is borrowed from [RFC3471] but not the 
definition since pointing to "incoming interface at downstream node"
(which is the RFC3209 definition taken from ERO construction) and not 
the corr. definition of [RFC3473] "Data channels are specified from the 
viewpoint of the sender of the Path message".

>> 9. section 7.4.1
>> 
>> " As described in section 3, a node receiving crankback information
>> in a PathErr must first check to see whether it is allowed to
>> perform re-routing. This is indicated by the Re-routing Flags in
>> the SESSION_ATTRIBUTE object during LSP setup request."
>> 
>> -> why do you make use of the session attribute since section 6.4 
>> mentions usage of lsp attribute object
> 
> Good catch! Old text that should be replaced with LSP ATTRIBUTE.
> 
>> 10. section 7.3
>> 
>> in section 7.3.1 it is mentioned
>> 
>> " If crankback is not being used but an IF-ID ERROR_SPEC object is 
>> included in a PathErr, ResvErr or Notify message, the sender SHOULD
>>  include one of the TLVs of type 1 through 3 as described in 
>> [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in 
>> [BUNDLE] and component links should be identified using the 
>> principles described in that document.
>> 
>> A sender MAY include additional TLVs from the range 6 through 27 to
>> report crankback information, although this information will at 
>> most only be used for logging."
>> 
>> [...]
>> 
>> "An LSR that proposes to perform crankback re-routing SHOULD 
>> support receipt and processing of all of the fundamental crankback 
>> TLVs, and is RECOMMENDED to support the receipt and processing of 
>> the additional crankback TLVs."
>> 
>> in section 7.3.2 it is mentioned
>> 
>> " Error Report TLVs are those in the range 1 through 3. (Note that 
>> the obsoleted TLVs 4 and 5 may be considered in this category, but 
>> SHOULD NOT be used.)
>> 
>> As stated above, when crankback information is reported, the IF_ID 
>> ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
>>  used, at least one of the TLVs in the range 1 through 3 MUST be 
>> present. The choice of which TLV to use will be dependent on the 
>> circumstance of the error and device capabilities. For example, a 
>> device that does not support IPv6 will not need the ability to 
>> create a TLV of type 2. Note, however, that such a device MUST
>> still be prepared to receive and process all error report TLVs."
>> 
>> in section 7.3.4 it is mentioned
>> 
>> " It is left as an implementation detail precisely when to include
>> each of the TLVs according to the capabilities of the system
>> reporting the error."
>> 
>> => would it be possible to harmonize these MUST, SHOULD, MAY, etc;
>> ? one way to achieve this is by reducing repetitions and probably
>> have 2 sub-sections instead of 4
> 
> Yes.
> 
>> same comment in section 7.4.5 where it is mentioned
>> 
>> "When the node gives up it must propagate the failure message
>> further upstream and include crankback information when it does
>> so."
> 
> Same answer.
> 
>> 11. section 8.
>> 
>> " For example, when an intermediate LSR issues a PathErr message,
>> the signaling module of the intermediate LSR should interact with
>> the routing logic to determine the routing-protocol-specific link
>> or node ID where the blockage or fault occurred and carry this
>> information onto the Link TLV and Node TLV inside the IF_ID
>> ERROR_SPEC object."
>> 
>> -> Link TLV is not defined as part of the table ? would it be
>> possible to list to which TLV you are referring to
> 
> Yes. Means TLV 1, 2 or 3.
> 
>> 12. section 9.1
>> 
>> " In a network segmented into areas, the following procedures can
>> be used. As explained in Section 8.2, the LSP restoration behavior
>> is indicated in the Flags field of the SESSION_ATTRIBUTE object of
>> the Path message. If the Flags indicate "End-to-end re-routing",
>> the PathErr message is returned all the way back to the ingress
>> LSR, which may then issue a new Path message along another path,
>> which is the same procedure as in the flat network case above."
>> 
>> -> why do you make use of the session attribute since section 6.4 
>> mentions usage of lsp attribute object
> 
> Ditto, above.
> 
>> editorial ---------
>> 
>> 1. title
>> 
>> "Crankback Signaling Extensions for MPLS and GMPLS Signaling"
>> 
>> is probably redundant i would suggest (but leave this at your
>> discretion)
>> 
>> "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"
> 
> OK
> 
>> 2. section 2.2
>> 
>> alignment with P&R terminology and concepts would be advisable 
>> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt>
> 
> OK. Anything specific or do we just need to do a general parse?

-> adapt terminology (use the term protecting instead of backup, use the 
term protected or working instead of primary, etc.) and concepts (e.g. 
prefer the term "recovery" rather than restoration in the sentence "... 
various restoration schemes for link or node failures ..."; prefer the 
term "re-routing" rather than restoration in the sentence "... and 
include fast restoration.", etc.)

>> 3. section 4.2
>> 
>> "On the other hand, in a network partitioned into areas such as
>> with hierarchical OSPF,..."
>> 
>> why "hierarchical OSPF" and not simply "OSPF"
> 
> Because we like adding the word "hierarchical" at every oportunity
> :-)
> 
>> 4. section 5. - point 3)
>> 
>> instead of "... (particularly in the GMPLS context),"
>> 
>> I guess you mean for non-PSC LSP ?
> 
> You guess correctly. Will tidy this.
> 
>> 5. section 7.2
>> 
>> "IF_ID PHOP" -> IF_ID RSVP_HOP ?
> 
> Yes.
> 
>> 6. section 7.2
>> 
>> " Node Identifiers:
>> 
>> A sequence of TLVs as defined here of types 1, 2 or 8 that 
>> indicates downstream nodes that have already participated in 
>> crankback attempts and have been declared unusable for the current
>> LSP setup attempt."
>> 
>> type 1, 2 does not define nodes in the proposed table ?
> 
> Not sure about this. Your point is valid, but it is also the case
> that  one may identify a node by one of its interfaces. Thus it may be
> convenient to simply put the list of failed interfaces into this TLV and
> thus identify the list of nodes that have failed to perform crankback.
> 
> I guess we need a little input from the implementers on this point.

-> you would need feedback from people having implemented this with 
numbered i/fs (from my side, crankback has been experimented for 
unnumbered id) but this is indeed a common trick - so you would probably 
need to insert a hint here -

>> 7. section 8
>> 
>> " The ingress LSR, upon receiving the error message, should
>> interact with the routing logic to compute an alternate path by
>> pruning the specified link ID or node ID in the routing database."
>> 
>> i guess "node ID" refers to Router ID ?
> 
> Well, "TE Router ID". And, of course, "Routing database" should read
> "Traffic Engineering  Database".
> 
>> also do no provide the exact pointer for TE Router ID and Router ID
>> in the IS-IS context
> 
> Yup. I think by using TE Router ID we are covered in the IS-IS case,
> and we just need to update the text to identify the exact field.
> 
>> hope this will help
> 
> 
> It does, a lot.
> 
> Thanks, Adrian



Envelope-to: [e-mail]
Delivery-date: Mon, 04 Apr 2005 10:32:19 +0000
Message-ID: <165f01c53901$9fa68c90$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: "Kireeti Kompella" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: WG last calls - comments on crankback i-d
Date: Sun, 3 Apr 2005 08:40:32 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_161D_01C53828.CC72F3A0"

This is a multi-part message in MIME format.

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

Hi Dimitri,

Thanks for the thorough review.

> technical
> ---------
>=20
> 1. section 2.1
>=20
> it seems from phrasing the term QoS is used in two different ways
>=20
> "Using RSVP-TE, resources can also be reserved along a path to =
guarantee
>   or control QoS for traffic carried on the LSP" thus last part of =
this=20
> sentence refers to the traffic oriented approach (as detailed in RFC=20
> 2702) but after in this section (and in section 4.2) the term "QoS=20
> constraints" is used in a resource oriented perspective;

Point taken. This needs to be clarified.

> 2. section 2.2
>=20
> " The requirement for end-to-end allocation of lambda resources in
>     GMPLS networks without wavelength converters means that end-to-end
>     restoration is the only way to recover LSP failures. "
>=20
> -> would it be possible to know how you came to this statement ?

Yes.
Actually, it should read "may be the only way".
Simply put, segment protection may be much harder in networks of =
photonic cross-connects because a particular lambda may already be in =
use on other links. End-to-end protection offers the choice of use of =
another lambda, but this choice is not available in segment protection.
=20
> 3. section 3.
>=20
> I may have missed it but the definition of "Explicit and Implicit=20
> Re-routing Indications" is not provided

The first paragraph was intended to convey this. We will clarify.

> 4. section 4.2.1
>=20
> not sure to see why the "reason" of the failure is important beside=20
> link, label, etc. (in particular since the persistence is limited to =
the=20
> LSP under establishmnet) - but i guess it depends on the semantic you=20
> put behind this word in the present context -

OK. It would probably help if we gave an example and a counter example.

Off the top of my head: "temporary control plane congestion" has a =
different impact on crankback rerouting to "cannot route to =
destination".

> also by context you mean "position" of the element under failure wrt =
to=20
> its sequence as part of the ERO ?

Yeah. I don't think either of us has the right word here. We'll try to =
find something that explains this a bit better.

> 5. section 4.4
>=20
> is it " error indication upstream" or indicationS (collection) ?

Hmmm.
One error indication (message) may report multiple errors.
We will clarify this by inserting the word "message".

> 6. section 5.2
>=20
> "The Notify
>     message may be used to expedite the propagation of error
>     notifications, but in a network that offers crankback routing at
>     multiple nodes there would need to be some agreement between LSRs
>     as to whether PathErr or Notify provides the stimulus for =
crankback
>     operation. "
>=20
> this agreement is constrained by the re-routing behavior selection (as =

> listed in section 6.4

Yes. That would be a helpful cross-reference.

> 7. section 6.4
>=20
> point 2 - why segment-based is referred to as "hierarchical" - do you=20
> refer to an "horizontal hierarchy" here ?)

Probably best if we remove this word because it has overloaded semantics =
with respect to hierarchical LSPs.
What we meant is simply that segment based protection allows you to =
protect ever smaller segments in a nested way. For example...


A--B--C--D--E--F--G--H
   |  |  |  |  |  |
   |  |  P--Q  |  |
   |  R----S---T  |
   W----X----Y----Z=20


> 8. section 7.2
>=20
> not sure to understand the "Proposed ERO" TLV ? would it be possible =
to=20
> describe this more than "MAY supply suggestions about the ERO that =
could=20
> have been used to avoid the error."

Intention is to allow a downstream LSR to report that "I cannot route =
using the supplied ERO, but if you had supplied *this* ERO it would have =
been possible."

> not sure to understand the "ERO_NEXT_CONTEXT" TLV

Both of these TLVs are described a bit further in 7.3.4. However, on =
re-reading I see that there isn't enough information. The distinction =
between TLVs 12 and 13 is the distinction between "this is the hop I was =
trying to satisfy when I failed" and "this is the next hop I was trying =
to reach when I failed".

> " Link Identifiers:
>=20
>            A sequence of TLVs as defined here of type 3 that indicate
>            incoming interfaces at downstream nodes that have already
>            participated in crankback attempts and have been declared
>            unusable for the current LSP setup attempt."
>=20
> -> definition does not match the one proposed above in the text
>=20
> "   For types 1, 2 and 3 the format of the Value field is already=20
> defined in [RFC3471]."

Not sure what you are saying. Are you simply suggesting that the =
defintion of the Value for type 27 should point to 3471?

> 9. section 7.4.1
>=20
> "   As described in section 3, a node receiving crankback information =
in
>     a PathErr must first check to see whether it is allowed to perform
>     re-routing. This is indicated by the Re-routing Flags in the
>     SESSION_ATTRIBUTE object during LSP setup request."
>=20
> -> why do you make use of the session attribute since section 6.4=20
> mentions usage of lsp attribute object

Good catch!
Old text that should be replaced with LSP ATTRIBUTE.

> 10. section 7.3
>=20
> in section 7.3.1 it is mentioned
>=20
>   "  If crankback is not being used but an IF-ID ERROR_SPEC object is
>     included in a PathErr, ResvErr or Notify message, the sender =
SHOULD
>     include one of the TLVs of type 1 through 3 as described in
>     [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in
>     [BUNDLE] and component links should be identified using the
>     principles described in that document.
>=20
>     A sender MAY include additional TLVs from the range 6 through 27
>     to report crankback information, although this information will at
>     most only be used for logging."
>=20
> [...]
>=20
>    "An LSR that proposes to perform crankback re-routing SHOULD
>     support receipt and processing of all of the fundamental crankback
>     TLVs, and is RECOMMENDED to support the receipt and processing of
>     the additional crankback TLVs."
>=20
> in section 7.3.2 it is mentioned
>=20
> " Error Report TLVs are those in the range 1 through 3. (Note that
>     the obsoleted TLVs 4 and 5 may be considered in this category, but
>     SHOULD NOT be used.)
>=20
>     As stated above, when crankback information is reported, the IF_ID
>     ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object =
is
>     used, at least one of the TLVs in the range 1 through 3 MUST be
>     present. The choice of which TLV to use will be dependent on the
>     circumstance of the error and device capabilities. For example, a
>     device that does not support IPv6 will not need the ability to
>     create a TLV of type 2. Note, however, that such a device MUST =
still
>     be prepared to receive and process all error report TLVs."
>=20
> in section 7.3.4 it is mentioned
>=20
> " It is left as an implementation detail precisely when to include =
each
>     of the TLVs according to the capabilities of the system reporting =
the
>     error."
>=20
> =3D> would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? =
one=20
> way to achieve this is by reducing repetitions and probably have 2=20
> sub-sections instead of 4

Yes.

> same comment in section 7.4.5 where it is mentioned
>=20
> "When the node gives up it must propagate
>     the failure message further upstream and include crankback
>     information when it does so."

Same answer.

> 11. section 8.
>=20
>    " For example, when an intermediate LSR issues a PathErr message, =
the
>     signaling module of the intermediate LSR should interact with the
>     routing logic to determine the routing-protocol-specific link or =
node
>     ID where the blockage or fault occurred and carry this information
>     onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC =
object."
>=20
> -> Link TLV is not defined as part of the table ? would it be possible =

> to list to which TLV you are referring to

Yes. Means TLV 1, 2 or 3.

> 12. section 9.1
>=20
> "   In a network segmented into areas, the following procedures can be
>     used. As explained in Section 8.2, the LSP restoration behavior is
>     indicated in the Flags field of the SESSION_ATTRIBUTE object of =
the
>     Path message. If the Flags indicate "End-to-end re-routing", the
>     PathErr message is returned all the way back to the ingress LSR,
>     which may then issue a new Path message along another path, which =
is
>     the same procedure as in the flat network case above."
>=20
> -> why do you make use of the session attribute since section 6.4=20
> mentions usage of lsp attribute object

Ditto, above.

> editorial
> ---------
>=20
> 1. title
>=20
> "Crankback Signaling Extensions for MPLS and GMPLS Signaling"
>=20
> is probably redundant i would suggest (but leave this at your =
discretion)
>=20
> "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"

OK

> 2. section 2.2
>=20
> alignment with P&R terminology and concepts would be advisable
> =
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-term=
inology-06.txt>

OK. Anything specific or do we just need to do a general parse?

> 3. section 4.2
>=20
> "On the other hand, in a network partitioned into areas such as with
>     hierarchical OSPF,..."
>=20
> why "hierarchical OSPF" and not simply "OSPF"

Because we like adding the word "hierarchical" at every oportunity :-)

> 4. section 5. - point 3)
>=20
> instead of "... (particularly in the GMPLS context),"
>=20
> I guess you mean for non-PSC LSP ?

You guess correctly. Will tidy this.

> 5. section 7.2
>=20
> "IF_ID PHOP" -> IF_ID RSVP_HOP ?

Yes.

> 6. section 7.2
>=20
>        " Node Identifiers:
>=20
>            A sequence of TLVs as defined here of types 1, 2 or 8 that
>            indicates downstream nodes that have already participated =
in
>            crankback attempts and have been declared unusable for the
>            current LSP setup attempt."
>=20
> type 1, 2 does not define nodes in the proposed table ?

Not sure about this. Your point is valid, but it is also the case that =
one may identify a node by one of its interfaces. Thus it may be =
convenient to simply put the list of failed interfaces into this TLV and =
thus identify the list of nodes that have failed to perform crankback.

I guess we need a little input from the implementers on this point.

> 7. section 8
>=20
> "  The ingress LSR, upon receiving the error message, should interact
>     with the routing logic to compute an alternate path by pruning the
>     specified link ID or node ID in the routing database."
>=20
> i guess "node ID" refers to Router ID ?

Well, "TE Router ID".
And, of course, "Routing database" should read "Traffic Engineering =
Database".

> also do no provide the exact pointer for TE Router ID and Router ID in =

> the IS-IS context

Yup. I think by using TE Router ID we are covered in the IS-IS case, and =
we just need to update the text to identify the exact field.

> hope this will help

It does, a lot.

Thanks,
Adrian

------=_NextPart_000_161D_01C53828.CC72F3A0
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>Hi Dimitri,</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Thanks for the thorough =
review.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; technical<BR>&gt; =
---------<BR>&gt; <BR>&gt;=20
1. section 2.1<BR>&gt; <BR>&gt; it seems from phrasing the term QoS is =
used in=20
two different ways<BR>&gt; <BR>&gt; "Using RSVP-TE, resources can also =
be=20
reserved along a path to guarantee<BR>&gt; &nbsp; or control QoS for =
traffic=20
carried on the LSP" thus last part of this <BR>&gt; sentence refers to =
the=20
traffic oriented approach (as detailed in RFC <BR>&gt; 2702) but after =
in this=20
section (and in section 4.2) the term "QoS <BR>&gt; constraints" is used =
in a=20
resource oriented perspective;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Point taken. This needs to be=20
clarified.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&gt; 2. section 2.2<BR>&gt; =
<BR>&gt; " The=20
requirement for end-to-end allocation of lambda resources in<BR>&gt;=20
&nbsp;&nbsp;&nbsp; GMPLS networks without wavelength converters means =
that=20
end-to-end<BR>&gt; &nbsp;&nbsp;&nbsp; restoration is the only way to =
recover LSP=20
failures. "<BR>&gt; <BR>&gt; -&gt; would it be possible to know how you =
came to=20
this statement ?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Yes.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Actually, it should read "may be the =
only=20
way".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Simply put, segment protection may be =
much harder=20
in networks of photonic cross-connects because&nbsp;a particular lambda =
may=20
already be in use on other links. End-to-end protection offers the =
choice of use=20
of another lambda, but this choice is not available in segment=20
protection.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;<BR>&gt; 3. section 3.<BR>&gt;=20
<BR>&gt;&nbsp;I may have missed it but the definition of "Explicit and =
Implicit=20
<BR>&gt; Re-routing Indications" is not provided</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>The first paragraph was intended to =
convey this.=20
We will clarify.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>&gt; 4. section 4.2.1<BR>&gt; =
<BR>&gt; not=20
sure to see why the "reason" of the failure is important beside <BR>&gt; =
link,=20
label, etc. (in particular since the persistence is limited to the =
<BR>&gt; LSP=20
under establishmnet) - but i guess it depends on the semantic you =
<BR>&gt; put=20
behind this word in the present context -</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>OK. It would probably help if we gave =
an example=20
and a counter example.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Off the top of my head: "temporary =
control plane=20
congestion" has a different impact on crankback rerouting to "cannot =
route to=20
destination".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; also by context you mean =
"position" of the=20
element under failure wrt to <BR>&gt; its sequence as part of the ERO=20
?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Yeah. I don't think either of us has =
the right=20
word here. We'll try to find something that explains this a bit=20
better.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; 5. section 4.4<BR>&gt; <BR>&gt; =
is it "=20
error indication upstream" or indicationS (collection) ?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Hmmm.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>One error indication (message) may =
report=20
multiple errors.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>We will clarify this by inserting the =
word=20
"message".</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; 6. section 5.2<BR>&gt; <BR>&gt; =
"The=20
Notify<BR>&gt; &nbsp;&nbsp;&nbsp; message may be used to expedite the=20
propagation of error<BR>&gt; &nbsp;&nbsp;&nbsp; notifications, but in a =
network=20
that offers crankback routing at<BR>&gt; &nbsp;&nbsp;&nbsp; multiple =
nodes there=20
would need to be some agreement between LSRs<BR>&gt; &nbsp;&nbsp;&nbsp; =
as to=20
whether PathErr or Notify provides the stimulus for crankback<BR>&gt;=20
&nbsp;&nbsp;&nbsp; operation. "<BR>&gt; <BR>&gt; this agreement is =
constrained=20
by the re-routing behavior selection (as <BR>&gt; listed in section=20
6.4</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Yes. That would be a helpful=20
cross-reference.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT><BR><FONT face=3DCourier =
size=3D2>&gt; 7.=20
section 6.4<BR>&gt; <BR>&gt; point 2 - why segment-based is referred to =
as=20
"hierarchical" - do you <BR>&gt; refer to an "horizontal hierarchy" here =

?)</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Probably best if we remove this word =
because it=20
has overloaded semantics with respect to hierarchical LSPs.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>What we meant is simply that segment =
based=20
protection allows you to protect ever smaller segments in a nested way. =
For=20
example...</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></FONT><FONT face=3DCourier=20
size=3D2>A--B--C--D--E--F--G--H</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;|&nbsp; |&nbsp; =
|&nbsp; |&nbsp;=20
|&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier =
size=3D2>&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;|&nbsp; P--Q&nbsp;=20
|&nbsp; |</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;|&nbsp; =
R----S---T&nbsp;=20
|</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;&nbsp;&nbsp;W----X----Y----Z =
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV><FONT =
face=3DCourier=20
size=3D2></FONT>
<DIV><BR><FONT face=3DCourier size=3D2>&gt; 8. section 7.2<BR>&gt; =
<BR>&gt; not sure=20
to understand the "Proposed ERO" TLV ? would it be possible to <BR>&gt; =
describe=20
this more than "MAY supply suggestions about the ERO that could <BR>&gt; =
have=20
been used to avoid the error."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Intention is to allow a downstream =
LSR to report=20
that "I cannot route using the supplied ERO, but if you had supplied =
*this* ERO=20
it would have been possible."</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>&gt; not sure to understand the=20
"ERO_NEXT_CONTEXT" TLV</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>Both of these TLVs are described a =
bit further in=20
7.3.4. However, on re-reading I see that there isn't enough information. =
The=20
distinction between TLVs 12 and 13 is the distinction between "this is =
the hop I=20
was trying to satisfy when I failed" and "this is the next hop I was =
trying to=20
reach when I failed".</DIV>
<DIV><BR>&gt; " Link Identifiers:<BR>&gt; <BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A sequence =
of TLVs=20
as defined here of type 3 that indicate<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; incoming =
interfaces=20
at downstream nodes that have already<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
participated in=20
crankback attempts and have been declared<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unusable =
for the=20
current LSP setup attempt."<BR>&gt; <BR>&gt; -&gt; definition does not =
match the=20
one proposed above in the text<BR>&gt; <BR>&gt; "&nbsp;&nbsp; For types =
1, 2 and=20
3 the format of the Value field is already <BR>&gt; defined in =
[RFC3471]."</DIV>
<DIV>&nbsp;</DIV>
<DIV>Not sure what you are saying. Are you simply suggesting that the =
defintion=20
of the Value for type 27 should point to 3471?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 9. section 7.4.1<BR>&gt; <BR>&gt; "&nbsp;&nbsp; As described =
in=20
section 3, a node receiving crankback information in<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
a PathErr must first check to see whether it is allowed to =
perform<BR>&gt;=20
&nbsp;&nbsp;&nbsp; re-routing. This is indicated by the Re-routing Flags =
in=20
the<BR>&gt; &nbsp;&nbsp;&nbsp; SESSION_ATTRIBUTE object during LSP setup =

request."<BR>&gt; <BR>&gt; -&gt; why do you make use of the session =
attribute=20
since section 6.4 <BR>&gt; mentions usage of lsp attribute object</DIV>
<DIV>&nbsp;</DIV>
<DIV>Good catch!</DIV>
<DIV>Old text that should be replaced with LSP ATTRIBUTE.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 10. section 7.3<BR>&gt; <BR>&gt; in section 7.3.1 it is=20
mentioned<BR>&gt; <BR>&gt; &nbsp; "&nbsp; If crankback is not being used =
but an=20
IF-ID ERROR_SPEC object is<BR>&gt; &nbsp;&nbsp;&nbsp; included in a =
PathErr,=20
ResvErr or Notify message, the sender SHOULD<BR>&gt; &nbsp;&nbsp;&nbsp; =
include=20
one of the TLVs of type 1 through 3 as described in<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
[RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described =
in<BR>&gt;=20
&nbsp;&nbsp;&nbsp; [BUNDLE] and component links should be identified =
using=20
the<BR>&gt; &nbsp;&nbsp;&nbsp; principles described in that =
document.<BR>&gt;=20
<BR>&gt; &nbsp;&nbsp;&nbsp; A sender MAY include additional TLVs from =
the range=20
6 through 27<BR>&gt; &nbsp;&nbsp;&nbsp; to report crankback information, =

although this information will at<BR>&gt; &nbsp;&nbsp;&nbsp; most only =
be used=20
for logging."<BR>&gt; <BR>&gt; [...]<BR>&gt; <BR>&gt; &nbsp;&nbsp; "An =
LSR that=20
proposes to perform crankback re-routing SHOULD<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
support receipt and processing of all of the fundamental =
crankback<BR>&gt;=20
&nbsp;&nbsp;&nbsp; TLVs, and is RECOMMENDED to support the receipt and=20
processing of<BR>&gt; &nbsp;&nbsp;&nbsp; the additional crankback =
TLVs."<BR>&gt;=20
<BR>&gt; in section 7.3.2 it is mentioned<BR>&gt; <BR>&gt; " Error =
Report TLVs=20
are those in the range 1 through 3. (Note that<BR>&gt; =
&nbsp;&nbsp;&nbsp; the=20
obsoleted TLVs 4 and 5 may be considered in this category, but<BR>&gt;=20
&nbsp;&nbsp;&nbsp; SHOULD NOT be used.)<BR>&gt; <BR>&gt; =
&nbsp;&nbsp;&nbsp; As=20
stated above, when crankback information is reported, the IF_ID<BR>&gt;=20
&nbsp;&nbsp;&nbsp; ERROR_SPEC object MUST be used. When the IF_ID =
ERROR_SPEC=20
object is<BR>&gt; &nbsp;&nbsp;&nbsp; used, at least one of the TLVs in =
the range=20
1 through 3 MUST be<BR>&gt; &nbsp;&nbsp;&nbsp; present. The choice of =
which TLV=20
to use will be dependent on the<BR>&gt; &nbsp;&nbsp;&nbsp; circumstance =
of the=20
error and device capabilities. For example, a<BR>&gt; &nbsp;&nbsp;&nbsp; =
device=20
that does not support IPv6 will not need the ability to<BR>&gt;=20
&nbsp;&nbsp;&nbsp; create a TLV of type 2. Note, however, that such a =
device=20
MUST still<BR>&gt; &nbsp;&nbsp;&nbsp; be prepared to receive and process =
all=20
error report TLVs."<BR>&gt; <BR>&gt; in section 7.3.4 it is =
mentioned<BR>&gt;=20
<BR>&gt; " It is left as an implementation detail precisely when to =
include=20
each<BR>&gt; &nbsp;&nbsp;&nbsp; of the TLVs according to the =
capabilities of the=20
system reporting the<BR>&gt; &nbsp;&nbsp;&nbsp; error."<BR>&gt; <BR>&gt; =
=3D&gt;=20
would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? one =
<BR>&gt;=20
way to achieve this is by reducing repetitions and probably have 2 =
<BR>&gt;=20
sub-sections instead of 4</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes.</DIV>
<DIV><BR>&gt; same comment in section 7.4.5 where it is =
mentioned<BR>&gt;=20
<BR>&gt; "When the node gives up it must propagate<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
the failure message further upstream and include crankback<BR>&gt;=20
&nbsp;&nbsp;&nbsp; information when it does so."</DIV>
<DIV>&nbsp;</DIV>
<DIV>Same answer.</DIV>
<DIV><BR>&gt; 11. section 8.<BR>&gt; <BR>&gt; &nbsp;&nbsp; " For =
example, when=20
an intermediate LSR issues a PathErr message, the<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
signaling module of the intermediate LSR should interact with =
the<BR>&gt;=20
&nbsp;&nbsp;&nbsp; routing logic to determine the =
routing-protocol-specific link=20
or node<BR>&gt; &nbsp;&nbsp;&nbsp; ID where the blockage or fault =
occurred and=20
carry this information<BR>&gt; &nbsp;&nbsp;&nbsp; onto the Link TLV and =
Node TLV=20
inside the IF_ID ERROR_SPEC object."<BR>&gt; <BR>&gt; -&gt; Link TLV is =
not=20
defined as part of the table ? would it be possible <BR>&gt; to list to =
which=20
TLV you are referring to</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes. Means TLV 1, 2 or 3.</DIV>
<DIV><BR>&gt; 12. section 9.1<BR>&gt; <BR>&gt; "&nbsp;&nbsp; In a =
network=20
segmented into areas, the following procedures can be<BR>&gt; =
&nbsp;&nbsp;&nbsp;=20
used. As explained in Section 8.2, the LSP restoration behavior =
is<BR>&gt;=20
&nbsp;&nbsp;&nbsp; indicated in the Flags field of the SESSION_ATTRIBUTE =
object=20
of the<BR>&gt; &nbsp;&nbsp;&nbsp; Path message. If the Flags indicate=20
"End-to-end re-routing", the<BR>&gt; &nbsp;&nbsp;&nbsp; PathErr message =
is=20
returned all the way back to the ingress LSR,<BR>&gt; &nbsp;&nbsp;&nbsp; =
which=20
may then issue a new Path message along another path, which is<BR>&gt;=20
&nbsp;&nbsp;&nbsp; the same procedure as in the flat network case=20
above."<BR>&gt; <BR>&gt; -&gt; why do you make use of the session =
attribute=20
since section 6.4 <BR>&gt; mentions usage of lsp attribute object</DIV>
<DIV>&nbsp;</DIV>
<DIV>Ditto, above.</DIV>
<DIV><BR>&gt; editorial<BR>&gt; ---------<BR>&gt; <BR>&gt; 1. =
title<BR>&gt;=20
<BR>&gt; "Crankback Signaling Extensions for MPLS and GMPLS =
Signaling"<BR>&gt;=20
<BR>&gt; is probably redundant i would suggest (but leave this at your=20
discretion)<BR>&gt; <BR>&gt; "Crankback Signaling Extensions for MPLS =
and GMPLS=20
RSVP-TE"</DIV>
<DIV>&nbsp;</DIV>
<DIV>OK</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 2. section 2.2<BR>&gt; <BR>&gt; alignment with P&amp;R =
terminology and=20
concepts would be advisable<BR>&gt; &lt;</FONT><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recove=
ry-terminology-06.txt"><FONT=20
face=3DCourier=20
size=3D2>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recov=
ery-terminology-06.txt</FONT></A><FONT=20
face=3DCourier size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DCourier size=3D2>OK. Anything specific or do we just =
need to do a=20
general parse?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>&nbsp;</DIV>
<DIV>&gt; 3. section 4.2<BR>&gt; <BR>&gt; "On the other hand, in a =
network=20
partitioned into areas such as with<BR>&gt; &nbsp;&nbsp;&nbsp; =
hierarchical=20
OSPF,..."<BR>&gt; <BR>&gt; why "hierarchical OSPF" and not simply =
"OSPF"</DIV>
<DIV>&nbsp;</DIV>
<DIV>Because we like adding the word "hierarchical" at every oportunity=20
:-)</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 4. section 5. - point 3)<BR>&gt; <BR>&gt; instead of "...=20
(particularly in the GMPLS context),"<BR>&gt; <BR>&gt;&nbsp;I guess you =
mean for=20
non-PSC LSP ?</DIV>
<DIV>&nbsp;</DIV>
<DIV>You guess correctly. Will tidy this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; 5. section 7.2<BR>&gt; <BR>&gt; "IF_ID PHOP" -&gt; IF_ID =
RSVP_HOP=20
?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes.</DIV>
<DIV><BR>&gt; 6. section 7.2<BR>&gt; <BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; " Node Identifiers:<BR>&gt; =
<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A sequence =
of TLVs=20
as defined here of types 1, 2 or 8 that<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicates=20
downstream nodes that have already participated in<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; crankback =
attempts=20
and have been declared unusable for the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current LSP =
setup=20
attempt."<BR>&gt; <BR>&gt; type 1, 2 does not define nodes in the =
proposed table=20
?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Not sure about this. Your point is valid, but it is also the case =
that one=20
may identify a node by one of its interfaces. Thus it may be convenient =
to=20
simply put the list of failed interfaces into this TLV and thus identify =
the=20
list of nodes that have failed to perform crankback.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I guess we need a little input from the implementers on this=20
point.<BR><BR>&gt; 7. section 8<BR>&gt; <BR>&gt; "&nbsp; The ingress =
LSR, upon=20
receiving the error message, should interact<BR>&gt; &nbsp;&nbsp;&nbsp; =
with the=20
routing logic to compute an alternate path by pruning the<BR>&gt;=20
&nbsp;&nbsp;&nbsp; specified link ID or node ID in the routing=20
database."<BR>&gt; <BR>&gt; i guess "node ID" refers to Router ID =
?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Well, "TE Router ID".</DIV>
<DIV>And, of course, "Routing database" should read "Traffic Engineering =

Database".</DIV>
<DIV><BR>&gt; also do no provide the exact pointer for TE Router ID and =
Router=20
ID in <BR>&gt; the IS-IS context</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yup. I think by using TE Router ID we are covered in the IS-IS =
case, and we=20
just need to update the text to identify the exact field.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&gt; hope this will help</DIV>
<DIV>&nbsp;</DIV>
<DIV>It does, a lot.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Adrian</DIV>
<DIV></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_161D_01C53828.CC72F3A0--




Envelope-to: [e-mail]
Delivery-date: Mon, 04 Apr 2005 09:18:08 +0000
Date: Mon, 04 Apr 2005 16:51:03 +0800
From: Zhang Renhai <[e-mail]>
Subject: Re: WG last calls
To: Adrian Farrel <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, [e-mail]
Message-id: <00a901c538f3$71e26d00$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi, Adrian 
In RFC 3209,LSP is provided with attribute of  Priority(Setup Priority,Holding Priority),
so it is more reasonable to  process different LSPs according to the Priority, for the LSP
with higher priority, more retry number should be given, lower priority with less number.
Extremely, to the highest LSP, can the interception be concelled by ABR?(although multi LSPs
may be derived simultaneously, sellection can be done by egress on receiving Path massege
.So we can get another LSP with most possibility because of its highest priority)

Just my suggestion.

Regard,
Zhang


----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>; "Zhang Renhai" <[e-mail]>; <[e-mail]>; "Kireeti Kompella" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
Sent: Sunday, April 03, 2005 1:05 AM
Subject: Re: WG last calls


> Hi,
> 
> Yes, to clarify what Jerry says, the number of crankback attempts MAY be
> limited. At the moment, the only way that we provide to limit the attempts
> is implemented per LSR. That is, any LSR MAY decide that it has performed
> enough attempts at rerouting and pass the error back to the upstream LSR.
> 
> Note that the use of crankback to derive a path through a network is not
> recommended. This approach is almost equivalent to random walk routing and
> is neither efficient nor effective.
> 
> The use of crankback, as described in the draft is intended for use in
> specific circumstances, such as inter-domain routing. In these cases only
> selective LSRs (such as domain boundaries) perform rerouting attempts.
> 
> Adrian
> 
> ----- Original Message ----- 
> From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
> To: "Zhang Renhai" <[e-mail]>; "Adrian Farrel"
> <[e-mail]>; <[e-mail]>; "Kireeti Kompella"
> <[e-mail]>
> Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
> Sent: Friday, April 01, 2005 2:02 PM
> Subject: RE: WG last calls
> 
> 
> Zhang,
> 
> > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the
> > number of crankback rerouting is limited, so there will
> > be a result: there is another LSP,but for the reason of
> > limiting, the path may be not found.  I think sometimes
> > it is unacceptable.The LSP may be prefered to enhancing
> > performance.
> 
> This problem can be avoided by the setting the node retry threshold
> (configurable per node) very high (~infinity), so retries aren't
> limited.
> 
> Thanks,
> Jerry
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Mon, 04 Apr 2005 01:56:03 +0000
Date: Mon, 04 Apr 2005 09:53:25 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Regarding Reversion
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)"
Content-language: en

This is a multi-part message in MIME format.

--Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi Dimitri,
   I saw the details mentioned by you about this in another draft abot e2e recovery.
   So the LSP deletion is based on Reresh messages in reversion.
   But what will be the case in below scenarios:
   1. if there is a dwonstream node fails. In this case refresh messages too will get affected.
   2. if the signaling is in-band and the outif(as I mentioned in my previous mail) goes down. And there is no other interface to get the refresh messages.

   In both these scenarios, as refresh does not happen, the LSP should get deleted.

   Plz confirm if this is right.

   Or are you going to do some self-refresh kind of for infinite duration.
   Duration should be infinite as recovery of failure may take time.
   This self refresh has to be till failure recovers or till you again start getting the refresh messages. Or the State gets explicitly deleted by head end.

   Plz let me know your view.
Thanks and Regards,
Amit.

--Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)
Content-type: message/rfc822
Content-disposition: inline

MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: QUOTED-PRINTABLE

=B9=EF=D0=C48=D0=B5=DB=9E=85=0F=AD4=E3]=80=F4=10=B5=DB=9E=85=0F=AD4=
=E3]=81=EB=C9=DE=B5=FA=DA=95=C6=ADzW=EB0=83=04=BD=EA=EC=8A=89=F5=D0=
=C2=0C=12=F7=AB=B2*'=D7@=A8=9E=D7=A7=B6=DC=A9z=D7=B1=B7=F8m=9AW!j=
=BB=1E=B4=84;=CF9=F7P=A8=9E=D7=A7=B6=DA=DA=9E=C7=DE=AD=E9=DC=A1=D8=
=A7=81=B6=AC{=AE=170=83=04N=B6=9C=91'=AB=89=A9b=CD=E6=F2F=8B=ADz=BA'=
=04C=00 =BD9=FC=11?=00=B0=80LB=D1zW=9A=B1=EEt=D7a=C5=EF=CF=12z=9B^=
=99=B7=AB=DB}=B4=D3=86=AD=D3=8F=F4=D7=FD=B4=D3=9Dw=E7^t>=B7=9Cy=D7=
=A7q=E6=EE=96E=C0=95=C6=A7z=D3=13=02=C7=1A=9Ew=9DjwZ=BA=D8h=AE,=DEw'=
=AC]*Z=98(^rG=ABU=EA=EC=8A=89=D2=A5=A9=80=B2=C6=AC=B2)=F7=D3]=B4=D3=
=8Dt=DBj'=A6=C8=1C=A2e=D2=A5=A9=8Bz=F7=A5]*Z=99+Z=B6=EB
=A2=C7(=AD=ED=EE=B7=AA=BA*=DEw=9D=B5=EB-=B0=05,=10=18=11-=B4=1D3=0B=
=E3Nt=1D3=0B0D=92=00a=07L=C2=CC =C1
8t=CC-0=060=83=04=04=04=84=EB=84=C4]3=080A=D30=B3=8D-=83ND@=0B4=03=
=04j=EBh=95=E6=AB=9Ez=BD=EA=EC=8A=89=DFMO=14=0F=8F=11=93=D3=95=08=
=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F=98[Z]=0B=
=08=1D\=1B=DB=88=19=18]=18H=1C=1B=18[=99H=19=98Z[=1D\=99H=1D=1A=19\=
=99H=1A\=C8=1B=9B=C8=1C=DDX=DA=08=18=99Z=18]=9A[=DD\=88=18\=C8=1E[=
=DDH=1BY[=9D=1A[=DB=88=0BH=1B=1B=D8=D8[=08=19=18]=18H=1C=1B=18[=99H=
=19=98Z[=1D\=99H=19=19]=19X=DD=1A[=DB=88=19=1B=D9\=C8=1B=9B=DD=08=
=1A[\=1B=1EH=1C=DD=18]=19H=19=19[=19]=1A[=DB=88=18[=99=08=18=DB=DB[[=
=DB=88=14=18]=1A=11\=9C=8B=D4=99\=DD=91\=9C=88=19=1B=C8=1B=9B=DD=08=
=1D=1C=9AY=D9=D9\=88=18[=9EH=1C=DD=18]=19H=19=19[=19]=1A[=DB=88=1B=
=9B=DC=88=19=1B=D9\=C8=18H=13=9B=DD=1AY=9EN=C8=1A[=88=1C=18\=9D=1AX=
=DD[=18\=8B=08=1A[=88=1D=1A=19H=1C=1C=99\=D9[=9D=08=18=DB=DB=9D=19^=
=1D=08=1D=DA=19\=99H=1B=DB=99H=19=1B=C8=18\=DC=DD[YH=18=DB=DB=9D=1C=
=9B=DB=08=1C=1B=18[=99H=18]=98Z[=18X=9A[=1A]=1EH=19]=99[=88=1A[=88=
=18=D8\=D9H=1B=D9=88=19=18]=18H=1C=1B=18[=99H=19=98Z[=1D\=99H=0BH=
=1B=9B=DD=19N=88=19=19]=18Z[=1C=C8=1B=D9=88=1A]=08=18]=98Z[=18X=9B=
=19H=1A[=88=1B=DD=1A=19\=88=19=1B=D8=DD[Y[=9D=1C=C8=0BH=1C=DD=18]=
=19\=C8=18=D8[=88=18=99H=1A=D9\=1D=08=1C=99Y=9C=99\=DA=19Y=0F=0B=D1=
=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11=93=D3=95=08=14=D2V=91OL=
=8F=8F=10=8F=90[Z]=08
=CC
=0C
H=09=9B=1D=0E=D0[Z]=11=D0=1A=1DX]=D9ZK=98=DB=DBI=99=DD=0E=CF=0B=D0=
=8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=11=93=D3=95=08=14=D2V=91OL=
=8F=94=D9[=9D=08=18=9EN=88=1B=DD=DB=99\=8BX=D8=D8[\=10=1B=DC=1C=CB=
=9AY]=19=8B=9B=DC=99=CF=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=11=93=D3=
=95=08=14=D2V=91OL=8F=8C
=0B=CC=0CK=CC=8C=0C
H=0CM=CE=8DLH=16=91N=0F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=
=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=95=1B=CE=8F=0B=D1=93=D3=95=0F=
=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=91=1A[Z]=1C=9AH=14=10T=10Q=12SRU=
=14=92S=D5K=D0=91K=D0S=10=D0U=11S=10=10S=10=D0U=11S=0F=0B=D1=93=D3=
=95=0F=8F=10=94=8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=D8=CE=8F=
=0B=D1=93=D3=95=0F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=D8=D8[\=
=10=1B=DC=1C=CB=9AY]=19=8B=9B=DC=99=CF=0B=D1=93=D3=95=0F=8F=10=94=
=8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=98=D8=CE=8F=0B=D1=93=D3=
=95=0F=88=0F=10=94=8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=94=DDX=9A=
=99X=DD=0E=8F=0B=D1=93=D3=95=0F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=
=94=99N=88=14=99Y=D8\=99=1A[=99=C8=14=99]=99\=9C=DA[=DB=8F=0B=D1=93=
=D3=95=0F=8F=10=94=8F=88=0F=10=94=8F=8F=10=94=8F=8F=0B=D4=0F=8F=14=
=0F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=
=9AY\=88=8F=92=1AK=0F=10=94=8F=95=1A=18[=9A=DC=C8=19=9B=DC=88=1C=99\=
=1B=1EZ[=99=CB=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=0B=D4=0F=8F=15S=
=0F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=
=9AY\=88=8F=90X=D8=DB=DC=99=1A[=99=C8=1D=1B=C8=1D=1A=19H=1C=DD=18]=
=19[Y[=9D=08=12H=1BY[=9D=1A[=DB=99Y=08=19=9C=9B=DBH=1D=1A=19H=19=1C=
=98Y=9D=0B=08=12H=1D[=99=19\=9C=DD=18[=99=08=1D=1A=18]=0B=08=1AY=88=
=1D=1A=19\=99H=1A\=C8=18H=19=98Z[=1D\=99H=1D=1A=19H=1B=DB=19=08=1D=
=DB=DC=9A=DA[=99=C8=13=14=D4=08=1C=DA=1B=DD[=19=08=1B=9B=DD=08=18=
=99H=19=19[=19]=19Y=0B=8F=10=94=8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=
=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=
=88=8F=90=9D]=08=1B=9B=DD=08=1B=DB=9B=1EH=19=9B=DC=88=14=94=D5=94=
=0B=08=19=9B=DC=88=18[=9EH=13T=13=14=C8=14=DAY=DB=98[=1A[=99=C8=1C=
=1C=9B=DD=1B=D8=DB=DB=0B=08=1A]=08=1A\=C8=1BX[=99=18]=1B=DC=9EH=1D=
=1A=18]=08=1D=DA=19[=88=18H=19=98Z[=1D\=99H=1A=18\=1C=19[=9C=CB=08=
=1E[=DDH=1C=DA=1B=DD[=19=08=1C=DD=18\=9D=08=1D=19X\=9A[=99=C8=19=1B=
=DD=DB=88=1D=1A=19H=13=14=D4=0B=8F=10=94=8F=8F=0B=D1=93=D3=95=0F=8F=
=10=94=8F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=
=DB=DD\=9AY\=88=8F=95=18Z=D9H=19=9B=DC=88=1A[=9C=DD=18[=98=D9H=1AY=
=88=18H=13=DD]=12[=9D=19\=99=98X=D9J=1B=DB=88=1D=DA=1AX=DA=08=13=14=
=D4=08=1A\=C8=1C=D9]=1D\
H=19=DB=D9\=C8=19=1B=DD=DB=8B=8F=10=94=8F=94=1C=9B=DD=1B=D8=DB=DB=
=08=1D=DA[=1B=08=1B=19XY=08=1D=1B=C8=13=14=D4=08=19=19[=19]=1A[=DB=
=8B=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=0B=D5S=0F=8F=14=0F=8F=11=93=
=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F=
=94=1B=1E=88=18=DB=DC=9C=99X=DD=08=1BYH=1AY=88=12H=18[H=1D=DC=9B=DB=
=99=CB=8F=10=94=8F=94=99Y=D8\=99=1C=CB=0F=10=94=8F=90[Z]=0B=8F=10=
=94=8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11=93=D3=95=
=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F=90=DB=
=DB=9D=19[=9D=0B]=1C=98[=9C=D9=99\=8BY[=98=DB=D9=1A[=99=CE=88=14US=
=D5=11Q=0BT=14=92S=95=10P=93=11O=10=94=8F=93RSQK]=99\=9C=DA[=DB=8E=
=88=0CK=8C=0F=10=94=8F=90=DB=DB=9D=19[=9D=0B]=1E\=19N=88=15=11V=15=
=0B=D4=13=10RS=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11=
=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=
=8F=89=9C=18\=98N=C6=8A=C9=CD=C9=88=CD=8C=CD=8D=0C=0E=C9=91XX=DD]=
=19N=C9=99][[=0E=C5=D2=A5=89=98=9C=9D=98=98\=8E=CF=10=94=8F=85=E7=
=09=C9=99X=DA\=98=CE=C9=93=DD=1A[=19=19N=DE=89=9C=98\][=CE=C9=9C][=
=DD=0E=C9=98=D9[=9D=0E=DD=09=98=DB=DC=1EN=DA=98=0B=09=9C=1B=1D\=DB[=
=8E=C9=9B=18\][=CE=CB"=9FI=9B=D8=DA\=98=CE=C9=9D=1A[Y\=CE=DBM=09=98]=
=1A[=19=19N=D7M=89=95XX=DD]=19N=E2I=99XX=DD]=19N=C9=9C=DD\=0C=8E=C1=
=CA&]=09=98=DB=DC=1EN=DA=98=89=95=12=13=D4=93=8E=C9=99=9C=98X=CCL=
=8E=C9=99XX=DD]=19N=D5=D2=A5=89=98=9C=9D=98=98\=8E=D2=89=93=DD[[=0E=
=C9=9C=DA=1EN=C9=9B=DC=99=1BN=C9=90]=1A[=19=19N=DA=09=9C=1B=1D\=DB[=
=8E=C9=91X=DA\=98=CE=CA=DE=D7=C9=9C=DA=1EN=C9=99X=DA\=98=CE=C9=9C=
=99Y=CE=E2=89=9BZY=19=1B=DD=0E=C9=88=CD=8C=CD=8D=0C=0E=C9=98=D8=D9Y=
=1A[=0E=D2=DE=89=91][[=0E=DB=00X=81=01=81=12=D3A=D3=09=90X=DA\=98=
=CE=C9=9B=DD[[=0E=C9=93=D8X=DD]=19N=DFA=D3=09=90X=DA\=98=CE=C9=92Y=
=DC=98]=99N=C4I =06=10I=93=D8X=DD]=19N=CC=09=9C=DD\=0C=CE=C2=0C=10=
=D3=87L=C2=D3=00c=08=09=90XX=DD]=19N=C0@HN=89=98XX=DD]=19N=CCE=D3=
=09=90X=DA\=98=CE=C3=04=1D=09=92Y=DC=98]=99N=CB=09=98]=1A[=19=19N=
=D2=D8=09=93=D8X=DD]=19N=C9=C4=00=89=92XX=DD]=19N=CF=10=94=8F=89=90X=
=DA\=98=CE=CF=10=94=8F=8F=10=94=8F=84=81=05=C1=C9=9C][=DD=0E=CF=10=
=94=8F=88=CF=10=94=8F=8F=10=94=8F=94=8F=10=94=8F=84=D0=C9=9C=1B=DD[=
=99=0E=C8=E0=C9=9C=1B=DD[=99=0E=D0=D0=80=89=9C=DD\=0C=CE=CF=10=94=
=8F=A0=CF=10=94=8F=8F=10=94=8F=89=90][[=0E=C9H=C9=98][[=0E=D9=C9=98[\=
=0E=C9=9B=DD[[=0E=C9=93=D8X=DD]=19N=C9=98=D9[=9D=0E=C1=05=89=93=DD[[=
=0E=E5=D0=8F=10=94=8F=9C=CF=10=94=8F=90=CF=10=94=8F=94=80=99=89=90=
=D8=D9Y=1A[=0E=D0=C9=98X=DD]=19N=C5=89=93=DD[[=0E=E5=D1=1D=01=A1=D5=
=85=DD=95=89=C9=98Y[=1AY=CE=CD=89=9B=DD[[=0E=C9=93=D9=DC=98]=99N=D9=
=9D=D0=C9=9C=DD\=0C=CE=C9=90][[=0E=C9H=C9=98\=9A[
=CE=CD=D5=89=98[\=0E=C9=98=9C=9D=98=98\=8E=D5=8D=D0=C9=98=D9[=9D=0E=
=C1I=98[\=0E=D5=9D=85=C9=98[\=0E=D1=A5=89=98Y[=1AY=CE=DC=81I=98[\=
=0E=D5=D9=95=C9=CD=A5=89=9B=DD[[=0E=C9=98]=1A[=19=19N=C9=90][[=0E=
=C9H=C9=98\=9A[=99=CE=D1=89=9B=D8X=DD]=19N=C9=98=D9[=9D=0E=C1=89=98[\=
=0E=C5=89=90Q[=1AY=CE=C4=89=98=D8=D9Y=1A[=0E=C9=98[\=0E=C5=89=98=9C=
=9D=98=98\=8E=C5=9D=89=99=1A]=9AY=19N=C1=85=89=90Q[=1AY=CE=C5=89=98][=
[=0E=C1=A5=89=98=D8=D9Y=1A[=0E=D1=95=89=90X=DA\=98=CE=C9=98Y[=1AY=
=CE=CD=89=9B=DD[[=0E=C9=93=D9=DC=98]=99N=C9=90X=DA\=98=CE=C1=91=A5=
=89=93=DD[[=0E=E5=D1=C9=98[\=0E=C9=C9=98=D8=D9Y=1A[=0E=C1=85=C1=85=
=91=A5=89=93=DD[[=0E=E5=D1=C9=98[\=0E=E5=89=99=1A]=9AY=19N=D5=01=85=
=89=90Q[=1AY=CE=CD=85=D1=95=89=90X=DA\=98=CE=C9=98Y[=1AY=CE=C9=98[\=
=0E=D4=C9=90][[=0E=C9H=C9=98][[=0E=CD=8C=C9=98=D9[=9D=0E=C1=8D=8D=
=85=89=9D=1A[Y\=CE=C1=01=A5=95=D1=98=89=98Y[=1AY=CE=C9=99=1A]=9AY=
=19N=C9=98[\=0E=DC=C9=90][[=0E=C9H=C9=98][[=0E=C9=93=DD[[=0E=D5=CD=
=CD=85=9D=94=89=93=DD[[=0E=E5=90=C9=98=D9[=9D=0E=C0=99=89=90=D8=D9Y=
=1A[=0E=D0=C9=9C=DD\=0C=CE=C4=C8=D1=90=DC=E0=E0=C4=C8=D1=98=C9=98[\=
=0E=D9=98=89=98]=1A[=19=19N=C4=C8=D1=98=C9=98[\=0E=D9=98=C4=C8=D1=
=90=DC=E0=CF=0B=D1=93=D3=95=0F=8F=0B


--Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)--



Envelope-to: [e-mail]
Delivery-date: Sat, 02 Apr 2005 18:14:21 +0000
Message-ID: <15e901c537af$d846cbd0$dccb2bd4@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>, "Zhang Renhai" <[e-mail]>, <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
Subject: Re: WG last calls
Date: Sat, 2 Apr 2005 18:05:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

Yes, to clarify what Jerry says, the number of crankback attempts MAY be
limited. At the moment, the only way that we provide to limit the attempts
is implemented per LSR. That is, any LSR MAY decide that it has performed
enough attempts at rerouting and pass the error back to the upstream LSR.

Note that the use of crankback to derive a path through a network is not
recommended. This approach is almost equivalent to random walk routing and
is neither efficient nor effective.

The use of crankback, as described in the draft is intended for use in
specific circumstances, such as inter-domain routing. In these cases only
selective LSRs (such as domain boundaries) perform rerouting attempts.

Adrian

----- Original Message ----- 
From: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
To: "Zhang Renhai" <[e-mail]>; "Adrian Farrel"
<[e-mail]>; <[e-mail]>; "Kireeti Kompella"
<[e-mail]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[e-mail]>
Sent: Friday, April 01, 2005 2:02 PM
Subject: RE: WG last calls


Zhang,

> From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the
> number of crankback rerouting is limited, so there will
> be a result: there is another LSP,but for the reason of
> limiting, the path may be not found.  I think sometimes
> it is unacceptable.The LSP may be prefered to enhancing
> performance.

This problem can be avoided by the setting the node retry threshold
(configurable per node) very high (~infinity), so retries aren't
limited.

Thanks,
Jerry






Envelope-to: [e-mail]
Delivery-date: Sat, 02 Apr 2005 17:28:19 +0000
Message-ID: <[e-mail]>
Date: Sat, 02 Apr 2005 19:25:31 +0200
From: dimitri papadimitriou <[e-mail]>
Reply-To:  [e-mail],  [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319
MIME-Version: 1.0
To:  [e-mail]
CC: Kireeti Kompella <[e-mail]>,  [e-mail],  [e-mail],  [e-mail],  [e-mail],  [e-mail]
Subject: Re: WG last calls - comments on crankback i-d
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

hi adrian,

some coments here below

technical
---------

1. section 2.1

it seems from phrasing the term QoS is used in two different ways

"Using RSVP-TE, resources can also be reserved along a path to guarantee
  or control QoS for traffic carried on the LSP" thus last part of this 
sentence refers to the traffic oriented approach (as detailed in RFC 
2702) but after in this section (and in section 4.2) the term "QoS 
constraints" is used in a resource oriented perspective;

2. section 2.2

" The requirement for end-to-end allocation of lambda resources in
    GMPLS networks without wavelength converters means that end-to-end
    restoration is the only way to recover LSP failures. "

-> would it be possible to know how you came to this statement ?

3. section 3.

i may have missed it but the definition of "Explicit and Implicit 
Re-routing Indications" is not provided

4. section 4.2.1

not sure to see why the "reason" of the failure is important beside 
link, label, etc. (in particular since the persistence is limited to the 
LSP under establishmnet) - but i guess it depends on the semantic you 
put behind this word in the present context -

also by context you mean "position" of the element under failure wrt to 
its sequence as part of the ERO ?

5. section 4.4

is it " error indication upstream" or indicationS (collection) ?

6. section 5.2

"The Notify
    message may be used to expedite the propagation of error
    notifications, but in a network that offers crankback routing at
    multiple nodes there would need to be some agreement between LSRs
    as to whether PathErr or Notify provides the stimulus for crankback
    operation. "

this agreement is constrained by the re-routing behavior selection (as 
listed in section 6.4

7. section 6.4

point 2 - why segment-based is referred to as "hierarchical" - do you 
refer to an "horizontal hierarchy" here ?)

8. section 7.2

not sure to understand the "Proposed ERO" TLV ? would it be possible to 
describe this more than "MAY supply suggestions about the ERO that could 
have been used to avoid the error."

not sure to understand the "ERO_NEXT_CONTEXT" TLV

" Link Identifiers:

           A sequence of TLVs as defined here of type 3 that indicate
           incoming interfaces at downstream nodes that have already
           participated in crankback attempts and have been declared
           unusable for the current LSP setup attempt."

-> definition does not match the one proposed above in the text

"   For types 1, 2 and 3 the format of the Value field is already 
defined in [RFC3471]."

9. section 7.4.1

"   As described in section 3, a node receiving crankback information in
    a PathErr must first check to see whether it is allowed to perform
    re-routing. This is indicated by the Re-routing Flags in the
    SESSION_ATTRIBUTE object during LSP setup request."

-> why do you make use of the session attribute since section 6.4 
mentions usage of lsp attribute object

10. section 7.3

in section 7.3.1 it is mentioned

  "  If crankback is not being used but an IF-ID ERROR_SPEC object is
    included in a PathErr, ResvErr or Notify message, the sender SHOULD
    include one of the TLVs of type 1 through 3 as described in
    [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in
    [BUNDLE] and component links should be identified using the
    principles described in that document.

    A sender MAY include additional TLVs from the range 6 through 27
    to report crankback information, although this information will at
    most only be used for logging."

[...]

   "An LSR that proposes to perform crankback re-routing SHOULD
    support receipt and processing of all of the fundamental crankback
    TLVs, and is RECOMMENDED to support the receipt and processing of
    the additional crankback TLVs."

in section 7.3.2 it is mentioned

" Error Report TLVs are those in the range 1 through 3. (Note that
    the obsoleted TLVs 4 and 5 may be considered in this category, but
    SHOULD NOT be used.)

    As stated above, when crankback information is reported, the IF_ID
    ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is
    used, at least one of the TLVs in the range 1 through 3 MUST be
    present. The choice of which TLV to use will be dependent on the
    circumstance of the error and device capabilities. For example, a
    device that does not support IPv6 will not need the ability to
    create a TLV of type 2. Note, however, that such a device MUST still
    be prepared to receive and process all error report TLVs."

in section 7.3.4 it is mentioned

" It is left as an implementation detail precisely when to include each
    of the TLVs according to the capabilities of the system reporting the
    error."

=> would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? one 
way to achieve this is by reducing repetitions and probably have 2 
sub-sections instead of 4


same comment in section 7.4.5 where it is mentioned

"When the node gives up it must propagate
    the failure message further upstream and include crankback
    information when it does so."

11. section 8.

   " For example, when an intermediate LSR issues a PathErr message, the
    signaling module of the intermediate LSR should interact with the
    routing logic to determine the routing-protocol-specific link or node
    ID where the blockage or fault occurred and carry this information
    onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC object."

-> Link TLV is not defined as part of the table ? would it be possible 
to list to which TLV you are referring to

12. section 9.1

"   In a network segmented into areas, the following procedures can be
    used. As explained in Section 8.2, the LSP restoration behavior is
    indicated in the Flags field of the SESSION_ATTRIBUTE object of the
    Path message. If the Flags indicate "End-to-end re-routing", the
    PathErr message is returned all the way back to the ingress LSR,
    which may then issue a new Path message along another path, which is
    the same procedure as in the flat network case above."

-> why do you make use of the session attribute since section 6.4 
mentions usage of lsp attribute object


editorial
---------

1. title

"Crankback Signaling Extensions for MPLS and GMPLS Signaling"

is probably redundant i would suggest (but leave this at your discretion)

"Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE"

2. section 2.2

alignment with P&R terminology and concepts would be advisable
<http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-terminology-06.txt>

3. section 4.2

"On the other hand, in a network partitioned into areas such as with
    hierarchical OSPF,..."

why "hierarchical OSPF" and not simply "OSPF"

4. section 5. - point 3)

instead of "... (particularly in the GMPLS context),"

i guess you mean for non-PSC LSP ?

5. section 7.2

"IF_ID PHOP" -> IF_ID RSVP_HOP ?

6. section 7.2


       " Node Identifiers:

           A sequence of TLVs as defined here of types 1, 2 or 8 that
           indicates downstream nodes that have already participated in
           crankback attempts and have been declared unusable for the
           current LSP setup attempt."

type 1, 2 does not define nodes in the proposed table ?

7. section 8

"  The ingress LSR, upon receiving the error message, should interact
    with the routing logic to compute an alternate path by pruning the
    specified link ID or node ID in the routing database."

i guess "node ID" refers to Router ID ?

aslo do no provide the exact pointer for TE Router ID and Router ID in 
the IS-IS context

hope this will help
---

Kireeti Kompella wrote:

> Hi,
> 
> This is to initiate CCAMP WG last calls on:
> 
> draft-ietf-ccamp-crankback-04.txt
> 
> and
> 
> draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
> 
> Please send your comments to the list (preferably) or to the authors
> by April 14, 23:59 GMT (which is when the last calls end).
> 
> Thanks,
> Kireeti.
> -------
> 
> 
> .
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 20:23:22 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-00.txt
Date: Fri, 01 Apr 2005 15:22:03 -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		: Label Switched Path Stitching with Generalized MPLS Traffic Engineering
	Author(s)	: A. Ayyangar, J. Vasseur
	Filename	: draft-ietf-ccamp-lsp-stitching-00.txt
	Pages		: 17
	Date		: 2005-4-1
	
In certain scenarios, there may be a need to combine together two
   different Generalized Multi-Protocol Label Switching (GMPLS) Label
   Switched Paths (LSPs) such that in the data plane, a single
   end-to-end (e2e) LSP is achieved and all traffic from one LSP is
   switched onto the other LSP.  We will refer to this as "LSP
   stitching".  This document covers cases where: a) the node performing
   the stitching does not require configuration of every LSP pair to be
   stitched together b) the node performing the stitching is not the
   egress of any of the LSPs c) LSP stitching not only results in an
   end-to-end LSP in the data plane, but there is also a corresponding
   end-to-end LSP (RSVP session) in the control plane.  It might be
   possible to configure a GMPLS node to switch the traffic from an LSP
   for which it is the egress, to another LSP for which it is the
   ingress, without requiring any signaling or routing extensions
   whatsoever, completely transparent to other nodes.  This will also
   result in LSP stitching in the data plane.  However, this document
   does not cover this scenario of LSP stitching.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-00.txt

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


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-lsp-stitching-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-00.txt

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

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

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 17:04:00 +0000
Date: Fri, 1 Apr 2005 09:02:22 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Re: WG last calls
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 31 Mar 2005, Kireeti Kompella wrote:

> This is to initiate CCAMP WG last calls on:
>
> draft-ietf-ccamp-crankback-04.txt

<WG chair hat on>

While this document is well-written and fairly comprehensive, it is
missing an important section.  While it has been claimed that the
moral pedigree of the editor places his writings beyond question, the
said editor is also a WG chair, and as such MUST set an example, good
or otherwise.

So, this document will not be progressed until an appropriate Morality
Considerations section, complete with subsections as specified by RFC
4041, has been added.

<WG chair hat off>

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 13:05:11 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WG last calls
Date: Fri, 1 Apr 2005 07:02:38 -0600
Message-ID: <[e-mail]>
Thread-Topic: WG last calls
Thread-Index: AcU2bDu83poEj13ARbOnsTEGcvqTrQATUvcQ
From: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>
To: "Zhang Renhai" <[e-mail]>, "Adrian Farrel" <[e-mail]>, <[e-mail]>, "Kireeti Kompella" <[e-mail]>
Cc: "Ash, Gerald R \(Jerry\), ALABS" <[e-mail]>

Zhang,

> From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the
> number of crankback rerouting is limited, so there will
> be a result: there is another LSP,but for the reason of
> limiting, the path may be not found.  I think sometimes
> it is unacceptable.The LSP may be prefered to enhancing
> performance.

This problem can be avoided by the setting the node retry threshold
(configurable per node) very high (~infinity), so retries aren't
limited.

Thanks,
Jerry



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 11:53:37 +0000
To: Amit 70405 <[e-mail]>
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Regarding Reversion
Date: Fri, 1 Apr 2005 13:51:49 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFtaXQsIHVwb24gZGF0YSBwbGFuZSBm
YWlsdXJlIHRoZXJlIGlzIG5vIHN1Y2ggYmVoYXZpb3VyIGFzIHlvdSBtZW50aW9uIC0gbG9jYWwg
ZGF0YSBwbGFuZSBmYWlsdXJlIGRldGVjdGlvbiBkb2VzIG5vdCBpbXBseSBzdGF0ZSBkZWxldGlv
biBhbmQgY29tbW9uIFBhdGhFcnIvUmVzdkVyciBkbyBub3QgdHJpZ2dlciBhbnkgc3RhdGUgZGVs
ZXRpb24gbm9yIGRvZXMgYSBOb3RpZnk7IGluIHBhcnRpY3VsYXIsIGluIHRoZSBwcmVzZW50IGNv
bnRleHQgd2hlcmUgb25lIGRvIGFzc3VtZSBjb250cm9sIHBsYW5lIGF2YWlsYWJpbGl0eSBldmVu
IGluIGNhc2Ugb2YgZGF0YSBwbGFuZSBmYWlsdXJlIC0gbm90ZTogZGV0YWlscyBvZiBpdCBhdmFp
bGFibGUgaW4gb3RoZXIgZG9jdW1lbnRzIC0gc3RhdGVzIGNhbiBiZSBrZXB0IHJlZnJlc2hlZDwv
Rk9OVD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWku
Y29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBv
cHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNC8wMS8yMDA1IDE3OjUxIFpFODwv
Rk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRy
aSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxGT05UIFNJWkU9
Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8
Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+
IDxGT05UIFNJWkU9Mj5SZTogUmVnYXJkaW5nIFJldmVyc2lvbjwvRk9OVD48QlI+IDxCUj48QlI+
PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSw8QlI+VGhhbmtzIGZvciBy
ZXBseWluZy48L0ZPTlQ+PEJSPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PkFjY29yZGluZyB0byB0aGUgc3RhdGVtZW50IEkgbWVudGlvbmVkIGZyb20gdGhlIGRyYWZ0LCBJ
IHVuZGVyc3RhbmQgdGhhdCwgaWYgdGhlcmUgaXMgYSBmYWlsdXJlIHRoZSBvbGQgd29ya2luZyBM
U1Agc2hvdWxkIG5vdCBiZSBkZWxldGVkLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5CdXQgbm90IG9ubHkgZm9yIFJTVlAsIGZvciBhbnkgTVBMUyBTaWduYWxp
bmcgcHJvdG9jb2wsIGl0IGlzIG1hbmRhdG9yeSB0aGF0IHdoZW4gYSBmYWlsdXJlIGhhcHBlbnMs
IHlvdSBzaG91bGQgc3RhcnQgdGVhcmluZyBkb3duIHRoZSBMU1AuPEJSPjwvRk9OVD48QlI+PEZP
TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRha2UgZm9yIGluc3RhbmNlIGlmIGEgT3V0SW50
ZXJmYWNlKG9uIHdoaWNoIExTUCBpcyBzZXR1cCkgZ29lcyBkb3duLjxCUj5Qcm90b2NvbCB3aWxs
IGxlYWQgdG8gTFNQIGRlbGV0aW9uLjwvRk9OVD48QlI+PC9VTD48UD48Rk9OVCBGQUNFPSJNb25v
c3BhY2UsQ291cmllciI+UGx6IGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48QlI+UmVnYXJkcyw8
QlI+QW1pdC48QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi
PkNvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc6IFFVT1RFRC1QUklOVEFCTEU8QlI+TUlNRS12ZXJz
aW9uOiAxLjA8QlI+Q29udGVudC10eXBlOiBURVhUL1BMQUlOPC9GT05UPjxCUj48QlI+PEZPTlQg
RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZwYXJhOxorJzcmIzYzNjQwOyZFYWN1dGU7JmV1bWw7
F0qWJmJydmJhcjs8QlI+F5wnJmVjaXJjOyZPdGlsZGU7eiZyYXF1bzsmcXVvdDsmY2VudDt0JmNv
cHk7amAsJnBsdXNtbjsmbGFxdW87LIp9Jm9jaXJjOyZ0aW1lczttNCZhdGlsZGU7XTYmVWFjdXRl
O4kmZWFjdXRlOyZzdXAyOwcomXQmY29weTtqYiZUSE9STjsmZnJhYzEyOyZlYWN1dGU7V0qWJmJy
dmJhcjtKJk91bWw7JnNoeTsmb3JkbTsmQXRpbGRlO2gmcGx1c21uOyZFY2lyYzsre18mc2h5OyZl
Y2lyYzsmcmVnO4ombWlkZG90OyYjNjM2NDA7JmNjZWRpbDtLeiZFdW1sO2wBYgQGBEtNB0wmQWNp
cmM7Jm91bWw7Jk9hY3V0ZTt9B0wmQWNpcmM7JklncmF2ZTsRJIAYQSZPYWN1dGU7MCZzdXAzOwgw
Q04dMwtMAYwgJkFhY3V0ZTsBASE6JmFhY3V0ZTsxF0wmQWNpcmM7DBB0JklncmF2ZTssJmF0aWxk
ZTtLYCZPYWN1dGU7JxACJklhY3V0ZTs8QlI+JkFjaXJjOzxCUj48QlI+EgQXByZxdW90OzxCUj4j
PEJSPjxCUj5SPEJSPhNDJnBvdW5kOyODJnBvdW5kO0NCAiZzdXAzOzxCUj6DPEJSPjxCUj4mQXVt
bDslIyZhdW1sO2cmYW1wOyZvdW1sOyZPYWN1dGU7JmNlbnQ7BBYmT3VtbDuXQjxCUj5zPEJSPkM8
QlI+UgJmJkNjZWRpbDtDJmFjdXRlOxYmT3VtbDuXRHQGh1YXdlYnJmFlbGlnOzYmb3VtbDsmT2dy
YXZlO2Z3QyZzdXAzOyZBdW1sOyUjJmFyaW5nOzdWJmFtcDsmYnJ2YmFyO1Y3QyZjZW50OwUmYW1w
O1Z2FyZhbXA7RpYmYWVsaWc7cgUmYW1wO1dmVyc2liZvdW1sOyZhdGlsZGU7JkF1bWw7JSMmYXJp
bmc7RiZvYWN1dGU7JmNlbnQ7BiZhbXA7FiZBRWxpZzsSJmNjZWRpbDsmYW1wOxYmYnJ2YmFyOxZ2
JmRpdmlkZTsGFiZBRWxpZzsWJmF1bWw7BpYmY2NlZGlsO0ZWJkFjaXJjOyZhZWxpZzs2Jm91bWw7
Jk9ncmF2ZTsmQWNpcmM7BkaWJk91bWw7l0cmYW1wOycmY2NlZGlsOwYXBhZGliZPdW1sO5dHJmFt
cDuWJmRpdmlkZTtUBhYmQUVsaWc7NhdGViZBY2lyYzsmYWVsaWc7JmFtcDtTJkF1bWw7JSMmYXVt
bDs2MyZjZW50OwY2NhYmdGltZXM7BAaWV0ZiJmFlbGlnOyZkaXZpZGU7JmFtcDtzJkF1bWw7JSMm
YXVtbDsmT3VtbDtXNzYWdlImT3VtbDuWQyZjZW50OwJmJkNjZWRpbDtDJnN1cDM7EyNGQ3ODgxMj
RmMmYW1wO2ZiJmF0aWxkZTsTI0ZjJmFtcDtmYxMjRkNzgzwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 11:01:27 +0000
Date: Fri, 01 Apr 2005 17:51:36 +0800
From: Amit 70405 <[e-mail]>
Subject: Re: Regarding Reversion
To: [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)"
Content-language: en

This is a multi-part message in MIME format.

--Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline

Hi,
  Thanks for replying.
 
  According to the statement I mentioned from the draft, I understand that, if there is a failure the old working LSP should not be deleted.

  But not only for RSVP, for any MPLS Signaling protocol, it is mandatory that when a failure happens, you should start tearing down the LSP.
  
  Take for instance if a OutInterface(on which LSP is setup) goes down.
  Protocol will lead to LSP deletion.

  Plz correct me if I am wrong.
Regards,
Amit.


--Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)
Content-type: message/rfc822
Content-disposition: inline

MIME-version: 1.0
Content-type: TEXT/PLAIN
Content-transfer-encoding: QUOTED-PRINTABLE

=B6=1A+=8B7=9D=C9=EB=17J=96=A6
=17=9C=91=EA=D5z=BB"=A2t=A9j`,=B1=AB,=8A}=F4=D7m4=E3]6=DA=89=E9=B2=
=07(=99t=A9jb=DE=BD=E9WJ=96=A6J=D6=AD=BA=C3h=B1=CA+{_=AD=EA=AE=8A=
=B7=9D=E7Kz=CBl=01b=04=06=04KM=07L=C2=F6=D3}=07L=C2=CC=11$=80=18A=
=D30=B3=080CN=1D3=0BL=01=8C =C1=01=01!:=E11=17L=C2=0C=10t=CC,=E3K`=
=D3=91=10=02=CD=00=C1=1A=BA=DA%y=AA=E7=9E=8Bz=BB"=A2}=D3S=C5=03=E3=
=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6=86=
=92=02=D2=07v=F7V=C6B=07=96=F7R=07=06=C6V=176R=066=C6=17&=96g=92=07=
=96=F7W"=066=F6=D6=D6V=E7B=02=D2=07F=F2=07v=86=966=82=07=06=F7FV=E7F=
=96=16=C2=07f=96=F6=C6=17F=96=F6=E2=06F=F2=07=96=F7R=07&VfW"=03=F2=
=06=96=E2=07=06=17'F=967V=C6=17"=07F=86=972=077=06V6=96f=966=17F=96=
=F6=E2=06&V=96=E6r=06gV=E67F=96=F6=E6=16=C2=077=06V6=96f=962=06FWF=
=16=96=C72=066=F6=E66W&=E6=96=E6r=07&V=16=C6=97=A6=17F=96=F6=E2=07W6=
=96=E6r=05%5e=02=06=17&R=07=07&=F7f=96FVB=06=96=E2=07F=86R=06V=E6B=
=D7F=F2=D6V=E6B=076=96v=E6=16=C6=96=E6r=06F=F67V=D6V=E7C=C4%#=E3=C2=
=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E3=C4#=E4=16=D6=97B=
=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3=
=C2=F4#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E56V=
=E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=
=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E3=03B=F3=03=12=
=F3#=03=03R=03=13C=A33=92=05=A4S=83=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=
=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E5F=F3=A3=C2=F4d=F4=E5C=E2=03=C4d=
=F4=E5B=054=95=A4S=D3#=E666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C2=
=F4d=F4=E5C=E3=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E663=A3=C2=F4d=
=F4=E5C=E2=03=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E6&63=A3=C2=F4d=
=F4=E5C=E2=03=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E57V&=A6V7C=A3=
=C2=F4d=F4=E5C=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E5&Vv=17&F=96=E6r=05&W=
fW'6=96=F6=E3=C2=F4d=F4=E5C=E3=C4%#=E2=03=C4%#=E3=C4%#=E3=C2=F5=03=
=E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E46=F6=E7FV=E7B=D7G&=16=E76fW"=D6V=E66=F6F=96=E6s=A2=03t$=95C=
=C4%#=E5&V6V=97fVC=A2=06g&=F6=D2=05=B3=13s"=E3#B=E3=12=E35=D2=02=84f=
=F7'v=17&FVB=D4f=F7#=A2=05=B3=13=02=E3s=82=E3#3=02=E3=13c5=D2=92=06'=
=92=077=A7=86=D63=03"=D6=96=E2=E6=87V=17vV=92=E66=F6=D2=02=86=D76=
=87GG=06B=93=B2=04g&=92=C2=03=03=12=04=17=07"=03#=03=03R=03=13C=A3#=
=83=A3CB=02=B3=03=83=03=03=C4%#=E4F=17FS=A2=04g&
=C2=03=03=12=04=17=07"=03#=03=03R=03=13C=A3#=83=A3CB=02=B3=03=83=03=
=03=C4%#=E4g&=F6=D3=A2=04=16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=
=06=87V=17vV=92=E66=F6=D2fwC=B3=C4%#=E57V&=A6V7C=A2=05&Vv=17&F=96=
=E6r=05&WfW'6=96=F6=E3=C4%#=E5F=F3=A2=06&=16=C6=12=E7&=16=A6=16v=F7=
=06=16=C6=16=E4=06=96=E7FV=C2=E66=F6=D2=C2=06F=96=D6=97G&=92=E7=06=
=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S=C4%#=E463=A2=0666=
=16=D7=04=06=96WFb=E6=F7&s=C4%#=E4=D6W76=16vR=D6=96C=A2=02f=C7C=B3=
=13#FCs=83=83=13#Fc&fb=E3=13#Fc&fc=13#FCs=83=84=06=87V=17vV=92=E66=
=F6=D2fwC=B3=C4%#=E4=D4=94=D4R=D7fW'6=96=F6=E3=A2=03=12=E3=03=C4%#=
=E5=82=D4=D6=16=96=C6W#=A2=06=95=06=C6=16=E6WB=04=D6W76V=E6vW"=04W=
=87=07&W72=03R=E3"=04=86=F7Df=97=82=03=12=E3#R=02=86'V=96=C7B=04=D6=
=17"=02f=E6'7=03=B32=03#=03=03B=93=C4%#=E46=F6=E7FV=E7B=D7G=97=06S=
=A2=07FW=87B=F7=06=C6=16=96=E3=B2=066=86=17'6WC=D7W2=D6=1766=96=93=
=C4%#=E46=F6=E7FV=E7B=D6=C6=16=E6wV=16vS=A2=06V=E3=C4%#=E46=F6=E7FV=
=E7B=D6F=977=06=F76=97F=96=F6=E3=A2=06=96=E6=C6=96=E6S=C4%#=E5=82=
=D4=1666W=07B=D4=C6=16=E6wV=16vS=A2=06V=E3=C4%#=E5=07&=96=F7&=97G=
=93=A2=06=E6=F7&=D6=16=C3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4=
=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=C3=
=C4%#=E4=96=E2=07F=86R=06G&=16gB=06G&=16gB=D6=96WFb=D666=16=D7=02=
=D6v=D7=06=C72=D7&V6=F7fW'=92=D6gV=E67F=96=F6=E6=16=C2=D3=03B=E7G=
=87B=C2=06=96=E2=07F=86R=076V7F=96=F6=E2=06=16&=F7WB=05&WfW'6=96=F6=
=E2=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5=03=E3=C5T=C3=E3=C4d=F4=E5B=04d=
=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=97B=06=972=076=16=
=96C=A3=C4%#=E2g=17V=F7C=B5&WfW'6=96=F6=E2=06=96=D7=06=C6=96W2=07F=
=86=17B=06=12=07v=F7&=B6=96=E6r=07=06=17F=82=07&V=D6=16=96=E72=06=
=16=C6=C6=F66=17FVB=07F=F2=07F=86R=04=C55=02=07F=86=17C=C4%#=E7v=172=
=06=F7&=96v=96=E6=16=C6=C7=92=07&=F7WFVB=06=F7fW"=06=97B=06WfV=E2=
=06=16gFW"=06=12=06f=16=96=C7W&R=E2g=17V=F7C=B3=C2=F4d=F4=E5C=E3=C4%#=
=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=
=96W"#=E5F=86=972=07&W=17V=97&V=D6V=E7B=06=D6=17=92=06=86=F6=C6B=07G'=
VR=06f=F7"=06=E6=F6=E2=D5=0542=06=E6WGv=F7&=B72=C2=06=16=E6B=06=D6=
=17=92=06=E6=F7B=06&R=07&W=17V=97&VB=06=96=E2=05=0542=E3=C4%#=E4=86=
=F7r=066=16=E2=05%5e=02=077W=07=06=F7'B=07F=86=973=F3=F2=04=92=06=
=D6V
=E2=06=97B=06=D6=17=92=07F=F7F=16=C6=C7=92=07f=96=F6=C6=17FR=05%5e=
=02=D5DR=077F=16=E6F=17&B=E3=C4%#=E4=172=07F=86=F7Vv=82=07F=86R=06f=
=16=96=C7W&R=06=86=172=06=86=17=07=06V=E6VB=06=16=E6B=04=C55=02=076=
=86=F7V=C6B=06=E6=F7B=06&R=06FV=C6WFVB=E3=C2=F4d=F4=E5C=E3=C4%#=E3=
=C2=F5T=C3=E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=
=C46=F7W&=96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"=
=07f=96Wr=06=F6=E2=07F=86=972=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=
=97B=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C2=F5


--Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)--



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 09:26:17 +0000
To: Amit 70405 <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
From: [e-mail]
Subject: Re: Regarding Reversion
Date: Fri, 1 Apr 2005 11:24:44 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: base64

PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIC0gd291bGQgeW91IHBsZWFzZSBj
bGFyaWZ5IHlvdXIgY29tbWVudCAtIHRvIHdoaWNoIHBvdGVudGlhbCB2aW9sYXRpb24gZG8geW91
IHJlZmVyID8gaW4gcGFydGljdWxhciB0aGlzIHNwZWNpZmljYXRpb24gYmVpbmcgZnVuY3Rpb25h
bCBzcGVjaWZpYyBkZXRhaWxzIGNvbmNlcm5pbmcgcmVhbGl6YXRpb24gdXNpbmcgUlNWUCBhcmUg
cHJvdmlkZWQgaW4gdGhlIGVuZC10by1lbmQgc2lnbmFsaW5nIGRvY3VtZW50PEJSPjwvRk9OVD48
QlI+PEZPTlQgU0laRT0yPjxCPkFtaXQgNzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PC9C
PjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9y
ZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjA0LzAxLzIwMDUgMTQ6MzkgWkU4PC9GT05UPjxCUj48
QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5v
cmc8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5i
Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0y
PlJlZ2FyZGluZyBSZXZlcnNpb248L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNF
PSJNb25vc3BhY2UsQ291cmllciI+Q29udGVudC10cmFuc2Zlci1lbmNvZGluZzogN0JJVDxCUj5S
ZWNlaXZlZDogZnJvbSBbMTcyLjI0LjEuM10gKEZvcndhcmRlZC1Gb3I6IFsxMC43OC4yMzAuMTYz
XSkgYnkgc3p4bWMwMi1pbi5odWF3ZWkuY29tIChtc2h0dHBkKTsgRnJpLCAwMSBBcHIgMjAwNSAx
NDoyODo0NCArMDgwMDxCUj5EYXRlOiBGcmksIDAxIEFwciAyMDA1IDE0OjI4OjQ0ICswODAwPEJS
PkZyb206IEFtaXQgNzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPlN1YmplY3Q6IFJl
Z2FyZGluZyBSZXZlcnNpb248QlI+VG86IGJhbGEucmFqYWdvcGFsYW5AaW50ZWwuY29tLCBkaW1p
dHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5DYzogY2NhbXBAaWV0Zi5vcmc8QlI+TWVz
c2FnZS1pZDogJmx0OzEyNGQ3ODgxMjRmMmZmLjEyNGYyZmYxMjRkNzg4QGh1YXdlaS5jb20mZ3Q7
PEJSPk1JTUUtdmVyc2lvbjogMS4wPEJSPlgtTWFpbGVyOiBpUGxhbmV0IE1lc3NlbmdlciBFeHBy
ZXNzIDUuMiBIb3RGaXggMS4yNSAoYnVpbHQgTWFyICZuYnNwOzMgMjAwNCk8QlI+Q29udGVudC10
eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpPEJSPkNvbnRlbnQtbGFuZ3VhZ2U6IGVu
PEJSPkNvbnRlbnQtZGlzcG9zaXRpb246IGlubGluZTxCUj5YLUFjY2VwdC1MYW5ndWFnZTogZW48
QlI+UHJpb3JpdHk6IG5vcm1hbDwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD
b3VyaWVyIj5IaSw8QlI+SW4gdGhlIGRyYWZ0IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcmVjb3Zl
cnktZnVuY3Rpb25hbC0wNC50eHQsIGluIHRoZSBzZWN0aW9uIGFib3V0IFJldmVyc2lvbi48L0ZP
TlQ+PEJSPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkl0IGlzIHNhaWQ6
PEJSPiZxdW90O1JldmVyc2lvbiBpbXBsaWVzIHRoYXQgYSB3b3JraW5nIHBhdGggcmVtYWlucyBh
bGxvY2F0ZWQgdG8gdGhlIExTUCB0aGF0PEJSPndhcyBvcmlnaW5hbGx5IHJvdXRlZCBvdmVyIGl0
IGV2ZW4gYWZ0ZXIgYSBmYWlsdXJlLiZxdW90OzwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v
bm9zcGFjZSxDb3VyaWVyIj5UaGlzIHJlcXVpcmVtZW50IG1heSBob2xkIHRydWUgZm9yIG5vbi1Q
U0MgbmV0d29ya3MsIGFuZCBtYXkgbm90IGJlIHJlcXVpcmVkIGluIFBTQy48QlI+SG93IGNhbiBS
U1ZQIHN1cHBvcnQgdGhpcz8/IEkgbWVhbiBpdCBtYXkgdG90YWxseSB2aW9sYXRlIFJTVlAtVEUg
c3RhbmRhcmQuPEJSPkFzIHRob3VnaCB0aGUgZmFpbHVyZSBoYXMgaGFwcGVuZWQgYW5kIExTUCBz
aG91bGQgbm90IGJlIGRlbGV0ZWQuPC9GT05UPjxCUj48L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9z
cGFjZSxDb3VyaWVyIj5QbHogbGV0IG1lIGtub3cgeW91ciB2aWV3IG9uIHRoaXMuPEJSPlJlZ2Fy
ZHMsPEJSPkFtaXQuPEJSPjwvRk9OVD48L1A+



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 06:47:08 +0000
Date: Fri, 01 Apr 2005 14:39:53 +0800
From: Amit 70405 <[e-mail]>
Subject: Regarding Reversion
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg)"
Content-language: en

This is a multi-part message in MIME format.

--Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg)
Content-type: message/rfc822
Content-disposition: inline

Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163])
 by szxmc02-in.huawei.com (mshttpd); Fri, 01 Apr 2005 14:28:44 +0800
Date: Fri, 01 Apr 2005 14:28:44 +0800
From: Amit 70405 <[e-mail]>
Subject: Regarding Reversion
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-transfer-encoding: 7BIT
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Hi,
   In the draft draft-ietf-ccamp-gmpls-recovery-functional-04.txt, in the section about Reversion.

   It is said:
   "Reversion implies that a working path remains allocated to the LSP that
   was originally routed over it even after a failure."

   This requirement may hold true for non-PSC networks, and may not be required in PSC.
   How can RSVP support this?? I mean it may totally violate RSVP-TE standard.
   As though the failure has happened and LSP should not be deleted.

   Plz let me know your view on this.
Regards,
Amit.


--Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg)--



Envelope-to: [e-mail]
Delivery-date: Fri, 01 Apr 2005 03:37:44 +0000
Date: Fri, 01 Apr 2005 11:13:28 +0800
From: Zhang Renhai <[e-mail]>
Subject: Re: WG last calls
To: Adrian Farrel <[e-mail]>, [e-mail], Kireeti Kompella <[e-mail]>
Message-id: <000e01c53668$c9abb7e0$[e-mail]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Hi,Adrian 
 From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the number of crankback
rerouting is limited, so there will be a result: there is another LSP,but for the reason
of limiting, the path may be not found.
I think sometimes it is unacceptable.The LSP may be prefered to enhancing performance.

Regards,
Zhang

----- Original Message ----- 
From: "Kireeti Kompella" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 31, 2005 11:37 PM
Subject: WG last calls


> Hi,
> 
> This is to initiate CCAMP WG last calls on:
> 
> draft-ietf-ccamp-crankback-04.txt
> 
> and
> 
> draft-ietf-ccamp-rsvp-te-exclude-route-03.txt
> 
> Please send your comments to the list (preferably) or to the authors
> by April 14, 23:59 GMT (which is when the last calls end).
> 
> Thanks,
> Kireeti.
> -------
>